JVM实战调优（一）

去年交付给客户现场的大数据分析展示平台，在交付初期出现了几个性能问题，今天对问题的排查和处理做一个总结。
该系统主要对一些底层的设备数据做相关性分析处理，然后展示在网页上。系统在开发测试环境都是正常稳定的，客户现场部署后的试用初期也OK，但第二个月工厂开始增加设备后，系统查询分析结果十分缓慢。

场景1

查询报表时，数据分析结果返回十分缓慢

排查定位

1. 发现数据分析接口返回的时间在10s~30s不等，简直不能忍，初步怀疑数据返回量过大浏览器渲染慢导致， 我打开浏览器控制台，发现数据量很小且做了分页返回，排除；
2. 进入linux服务器，top 发现有运行web服务的java进程CPU居然一度飙升到100%，内存使用反而很低，于是怀疑某些线程操作阻塞了。赶紧top -h 进程id观察哪个线程cpu占比最高，使用jstacK 线程id > jdump.txt 创建当前时刻的线程快照；
3. 使用 printf “%x\n” 线程id 为获取该线程的16进制id，在jdump中定位日志发现：大量线程在wating on condition，然后发现整个日志大量wating on同一把锁，于是根据 parking to wait for <0x000000073168d480> 中wait的对象进行查找，看是哪一个拥有该对象的线程在Runnable，于是定位到具体的代码行中；
4. 发现在查询收率分析数据的时候，会调用python脚本分析数据的相关性在返回（上了锁，python每次分析只能有一个线程在调用（可能有中间数据），否则分析结果会错误），由于现场数据量比较大，执行时间过长，当前锁不释放，导致资源等待；

解决方案

优化调用分析结果的逻辑，不做实时计算，定时任务分析每10分钟的相关性数据存在mysql库里，减轻web查询的压力。

优化后每次查询都在1.5s以内，恢复正常。

场景2

系统使用偶尔卡顿，体验不好

排查定位

1. 通过top查看cpu正常，不足百分之5%，使用 jstat -gcutil 打印GC日志，发现fullGC十分频繁，且老年代空间总是接近溢出。考虑到触发JVM进行Full GC的情况；
   考虑到触发JVM进行Full GC的情况主要有以下三种：

• System.gc()方法的调用
• 老年代空间不足
• 永生区空间不足

2. 此刻堆内存占用并不多，考虑是否存在一个大对象，进入到老年代导致fullGC？ 为了定位到有大对象的创建存在，使用jmap -histo:live （慎用，会产生一次FullGC）发现了一个 [C 的对象数组占比特别高
3. 导出整个JVM 中内存信息jmap -dump:format=b,file=文件名 [pid]
4. 然后使用Jhat（JVM Heap Analysis Tool）命令与jmap搭配使用，用来分析jmap生成的dump，jhat内置了一个微型的HTTP/HTML服务器，生成dump的分析结果后，可以在浏览器中查看。
   进入 Heap Histogram界面，查看实例数据最多和占用资源最大的类，并且追溯到工程代码，发现：web前端会轮询后台一个数据实时更新的接口，而接口的实现是先从数据把半年的数据load到java内存中，然后做了一个统计并返回数据。也就意味着每次轮询，都会产生大数组对象了，那么改对象直接就进入老年代，导致老年代空间不足，频繁回收。

解决方案

1. 优化代码逻辑，在sql层面做一些合理统计只返回需要的数据load到java中。
2. JVM启动参数：调整各代的内存比例，提高老年代大小。
   在 -Xmx（堆最大内存）不变的情况下，对-Xmn（年轻代大小）进行一些减少，老年代的最大内存 = 堆内存 - 新生代 最大内存。
   从而提升了老年代的空间。
3. 基于当前响应时间优先的业务场景，更改老年代垃圾回收算法，从PS+PO的方式改成PS+CMS（并发标记清除，最小停顿时间为目的）方式。

对于CMS的一些说明：

CMS是针对老年代进行回收的一款并发、使用标记-清除算法的GC
CMS有什么用？
CMS以获取最小停顿时间为目的。
在一些对响应时间有很高要求的应用或网站中，用户程序不能有长时间的停顿，CMS 可以用于此场景。
CMS如何执行？
总体来说CMS的执行过程可以分为以下几个阶段：
1 初始标记(STW)
2 并发标记
3 并发预清理
4 重标记(STW)
5 并发清理
6 重置
CMS缺点？
1.CMS回收器采用的基础算法是Mark-Sweep。所有CMS不会整理、压缩堆空间
2.CMS需要更多的CPU资源。
3.CMS需要更大的堆空间。
4.CMS回收器减少了回收的停顿时间，但是降低了堆空间的利用率。

至此，系统恢复正常。