Java性能调优随记

事情发生在16年了。当时系统beta版本进行上线前的性能压测时， 发现进程的内存占用率会持续升高，与之而来的时，性能的接口性能的持续下降。 最奇怪的是，停止压测后CPU和内存开销并没有恢复过来。 记得之前发过博文，不知道怎么回事找不到了。 应其他同事的要求，回忆一下当时的定位过程，再做一个简单分享。

在讲述整个过程前，请大家自备两个梯子：

1. Java虚拟机的垃圾回收机制

2. jmeter的基本使用知识

首先下载jmeter工具，感觉是一个轻量级的性能检测工具，很好用。 有基于windows 的GUI版本，也有在linux上运行的命令行版本。

下载地址：http://jmeter.apache.org/download_jmeter.cgi

怪象简述

刚开始压测时，一切指标都是正常的，也达到了预期水平。

8小时后，性能直线下降。

停止压测后，CPU和内存，仍然居高不下。 不要小看 2.4%的内存占用，这是200多G内存的物理服务器。 （后面部署方式已切换为虚拟机的部署方式）

定位解决

1. 首先命令行，看下java堆的情况：jmap -heap 24442

看见年老区的内存被占满了。

2. 继续执行命令：jsat –gcutil 24442 1000 5，

看见年老区 使用率 100%，同时执行了12304次 FullGC

3）查看进程24442的线程信息： ps –mp 24442 –o THREAD,tid,time

发现很多线程运行了好几个小时

这个时候，明显怀疑有内存泄露了。 再执行了两个命令（时间太久，没有找到截图了）：

jstat -printcompilation -h3 24442
jmap -histo 24442

进一步发现，内存中某个类的实例数量和String类的实例数量，异常的多。 最后在排查代码，找到了具体的类 及其使用逻辑。 发现是由于队列的使用不当，造成了内存泄露

总结

本项目中，因为涉及频繁的小IO，所以开发同事期望通过生产者－队列－消费者的模型， 用批量IO解决频繁小IO带来的资源开销。 但在使用此模型时，忘计考虑了极限状态下，生产者的输入能力远大于消费者的消费能力时， 会造成队列中的数据积压，进而造成内存泄露。 但又因为常规情况下不会出现 此场景，所以很难发现这个bug。

这个案例告诉我们：

1. 对于一些关键接口，开发同事可以在完成开发后， 自己用Jmeter压测一下，避免问题遗留到上线前期，造成巨大风险。

2. Java仍然会有内存泄露的情况，使用类似数组、队列、栈等数据结构时，需要格外小心。