Tomcat(hybris)服务器GC异常导致性能衰减问题排查求助

刚接手这类「重启就好、运行几天就崩」的性能问题确实挠头，结合你给出的JVM参数、4核16G的服务器配置，还有监控截图的线索，咱们从几个核心方向入手排查：

一、先从JVM GC配置和行为找线索 #

你用的是G1GC，堆内存固定12G（占16G服务器的75%，这个比例是合理的），但几个参数得重点关注：

• XX:MaxGCPauseMillis=200：G1会拼命保证200ms的停顿，但如果老年代堆碎片多、内存回收跟不上，它会频繁触发混合GC甚至Full GC，直接把CPU拉满
• XX:NewRatio=4：新生代只占堆的1/5（也就是2.4G），对于Hybris这种电商平台来说，新生代偏小了——大量短期对象会快速挤到老年代，老年代GC压力陡增，时间一长就扛不住
• XX:ConcGCThreads=1：4核CPU只给1个并发GC线程，并发标记阶段效率太低，老年代对象增长速度超过清理速度，最后只能触发阻塞式的Full GC，性能直接雪崩

结合你给出的监控截图，重点盯这几个点：

• 老年代内存是不是只涨不跌？如果是，基本实锤内存泄漏
• GC占用的CPU时间是不是随运行时间越来越高？尤其是并发GC的耗时是不是越来越长
• Eden区是不是频繁回收，而且每次回收后存活对象占比特别大？这就是新生代太小的典型表现

二、内存泄漏的核心排查方向 #

重启就恢复，运行几天就崩，内存泄漏是头号嫌疑，针对Hybris平台，优先查这几个点：

• Hybris缓存配置：去cache.properties里看缓存过期策略，比如cache.*.expirationTime有没有设置，会不会有缓存对象被静态引用死死攥住，或者缓存键值对无限膨胀
• 资源泄漏：检查JDBC连接池（不管是Tomcat的还是Hybris自带的），有没有连接用完没释放的情况；还有文件流、网络连接这些资源，代码里有没有在finally块里正确关闭
• 自定义/第三方代码：排查项目里新增的自定义扩展、第三方插件，有没有ThreadLocal用完没清理，或者静态集合（比如HashMap）一直往里面加对象从不删除的情况
• Flexible Search问题：有没有大量未关闭的Flexible Search会话？或者某些查询返回超大结果集，被代码长期持有没释放

三、CPU飙升的关联排查 #

内存泄漏会逼得GC疯狂跑占CPU，但也得排除其他可能性：

• 线程泄漏：用jstack或者Arthas抓一下线程栈，看看线程数是不是随时间越来越多——比如定时任务线程池没设上限，或者异步任务跑完没销毁线程
• 高CPU代码：高负载时用top -H找到占CPU最高的线程，转成十六进制后去jstack日志里找对应的线程栈，看看是不是有死循环、频繁的字符串拼接、复杂正则匹配这类耗时操作
• CronJob问题：去Hybris的HAC控制台看定时任务记录，有没有某些CronJob运行时间越来越长，或者重复执行的情况——比如数据越积越多，任务处理逻辑没优化

四、马上能上手的实操步骤 #

1. 分析GC日志：你已经开了GC日志，把完整运行周期的日志导出来，用GCViewer或者GCEasy（本地工具，不用传外网）分析，看看内存增长趋势、Full GC频率、停顿时间变化，能快速定位是内存泄漏还是GC配置不合理
2. 抓堆快照：在服务器性能下降但还没挂的时候，用jmap -dump:format=b,file=heapdump.hprof <进程ID>抓个堆快照，然后用MAT（Memory Analyzer Tool）打开，找占用内存最大的对象、引用链，直接揪出泄漏点
3. 临时调整JVM参数缓解：先把新生代调大，把XX:NewRatio=4改成-XX:NewSize=3G -XX:MaxNewSize=3G，同时把ConcGCThreads=2（4核CPU给2个并发GC线程更合理），看看能不能延长性能衰退的时间，给排查争取窗口
4. Hybris自带工具排查：登录HAC控制台，去Monitoring模块看缓存使用、线程状态、CronJob执行记录，Hybris自带的监控已经能给出不少线索

内容的提问来源于stack exchange，提问作者David V.