JVM：浅谈JVM调优策略

多数的Java应用不需要在服务器上进行GC优化，虚拟机内部已有很多优化来保证应用的稳定运行，所以不要为了调优而调优，不当的调优可能适得其反。在应用上线之前，先考虑将机器的JVM参数设置到最优（适合）。

在进行GC优化之前，需要确认项目的架构和代码等已经没有优化空间。我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过GC优化令其性能达到一个质的飞跃。

GC优化是一个系统而复杂的工作，没有万能的调优策略可以满足所有的性能指标。GC优化必须建立在我们深入理解各种垃圾回收器的基础上，才能有事半功倍的效果。

1、Heap内存（老年代）持续上涨达到设置的最大内存值。

2、Full GC 次数频繁。

3、GC 停顿（Stop World）时间过长（超过1秒，具体值按应用场景而定）。

4、应用出现OutOfMemory 等内存异常。

5、应用出现OutOfDirectMemoryError等内存异常（ failed to allocate 16777216 byte(s) of direct memory (used: 1056964615, max: 1073741824)）。

6、应用中有使用本地缓存且占用大量内存空间。

7、系统吞吐量与响应性能不高或下降。

8、应用的CPU占用过高不下或内存占用过高不下。

吞吐量=用户代码时间 / （用户代码执行时间 + 垃圾回收时间）。是评价垃圾收集器能力的重要指标之一，是不考虑垃圾收集引起的停顿时间或内存消耗，垃圾收集器能支撑应用程序达到的最高性能指标。吞吐量越高算法越好。

STW越短，响应时间越好。评价垃圾收集器能力的重要指标，度量标准是缩短由于垃圾收集引起的停顿时间或完全消除因垃圾收集所引起的停顿，避免应用程序运行时发生抖动。暂停时间越短算法越好。

MinorGC尽可能多的收集垃圾对象。我们把这个称作MinorGC原则，遵守这一原则可以降低应用程序FullGC 的发生频率。FullGC 较耗时，是应用程序无法达到延迟要求或吞吐量的罪魁祸首。

（1）统计Minor GC 持续时间

（2）统计Minor GC 的次数

（3）统计Full GC的最长持续时间

（4）统计最差情况下Full GC频率

（5）统计GC持续时间和频率对优化堆的大小是主要着手点

我们按照业务系统对延迟和吞吐量的需求，在按照这些分析我们可以进行各个区大小的调整。

一般来说吞吐量优先的垃圾回收器：-XX:+UseParallelGC -XX:+UseParallelOldGC，即常规的（PS/PO）。

响应时间优先的垃圾回收器：CMS、G1。

Xms 是指设定程序启动时占用内存大小。一般来讲，设置大点，程序会启动的快一点，但是也可能会导致机器暂时变慢。

Xmx 是指设定程序运行期间最大可占用的内存大小。如果程序运行需要占用更多的内存，超出了这个设置值，就会抛出OutOfMemory异常。

Xss 是指设定每个线程的堆栈大小。这个就要依据你的程序，看一个线程大约需要占用多少内存，可能会有多少线程同时运行等。

（1）高优先级：-XX:NewSize/-XX:MaxNewSize

（2）中优先级：-Xmn（默认等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?）

（3）低优先级：-XX:NewRatio

如果想在日志中追踪类加载与类卸载的情况，可以使用启动参数 -XX:TraceClassLoading -XX:TraceClassUnloading。

1、MAT：提示可能的内存泄露的点。

2、jvisualvm

3、jconsole

4、Arthas

5、show-busy-java-threads GitHub链接