Analysis and Resolution of Full GC Issues in Inventory Center Online Business

针对库存中心线上业务full gc问题进行深入分析，并结合此次问题解决的方法、根因分析落地此类问题的解决思路，并沉淀出一些通用的实践经验及注意事项。

1. 事件回顾

从7.27号开始主站、分销等业务方开始反馈下单偶发超时现象，我们开始分析排查问题原因，震惊地发现线上偶发full gc，如下图所示。如果继续放任下去，势必影响严选交易下单核心链路及用户体验，造成交易损失。库存中心开发迅速响应，积极排查并解决问题，把问题在萌芽状态处理掉，避免造成资损。

2. 紧急止血

对于频繁full gc，根据经验，我们大胆猜测可能由于某些接口产生大对象并且调用频率较高引起，在紧急情况下，首先保证系统核心功能不受影响，然后再排查问题。一般有三种手段，如下：

- 扩容

- 限流

- 重启

我们应用限流是针对应用接口层面得，由于不知道问题具体原因且问题还在萌芽状态，所以就没有直接限流，而是直接扩容，顺带重启。我们临时紧急对堆内存扩容，将部分机器堆内存大小由6g提升至22g，并对应用进行重启，使配置参数生效。

3. 问题分析

由于没有OOM，所以没有现场内存快照，不好确定问题原因，而库存主服务涉及的逻辑太多（核心业务逻辑有十几万行代码，都是日常在运行的），且业务逻辑复杂、调用量大，并且存在少量慢请求，增加了排查问题难度。由于没有相对完善的基建设施，我们没有一个全局的调用监控平台去观察full gc前后应用到底发生了什么，只能通过在问题机器上分析链路调用情况，去一点点寻找问题真相。

4. 表象原因

本质上，我们要看下发生full gc时应用系统做了什么事情，也就是说找到压死骆驼最后一根稻草是什么？

我们对发生full gc前时间点应用日志进行了大量分析，结合慢sql分析，只要业务在一段时间频繁操作【内外部采购出库】业务，系统就会触发一次full gc，时间点比较吻合，因此，初步判定可能由于内外部采购出库业务操作引起得，通过分析业务代码分析发现，该库存变更经过干预拦截会将10w条数据load到内存中，共计300M左右，感觉一下子看到了希望！

对此我们7.28号紧急联系dba将该部分业务数据紧急迁移到其他数据库，避免进一步对业务造成影响，后续再对业务流程进行优化！！

5. 问题根因

当时我们多次dump了内存快照，并没有发现类似问题，庆幸地是155这台机器最后才升级(备用机，主要用于处理定时任务，留作参照对比效果)，让我们进一步接近了问题根因。

为进一步分析原因，我们对其中一台机器(155)堆内存快照进行了分析，发现了一个比较有意思的现象，即存在大量的线程阻塞等待线程；

每一个阻塞线程会持有大约14M的内存，正是这些线程导致了内存泄漏，至此我们终于找到了问题原因，同时验证了我们的猜想，即发生了内存泄漏！

6. 原因分析

本质上，我们要看下发生full gc时应用系统做了什么事情，也就是说找到压死骆驼最后一根稻草是什么？

我们对发生full gc前时间点应用日志进行了大量分析，结合慢sql分析，只要业务在一段时间频繁操作【内外部采购出库】业务，系统就会触发一次full gc，时间点比较吻合，因此，初步判定可能由于内外部采购出库业务操作引起得，通过分析业务代码分析发现，该库存变更经过干预拦截会将10w条数据load到内存中，共计300M左右，感觉一下子看到了希望！

对此我们7.28号紧急联系dba将该部分业务数据紧急迁移到其他数据库，避免进一步对业务造成影响，后续再对业务流程进行优化！！

7. 问题解决

7.27号紧急对部分机器(73和74)扩容后，我们可以发现扩容后2天内没有发生full gc，为我们进一步排查提供了容错时间；

8. 总结

通过优化线程池配置和业务流程l，如调高线程池队列大小、修复拒绝策略、优化业务流程规避大对象、任务错峰执行等一系列组合措施，保证了任务稳定执行。