《深入理解Java虚拟机》调优案例分析与实战

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

上节学习回顾

在上一节当中，主要学习了Sun JDK的一些命令行和可视化性能监控工具的具体使用，但性能分析的重点还是在解决问题的思路上面，没有好的思路，再好的工具也无补于事。

本节学习重点

在书本上本节的主要内容是讲作者在工作过程中对调优的一些经验实战。对于我们读者来说，重点是学习作者分析解决问题的具体思路。当然不能离开书本的内容，作者利用的是上一节所介绍到的工具去解决他所遇到的问题。但本人的工作环境跟书本上的教程不一致，但思路大同小异。所以在本章的学习笔记当中，还是结合自身的情况，聊聊调优这事吧。

我的工作环境

在上一节学习已经提过，由于本人的工作环境关系，使用的大都是IBM产品，包括服务器、中间件等，其中Java虚拟机就是IBM的J9虚拟机。它跟HotSpot多少还有点不同，由于IBM的资料甚少，所以对JVM调优也是一个难点。到目前为止，我们只能通过WAS控制台对JVM参数进行不断的修改尝试对比，找出比较优的方案。而IBM的产品都是一套完整的解决方案，WAS同时提供了对应用的参数跳转、对虚拟机的运行监控等都集成在一个控件台里面，如下如所示：

调整JVM参数的页面如下：

性能监控主页如下：

性能监控有许多项目可以自行选择，例如JDBC连接池、JVM运行情况、WEB容器线程池等，其中WEB容器与JVM运行情况监控如下图所示：

通过上图的曲线图看观察JVM堆内存使用走向，通过曲线也大概可以看出GC的情况。

一次调优经历

最难忘的一次调优就是2014年巴西世界杯，7天7夜下来最悲剧的莫过于你们在看世界杯，而我们却在日夜维护系统的世界杯活动。隐约记得参与活动人数大概上百万左右，系统经常性罢工，所以只好临时日夜不停地边维护边修复调优。问题大概是到了某个并发瓶颈，系统就会慢下来，甚至阻塞。由于是生产环境的线上活动，客户要求不能停止活动，哪怕阻塞了，也要求通过重启暂时恢复。所以我们的排查工作更难了，为了重现现象，我们需要等待瓶颈出现的那点时间日夜蹲守排查。通过对服务器指标的观察，都不是瓶颈所在。最后通过Kill -3间隔输出多个javacore文件进行线下分析，才找出问题所在。而这个javacore文件我们是通过“IBM Thread and Monitor Dump Analyzer for Java”这个软件进行分析的，如下如所示：