CMS GC暴走探究：从46秒到600毫秒，我是如何排查解决的？

CMS GC 暴走：一场与时间赛跑的故障排查之旅

GC 日志分析：发现问题根源

在一个忙碌的清晨，一个令人不安的告警邮件打破了宁静，某项关键服务几近瘫痪。出于好奇和学习的冲动，我开始了故障排查的旅程。

首当其冲，我仔细检查了 GC 日志，一个令人震惊的事实映入眼帘：Full GC 竟然长达 46.6 秒！要知道，我们通常遇到的 Full GC 时间都在 1 秒以内，即便最长的也不过几秒。46 秒的 Full GC，简直闻所未闻。

不仅如此，日志还显示 Young GC 和 Old GC 的时间也异常漫长，分别达到了 10 秒和 15 秒。这表明，整个 GC 系统都出了问题。

堆栈信息和线程 Dump：抽丝剥茧

接下来，我查看了堆栈信息和线程 Dump，希望能找到问题的根源。堆栈信息揭示了在 Full GC 期间，大量线程处于等待状态，大部分都在等待锁。这让我怀疑存在着严重的锁竞争问题。

线程 Dump 进一步证实了这一推测，大量线程处于死锁状态，相互等待。这些死锁线程主要集中在几个关键业务方法上，这些方法都涉及到对共享资源的访问，如数据库连接池、分布式锁等。

内存分析：拨开迷雾

为了更深入地了解问题，我使用 jmap 工具对堆内存进行了分析。结果显示，堆内存中堆积了大量对象，其中大部分都是一些临时对象，如字符串、数组等。这些对象虽然占用内存空间小，但数量庞大，导致堆内存很快被占满，从而触发频繁的 GC。

同时，我还发现了一些可疑的对象，这些对象的数量虽然不多，但内存占用却非常大。经过进一步调查，我发现这些对象都是由于内存泄露造成的。

调整 GC 参数：釜底抽薪

在查明问题根源后，我首先对 GC 参数进行了调整。将 CMS GC 的初始标记和重新标记算法改为“Serial”，并将 Young GC 的触发阈值降低，以减少 Young GC 的频率。这些调整有效地缩短了 GC 的时间，但仍然无法从根本上解决问题。

修复内存泄露：斩草除根

接下来，我开始着手修复内存泄露问题。通过分析堆栈信息和线程 Dump，我找到了几个可能导致内存泄露的关键方法。经过仔细检查，我发现这些方法都没有正确地关闭资源，导致对象无法被及时回收，从而造成内存泄露。

修复了这些内存泄露问题后，我重新启动了服务。这次，GC 时间大大缩短，Full GC 时间从 46.6 秒缩短到了 600 毫秒，Young GC 和 Old GC 的时间也分别缩短到了 100 毫秒和 200 毫秒。服务也恢复了正常运行。

总结：从经验教训中成长

这次故障让我深刻地认识到了 GC 的重要性，也让我对 GC 有了更深入的了解。在排查故障的过程中，我学到了很多宝贵的经验，也掌握了一些实用的工具和技巧。我相信，这些经验和知识将在未来的工作中对我大有裨益。

经验分享：给运维同学的一点建议

1. 平时要养成查看 GC 日志的习惯，及时发现 GC 异常情况。
2. 熟悉常用的 GC 工具，如 jmap、jhat、MAT、GCViewer 等，以便在遇到 GC 问题时能够快速定位和解决问题。
3. 定期对系统进行性能调优，及时调整 GC 参数，以保证系统的稳定性和性能。
4. 注意内存泄露问题，及时修复内存泄露漏洞，避免因内存泄露导致系统崩溃。

常见问题解答

1. 什么是 GC？

GC（Garbage Collection）是一种自动内存管理机制，负责回收不再被程序使用的内存空间，防止内存泄露和系统崩溃。

2. 为什么 GC 会暴走？

GC 暴走可能是由多种因素造成的，如内存泄露、锁竞争、过度频繁的 GC 等。

3. 如何检测 GC 问题？

可以通过查看 GC 日志、使用 GC 工具（如 jmap、GCViewer 等）以及分析堆栈信息和线程 Dump 来检测 GC 问题。

4. 如何修复 GC 问题？

修复 GC 问题的方法根据具体情况而异，一般包括调整 GC 参数、修复内存泄露、优化代码等。

5. 如何避免 GC 问题？

可以通过良好的编码习惯（如正确地关闭资源）、定期进行性能调优以及使用 GC 工具来避免 GC 问题。