解决 CMS Old GC 频繁触发线上问题技术方案
目录
一、CMS GC 工作原理
二、现象分析
（一）具体表现说明
（二）触发条件
三、总结优化措施
（一）调整 CMS 启动条件：降低 Old 区触发阈值
1. 原理分析
2. 建议配置
（二）调整 CMS GC 等待时间：控制 GC 频率
1. 原理分析
2. 建议配置
（三） 启用 Class Unloading：回收 MetaSpace 和 PermGen 区域内存
1. 原理分析
2. 建议配置
（四）控制对象晋升：避免过早晋升至 Old 区
1. 原理分析
2. 建议配置
（五）优化内存泄漏问题：定位与解决内存泄漏
1. 原理分析
2. 建议配置与步骤
四、总结
干货分享，感谢您的阅读！
在 Java 应用的内存管理中，垃圾回收（GC）是一个至关重要的组成部分。随着应用的复杂度增加，GC 的表现和效率直接影响着系统的吞吐量和响应时间。**CMS（Concurrent Mark-Sweep）**垃圾回收器作为一种低暂停时间的垃圾回收策略，广泛应用于高性能应用场景。然而，CMS Old GC 频繁触发的问题却困扰着许多开发者和运维人员。本文将深入分析 CMS Old GC 频繁触发的原因，并提供优化策略，帮助开发者在实际工作中解决这一问题。
一、CMS GC 工作原理
在讨论 CMS Old GC 频繁触发的原因之前，我们首先需要了解 CMS GC 的工作原理。CMS 是一种基于 标记-清除（Mark-Sweep）算法的垃圾回收器，采用了并发标记与清除的方式，旨在减少 GC 时的停顿时间。
CMS GC 的基本流程：
- Young GC：清理年轻代内存，回收新生对象。
- Concurrent Marking：并发标记所有存活的对象，标记结束后，标记的对象被分配到相应的区。
- Concurrent Sweep：在并发标记之后，清除被标记为垃圾的对象。
- CMS Old GC：当 Old 区内存占用达到阈值时，进行 Old GC，回收长时间存活的对象。
CMS 的目标是尽量减少 STW（Stop-The-World）事件，尤其是在 Old 区的垃圾回收时，通过并发的方式进行处理。然而，如果 Old GC 频繁发生，可能会对系统的性能产生负面影响，导致吞吐量下降，延迟增大。
二、现象分析
（一）具体表现说明
在生产环境中，CMS Old GC 频繁的问题表现为：
- GC 频繁触发：每次执行 Old GC 的时间虽然不长，但却经常发生。
- 吞吐量下降：由于 GC 频繁，应用程序的吞吐量明显下降。
- 响应时间增大：频繁的 GC 导致应用的响应时间波动，影响用户体验。
（二）触发条件
CMS GC 是否触发，取决于一系列的条件。以下是触发 CMS Old GC 的常见情形：
- Old 区内存占用达到阈值：当 Old 区的占用率超过一定阈值时，CMS 会触发垃圾回收。
- Young GC 失败或将要失败：当 Young 区执行 GC 失败，或者预期下一次 Young GC 可能失败时，CMS 会尝试回收 Old 区。
- 手动请求 Full GC：通过
System.gc()等方式显式请求垃圾回收，也可能触发 Old GC。 - MetaSpace 的 GC：如果开启了
-XX:+CMSClassUnloadingEnabled，CMS 也会参与 MetaSpace 的回收。
具体来说，ConcurrentMarkSweepThread 类中的方法 shouldConcurrentCollect() 用于判断是否满足回收条件。代码中的判断逻辑会根据多个因素来决定是否需要触发 Old GC：
if (_cmsGen->occupancy() >= _bootstrap_occupancy) {
return true; // 触发 GC 的条件：Old 区占用率过高
}
此外，CMSWaitDuration 和 CMSCheckInterval 参数的设置也会影响 Old GC 触发的频率，较短的检查间隔可能导致过于频繁的 GC 触发。
三、总结优化措施
当 CMS Old GC 频繁时，优化措施的核心目标是减少 GC 的频率，提高系统的吞吐量和响应时间。以下总结几种在实际应用中的经验和建议：
（一）调整 CMS 启动条件：降低 Old 区触发阈值
通过调整 -XX:CMSInitiatingOccupancyFraction 参数，可以控制 CMS 启动回收的触发阈值。默认情况下，当 Old 区占用超过 92% 时，CMS 会启动 Old GC。然而，在高并发、内存压力较大的应用场景中，等待 Old 区占用达到 92% 才触发 GC 可能会导致回收过晚，从而造成频繁的 GC 和性能下降。
1. 原理分析
-XX:CMSInitiatingOccupancyFraction设置了 CMS 触发回收的占用率阈值。默认值为 92%，即当 Old 区占用超过 92% 时触发 GC。- 如果系统负载较重，尤其是内存占用较高的情况下，降低阈值可以更早地触发回收，避免 Old 区占满后才开始清理。
2. 建议配置
-XX:CMSInitiatingOccupancyFraction=85将阈值降低到 85%，可以使 CMS 更早地启动回收，减少内存压力，避免频繁的 Old GC。当系统负载较低时，可以适当提高此阈值，减少 GC 频率。
应用场景：
- 在内存较紧张的高并发应用中，建议将该参数设置为 80%-85%，通过提前回收 Old 区来避免后续的频繁 GC。
- 对于内存使用较为宽松的系统，可以适当提高此值，以减少不必要的回收。
（二）调整 CMS GC 等待时间：控制 GC 频率
参数 -XX:CMSWaitDuration 控制了 CMS GC 的等待时间，默认值为 2 秒。此参数的作用是在触发一个完整的 CMS GC 周期前，等待多久进行下一次的检查。如果 GC 周期过短，可能会导致不必要的频繁轮询，从而加重系统负担。
1. 原理分析
- CMS GC 的后台线程通过
sleepBeforeNextCycle()方法等待下次检查周期，期间会根据CMSWaitDuration设置的时间间隔进行睡眠。 - 通过增加等待时间，可以减少检查频率，避免过度轮询造成的性能开销。
2. 建议配置
-XX:CMSWaitDuration=5000将等待时间增至 5 秒（或更长），可以减少不必要的频繁轮询，特别是在系统负载较低或者不需要频繁回收的情况下。
应用场景：
- 在负载较低的应用中，增加等待时间能够降低过于频繁的 CMS GC 检查，从而提升系统的吞吐量。
- 在高负载的生产环境中，需要小心增加等待时间，以免影响到 GC 的及时触发。
（三） 启用 Class Unloading：回收 MetaSpace 和 PermGen 区域内存
在默认情况下，CMS 并不会回收 MetaSpace 或 PermGen 区域的内存。对于类的卸载和元数据回收，CMS 不会触及这些区域。如果应用中存在大量的类加载和卸载操作，未回收的类信息会占用大量内存，增加 Old GC 负担。
1. 原理分析
-XX:+CMSClassUnloadingEnabled启用后，CMS 将开始对 MetaSpace（或者 PermGen）区域进行垃圾回收。该功能对于运行时动态加载大量类的应用场景尤为重要。- 启用此功能后，可以减少内存压力，特别是在长时间运行的应用中，避免类信息堆积导致 CMS Old GC 频繁。
2. 建议配置
-XX:+CMSClassUnloadingEnabled在需要对 MetaSpace 或 PermGen 进行回收的应用中，启用该参数可以减少内存占用，从而减轻 Old 区的负担。
应用场景：
- 对于复杂的 Java Web 应用，尤其是需要动态加载大量类的场景，启用该选项有助于释放大量不再使用的类信息。
- 对于基于 OSGi 等框架的应用，动态的类加载和卸载操作可以通过启用此参数优化内存回收。
（四）控制对象晋升：避免过早晋升至 Old 区
在 CMS 中，对象在 Young 区存活一定时间后会晋升至 Old 区。默认情况下，CMS 会将存活时间较长的对象晋升到 Old 区，但如果这些对象其实并不需要长期存活，这会导致 Old 区的内存压力增大，进而触发频繁的 Old GC。
1. 原理分析
-XX:MaxTenuringThreshold控制对象晋升到 Old 区的年龄阈值。较低的值会导致对象较早晋升，而较高的值则会推迟晋升。合理配置该参数可以控制对象的晋升时机，从而避免不必要的内存消耗。- 如果设定值过低，可能导致许多短生命周期的对象提前晋升，增加 Old 区的内存压力。
2. 建议配置
-XX:MaxTenuringThreshold=10将晋升阈值设置为 10，意味着只有当对象在 Young 区存活超过 10 次 GC 后才会晋升到 Old 区。根据应用特点适当调整此值，可以有效控制晋升时机。
应用场景：
- 对于长期存活的对象（如缓存数据或数据库连接），适当提高此阈值可以避免这些对象过早晋升到 Old 区。
- 对于短生命周期的对象，减少晋升阈值可以避免它们占用过多的 Old 区内存。
（五）优化内存泄漏问题：定位与解决内存泄漏
内存泄漏是导致 Old GC 频繁的另一个常见原因。Java 应用中的内存泄漏通常表现为某些对象未被及时回收，占用了大量内存。常见的内存泄漏包括长时间持有对大对象的引用、静态引用、线程池中的线程等。
1. 原理分析
- 使用
jmap、arthas等工具进行堆 Dump，能够帮助我们识别哪些对象占用了异常大的内存。 - 通过对 Unreachable Objects（不可达对象）进行分析，查看它们的 Shallow Size 和 Retained Size，可以定位哪些对象未被及时回收。
- 通过 Histogram 分析对象分布，查找是否有异常的对象或类占用了大量内存。结合 incoming 和 outgoing 引用关系，可以定位对象的引用链和生命周期。
2. 建议配置与步骤
- 使用
jmap或arthas进行堆 Dump，获取内存快照。 - 通过 Histogram 分析对象的分布，关注那些占用大量内存的类。
- 使用
-XX:+HeapDumpOnOutOfMemoryError捕捉内存溢出时的堆 Dump 快照，帮助定位内存泄漏。 - 分析不可达对象（Unreachable Objects），关注 Shallow Size 和 Retained Size，找出长时间存活但未被回收的对象。
应用场景：
- 对于复杂业务逻辑，常常存在未释放的对象引用，导致内存泄漏。定期分析堆 Dump 文件，及时发现并解决这些问题。
- 使用
jprofiler或VisualVM等工具监控应用的内存使用情况，提前发现异常对象。
通过这些优化措施，我们可以有效降低 CMS Old GC 频繁触发的问题，提升系统的内存管理效率，减少 GC 对系统吞吐量和响应时间的影响。在实际操作过程中，建议结合实际应用负载、GC 日志分析和性能监控工具来进行动态调整，以达到最佳的内存管理效果。
四、总结
CMS Old GC 频繁触发不仅会对系统的吞吐量造成影响，还可能导致响应时间波动，严重时甚至可能影响到整个应用的稳定性。通过深入分析其触发原因和优化措施，我们可以采取一系列的解决方案来缓解或消除这一问题，从而提升系统的性能和响应能力。
-
合理配置 CMS 启动条件：通过调整
-XX:CMSInitiatingOccupancyFraction，提前触发 Old GC 回收，避免 Old 区过度占用内存，提高内存回收的及时性，从而减轻系统压力。 -
调整 GC 等待时间：合理设置
-XX:CMSWaitDuration，避免频繁轮询和回收。适当延长等待时间，可以减少不必要的 GC 触发，减轻系统负担。 -
启用 Class Unloading 功能：通过启用
-XX:+CMSClassUnloadingEnabled，回收 MetaSpace 或 PermGen 区域的内存，尤其在动态加载大量类的场景中，能够有效减轻 Old 区的内存压力，避免频繁的 Old GC。 -
控制对象晋升阈值：合理配置
-XX:MaxTenuringThreshold，避免对象过早晋升到 Old 区，减少 Old 区内存压力，降低频繁 Old GC 的可能性。 -
优化内存泄漏问题：内存泄漏是频繁 Old GC 的重要原因之一。通过堆 Dump 工具和分析方法，及时发现并解决内存泄漏问题，可以有效避免不必要的内存占用，减少 GC 的触发。
综上所述，频繁的 CMS Old GC 触发问题需要开发者在配置、内存管理、GC 策略等多个方面进行综合优化。除了调整 JVM 参数外，定期分析 GC 日志、使用性能监控工具、及时发现内存泄漏等手段都能帮助我们优化系统的 GC 行为，确保应用程序的稳定性和高效性。
感谢您的阅读，希望本文能够帮助您解决 CMS Old GC 频繁触发的问题，提升 Java 应用的性能。如果您有任何问题或建议，欢迎随时讨论！