跟我一起学JVM(四)——JVM调优总结与实例

Java虚拟机对于内存的管理和垃圾收集是虚拟机结构中非常重要的一环，对提升程序的性能和稳定性有着非常重要的作用

对于JVM的调优是没有正确答案的，需要根据项目的实际情况来配置合适的JVM参数。

（一）尽量减少Full GC的发生

通过之前的学习，我们知道老年代发生的GC速度比新生代速度慢十倍左右，那么如果想要提高性能，减少老年代的Full GC是非常有用的

如何减少Full GC的发生？
1.提高大对象进入老年代的难度，进入老年代的东西少了，执行Full GC的次数自然就变小了
2.确保对象的生命周期不会很长，并且不长时间占用新生代内存空间，这样大部分对象就可以在Minor GC被回收掉，不会被保留到老年代中。

（二）养成良好代码编写习惯，从源头节约资源，避免占用过多内存

实例：一个后台RPC服务器，使用的64位虚拟机，平时对外服务的Minor GC时间30毫秒以内，用户完全可以接受，但是业务上有个功能每十分钟加载80MB的数据文件到内存进行数据分析，这些数据会在内存中形成100万个HashMap<Long, Long> entry,此时的Minor GC将造成超过500毫秒的停顿，用户肯定是接受不了的。

分析：此处我们可以大致计算一下使用HashMap去存储的空间效率，该HashMap有效数据是key和value中存放的2*8B数据，但是一旦转变成Long对象，则需要添加对象头，存储时候为了内存对齐，又会浪费掉一部分的内存空间。综上最后的空间效率大概是18%，剩下的82%空间可以说都是被浪费掉的。

结论：在编写代码的时候要选择恰当的数据结构，提高空间利用效率，避免创造大对象从而造成老年代GC频繁的问题。

（三）使用恰当的高性能硬件程序部署策略

目前在高性能硬件上部署程序有两种方式
1.使用64位JDK来使用大内存
2.使用若干个32位虚拟机建立逻辑集群利用硬件资源

分析：由于大内存虽然扩充了空间，但是内存回收会导致长时间的停顿，而且32位JDK性能测试结果普遍低于64位JDK，所以大部分网站依旧采用了第二种方式进行构建。

（四）考虑Java堆外内存的溢出错误

实例：有个学校B/S考试系统，32位，堆1.6G，在测试时候时不时出现内存溢出问题，通过jstat发现GC并不频繁，新生代和老年代的内存空间也是正常情况，说明并不是Java堆的OOM，通过打印系统日志找到异常堆栈，显示在java.nio.ByteBuffer.allocateDirect…发生OOM错误。

分析：这是因为直接内存可能会导致内存溢出，直接内存是在堆之外的内存空间，也是由Java虚拟机管辖，但是直接内存的垃圾回收只是发生在Full GC阶段，虚拟机清理老年代时候顺便也清理一下直接内存，但是如果老年代不需要清理，那么直接内存也得不到清理。程序使用NIO又是非常占用直接内存的资源的，所以直接内存空间就会发生OOM错误。

（五）分析JVM崩溃情况

实例：异步请求（客户端向服务器发送HTTP请求后将请求和后续的过程委托给一个线程执行，而自己去做其他事情，所有的连接通信都由被委托的线程执行，这样可以有效的提高系统运行效率）该系统运行一段时间后出现了进程崩溃的情况，查看日志得到SocketException: Connection reset 这个错误是连接异常

分析：因为异步处理连接，但是远端服务器处理速度过慢，导致大量线程无法快速结束，始终处于等待状态。随着时间流逝，系统创建了大量线程，并且大部分都处于等待状态。线程的堆积，资源的使用最终超过了虚拟机的承受能力，从而使JVM崩溃。

喜欢请三连哦～

---

Instagram: https://www.instagram.com/barrywzc/
Twitter: https://twitter.com/BarryWa34098316
Bilibili: https://space.bilibili.com/473161964
GitHub: https://github.com/wzcwzcwzc
Patreon: https://www.patreon.com/wzcspace
WeChat: wzcspace

---

Please leave a LIKE and SUBSCRIBE for more content!