JVM优化案例

最新推荐文章于 2025-08-12 16:23:23 发布

原创最新推荐文章于 2025-08-12 16:23:23 发布 · 618 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#jvm #java

JVM 专栏收录该内容

14 篇文章

订阅专栏

案例:金融系统
金融交易系统对实时性要求极高，任何一次长时间的垃圾回收停顿都可能导致交易延迟甚至失败。系统运行一段时间后，开发团队发现垃圾回收耗时过长，尤其是在高并发交易时，系统停顿时间增加，严重影响交易的实时性。

问题现象

垃圾回收耗时长：系统运行时，垃圾回收的停顿时间过长，尤其是在老年代的垃圾回收过程中。
系统停顿频繁：频繁的垃圾回收导致系统停顿，影响交易的实时性。
交易延迟增加：由于垃圾回收的停顿，交易响应时间变长，用户体验下降。

分析过程

监控垃圾回收日志
- 开启垃圾回收日志（-XX:+PrintGCDetails -Xloggc:gc.log），收集垃圾回收的详细信息。
- 分析日志发现，新生代的垃圾回收频率较高，但每次回收的耗时并不长。老年代的垃圾回收耗时较长，尤其是CMS（Concurrent Mark-Sweep）收集器的使用导致了长时间的停顿。
分析新生代和老年代的内存分配
- 使用jstat工具监控内存使用情况
```
jstat -gc <pid> 1000
```
- 发现新生代内存空间较小，对象很快就会被晋升到老年代。老年代内存使用率逐渐增加，导致频繁的Full GC。
分析垃圾回收器的选择
- 系统使用的是CMS收集器（-XX:+UseConcMarkSweepGC），虽然它是一个并发收集器，但在某些情况下（如内存碎片化严重时）会导致“并发失败”，进而触发Full GC，造成系统长时间停顿。

优化方案

1. 调整新生代和老年代内存分配

调整新生代内存大小：通过调整-XX:NewRatio参数，增加新生代内存空间，减少对象过早晋升到老年代的频率。
- 原参数：-XX:NewRatio=8（新生代占堆内存的1/9）
- 调整后：-XX:NewRatio=2（新生代占堆内存的1/3）
- 这样可以增加新生代的内存空间，减少新生代垃圾回收的频率。
调整Eden区和Survivor区的比例：通过调整-XX:SurvivorRatio参数，优化新生代中Eden区和Survivor区的比例。
- 原参数：-XX:SurvivorRatio=8（每个Survivor区占新生代的1/10）
- 调整后：-XX:SurvivorRatio=4（每个Survivor区占新生代的1/6）
- 这样可以增加Survivor区的内存空间，减少对象在新生代中的复制次数，降低晋升到老年代的风险。

2. 更换垃圾回收器

更换老年代垃圾回收器：将老年代的垃圾回收器从CMS更换为Parallel Old收集器。
- 原参数：-XX:+UseConcMarkSweepGC
- 调整后：-XX:+UseParallelOldGC
- Parallel Old收集器是一个并行的垃圾回收器，适用于多核服务器，能够更高效地回收老年代的内存。

3. 启用自适应内存管理策略

启用自适应内存管理策略：通过-XX:+UseAdaptiveSizePolicy参数，让JVM根据当前的垃圾回收情况自动调整内存分配策略。
- 这样可以减少手动调优的复杂性，同时让JVM根据实际运行情况动态调整内存分配，提高垃圾回收的效率。

调整后的JVM启动参数

-Xms4g -Xmx4g -XX:NewRatio=2 -XX:SurvivorRatio=4 -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy -XX:+PrintGCDetails -Xloggc:gc.log

优化效果

垃圾回收耗时显著减少：老年代的垃圾回收时间从原来的数秒减少到几百毫秒，系统停顿时间大幅缩短。
系统停顿频率降低：由于新生代内存空间增加，对象晋升到老年代的频率降低，老年代的垃圾回收次数减少。
交易实时性提升：系统停顿时间减少，交易响应时间显著缩短，用户体验得到改善。

总结

通过调整新生代和老年代的内存分配比例、更换垃圾回收器以及启用自适应内存管理策略，成功解决了金融交易系统垃圾回收耗时过长的问题。这些优化措施不仅减少了垃圾回收的停顿时间，还提高了系统的整体性能和实时性。

针对如何发现的垃圾回收耗时长的问题进行解答:

1. 监控工具

监控工具是发现垃圾回收问题的常用手段。以下是一些常用的监控工具及其使用方法：

JVisualVM

功能：JVisualVM是一个可视化工具，可以实时监控JVM的内存使用情况、垃圾回收活动等。
使用方法：
1. 启动JVisualVM工具（通常在JDK的bin目录下）。
2. 连接到目标Java进程。
3. 在“监视”标签页中查看“堆”和“GC活动”。
4. 观察垃圾回收的频率和每次垃圾回收的耗时。
  - 如果发现垃圾回收的停顿时间过长（例如超过几百毫秒甚至秒级），则表明垃圾回收耗时过长。

JConsole

功能：JConsole也是一个JVM监控工具，可以实时查看垃圾回收的详细信息。
使用方法：
1. 启动JConsole工具。
2. 连接到目标Java进程。
3. 在“内存”标签页中查看“堆内存使用情况”和“垃圾回收活动”。
4. 观察垃圾回收的频率和每次垃圾回收的耗时。

VisualVM

功能：VisualVM是一个更强大的监控工具，支持实时监控和历史数据记录。
使用方法：
1. 启动VisualVM工具。
2. 连接到目标Java进程。
3. 在“监视”标签页中查看“堆内存使用情况”和“垃圾回收活动”。
4. 观察垃圾回收的频率和每次垃圾回收的耗时。
5. 可以通过“垃圾回收日志”选项查看详细的垃圾回收日志。

2. 垃圾回收日志

垃圾回收日志是分析垃圾回收问题的重要依据。通过开启垃圾回收日志，可以详细记录每次垃圾回收的耗时、回收的内存大小等信息。

开启垃圾回收日志

在JVM启动参数中加入以下参数：

-XX:+PrintGCDetails -Xloggc:gc.log

-XX:+PrintGCDetails：打印垃圾回收的详细信息。
-Xloggc:gc.log：将垃圾回收日志输出到指定的文件（gc.log）。

分析垃圾回收日志

垃圾回收日志会记录每次垃圾回收的详细信息，例如：

[GC (Allocation Failure) [PSYoungGen: 123456K->12345K(123456K)] 123456K->12345K(123456K), 0.0123456 secs] [Times: user=0.12 sys=0.01, real=0.02 secs]

[GC (Allocation Failure)：表示这次垃圾回收是因为内存分配失败触发的。
[PSYoungGen: 123456K->12345K(123456K)]：表示新生代内存从123456K减少到12345K，总容量为123456K。
123456K->12345K(123456K)：表示整个堆内存从123456K减少到12345K，总容量为123456K。
0.0123456 secs：表示这次垃圾回收耗时0.0123456秒。
[Times: user=0.12 sys=0.01, real=0.02 secs]：表示用户态时间、系统态时间和实际耗时。