面试题：Java虚拟机性能调优之GC调优策略

Question

假设一个Java应用程序频繁发生Full GC，导致系统响应变慢。请描述你会采取哪些步骤来诊断问题，并给出可能的调优策略，包括对垃圾回收器的选择和相关参数调整。

Answer 1

诊断问题步骤

1. 收集GC日志：
   • 在启动应用程序时添加-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/path/to/gc.log参数，生成详细的GC日志，记录每次GC的时间、类型、回收的内存大小等信息。
2. 分析GC日志：
   • 查看Full GC频率：通过日志确定Full GC发生的频繁程度。若频繁发生，可能是堆内存设置不合理或者存在内存泄漏。
   • 检查回收的内存量：观察每次Full GC回收的内存大小。若回收量很少，可能存在大量短期存活对象进入老年代。
   • 分析对象晋升情况：查看对象从新生代晋升到老年代的年龄分布，判断是否过早晋升。
3. 监控内存使用情况：
   • 使用JMX工具：如VisualVM、JConsole，连接到运行中的Java进程，实时监控堆内存、非堆内存的使用情况，以及各个内存区域（新生代、老年代、永久代/元空间）的变化趋势。
   • 内存分析工具：例如MAT（Eclipse Memory Analyzer），在应用程序发生Full GC后，生成堆转储文件（-XX:+HeapDumpOnOutOfMemoryError），使用MAT分析文件，查找可能存在的大对象或内存泄漏点。
4. 检查代码：
   • 查找大对象创建：审查代码，寻找可能一次性创建大量对象或者创建大对象的地方，例如大数据量的集合、未及时释放的资源等。
   • 检查对象生命周期：确保对象在使用完毕后及时释放，避免长时间持有导致内存无法回收。

调优策略

1. 垃圾回收器选择：
   • 新生代回收器：
     • Serial：简单高效，单线程回收，适用于客户端应用或小内存应用。
     • ParNew：Serial的多线程版本，可与CMS等老年代回收器配合使用，适用于多核CPU环境，在新生代回收性能较好。
     • Parallel Scavenge：关注吞吐量，适用于对响应时间要求不高，但追求高吞吐量的应用。
   • 老年代回收器：
     • Serial Old：Serial的老年代版本，单线程回收，通常与Serial新生代回收器配合，适用于客户端应用。
     • Parallel Old：与Parallel Scavenge新生代回收器配合，注重吞吐量，适合追求高吞吐量的应用。
     • CMS（Concurrent Mark Sweep）：低停顿，并发收集老年代垃圾，适用于对响应时间敏感的应用，但可能存在内存碎片问题。
     • G1（Garbage - First）：适用于大内存应用，可预测停顿时间，兼顾吞吐量和低停顿，是Java 9及以后的默认垃圾回收器。
2. 相关参数调整：
   • 堆内存大小调整：
     • -Xms：设置初始堆大小，一般建议与 -Xmx 相同，避免堆动态扩展带来的性能开销。
     • -Xmx：设置最大堆大小，根据应用程序的内存需求合理设置，避免过小导致频繁Full GC，过大则可能增加每次GC的时间。
   • 新生代相关参数：
     • -Xmn：设置新生代大小，一般建议为堆大小的1/3到1/4。过大可能导致老年代空间过小，过小则可能导致对象频繁晋升到老年代。
     • -XX:SurvivorRatio：设置Eden区与Survivor区的比例，常见值为8，即Eden区占新生代的8/10，两个Survivor区各占1/10。
   • 老年代相关参数：
     • 针对CMS：
       • -XX:CMSInitiatingOccupancyFraction：设置CMS开始回收的老年代占用比例，默认值68%，可根据应用情况适当调整，避免过早或过晚启动CMS回收。
       • -XX:+UseCMSCompactAtFullCollection：在Full GC后进行压缩，减少内存碎片。
       • -XX:CMSFullGCsBeforeCompaction：设置执行多少次Full GC后进行压缩，避免频繁压缩带来的性能开销。
     • 针对G1：
       • -XX:G1HeapRegionSize：设置G1堆内存区域大小，可根据堆大小和应用情况调整，默认值会根据堆大小自动计算。
       • -XX:MaxGCPauseMillis：设置最大GC停顿时间目标，G1会尽量满足此目标，但可能会影响吞吐量。