关于java:JVM性能调优的6大步骤及关键调优参数详解

JVM 性能调优是一个十分重要的技能，本篇次要介绍 JVM 性能调优以下几点：

1.JVM 内存调优

2.JVM 性能调优办法

3.JVM 性能调优步骤

4.JVM 调优参数详解

JVM 内存调优

对 JVM 内存的零碎级的调优次要的目标是缩小 GC 的频率和 Full GC 的次数。

1.Full GC

会对整个堆进行整顿，包含 Young、Tenured 和 Perm。Full GC 因为须要对整个堆进行回收，所以比较慢，因而应该尽可能减少 Full GC 的次数。

2. 导致 Full GC 的起因

1)年轻代（Tenured）被写满

调优时尽量让对象在新生代 GC 时被回收、让对象在新生代多存活一段时间和不要创立过大的对象及数组防止间接在旧生代创建对象。

2)长久代 Pemanet Generation 空间有余

增大 Perm Gen 空间，防止太多动态对象，管制好新生代和旧生代的比例

3)System.gc()被显示调用

垃圾回收不要手动触发，尽量依附 JVM 本身的机制

在对 JVM 调优的过程中，很大一部分工作就是对于 FullGC 的调节，上面具体介绍对应 JVM 调优的办法和步骤。

JVM 性能调优办法和步骤

1. 监控 GC 的状态

应用各种 JVM 工具，查看以后日志，剖析以后 JVM 参数设置，并且剖析以后堆内存快照和 gc 日志，依据理论的各区域内存划分和 GC 执行工夫，感觉是否进行优化。

举一个例子：零碎解体前的一些景象：

•  每次垃圾回收的工夫越来越长，由之前的 10ms 缩短到 50ms 左右，FullGC 的工夫也有之前的 0.5s 缩短到 4、5s
•  FullGC 的次数越来越多，最频繁时隔不到 1 分钟就进行一次 FullGC
•  年轻代的内存越来越大并且每次 FullGC 后年轻代没有内存被开释

之后零碎会无奈响应新的申请，逐步达到 OutOfMemoryError 的临界值，这个时候就须要剖析 JVM 内存快照 dump。

2. 生成堆的 dump 文件

通过 JMX 的 MBean 生成以后的 Heap 信息，大小为一个 3G（整个堆的大小）的 hprof 文件，如果没有启动 JMX 能够通过 Java 的 jmap 命令来生成该文件。

3. 剖析 dump 文件

关上这个 3G 的堆信息文件，显然个别的 Window 零碎没有这么大的内存，必须借助高配置的 Linux，几种工具关上该文件：

•  Visual VM
•  IBM HeapAnalyzer
•  JDK 自带的 Hprof 工具
•  Mat(Eclipse 专门的动态内存剖析工具)举荐应用

备注：文件太大，倡议应用 Eclipse 专门的动态内存剖析工具 Mat 关上剖析。

4. 剖析后果，判断是否须要优化

如果各项参数设置正当，零碎没有超时日志呈现，GC 频率不高，GC 耗时不高，那么没有必要进行 GC 优化，如果 GC 工夫超过 1 - 3 秒，或者频繁 GC，则必须优化。

注：如果满足上面的指标，则个别不须要进行 GC：

•  Minor GC 执行工夫不到 50ms；
•  Minor GC 执行不频繁，约 10 秒一次；
•  Full GC 执行工夫不到 1s；
•  Full GC 执行频率不算频繁，不低于 10 分钟 1 次；

5. 调整 GC 类型和内存调配

如果内存调配过大或过小，或者采纳的 GC 收集器比较慢，则应该优先调整这些参数，并且先找 1 台或几台机器进行 beta，而后比拟优化过的机器和没有优化的机器的性能比照，并有针对性的做出最初抉择。

6. 一直的剖析和调整

通过一直的试验和试错，剖析并找到最合适的参数，如果找到了最合适的参数，则将这些 参数利用到所有服务器。

cms 参数优化步流程

上面我再持续介绍下 JVM 的要害参数配置(仅用于参考)。

JVM 调优参数参考

1. 针对 JVM 堆的设置，个别能够通过 -Xms -Xmx 限定其最小、最大值，为了避免垃圾收集器在最小、最大之间膨胀堆而产生额定的工夫，通常把最大、最小设置为雷同的值;

2. 年老代和年轻代将依据默认的比例（1：2）调配堆内存，能够通过调整二者之间的比率 NewRadio 来调整二者之间的大小，也能够针对回收代。

比方年老代，通过 -XX:newSize -XX:MaxNewSize 来设置其相对大小。同样，为了避免年老代的堆膨胀，咱们通常会把 -XX:newSize -XX:MaxNewSize 设置为同样大小。

3. 年老代和年轻代设置多大才算正当

1）更大的年老代必然导致更小的年轻代，大的年老代会缩短一般 GC 的周期，但会减少每次 GC 的工夫；小的年轻代会导致更频繁的 Full GC

2）更小的年老代必然导致更大年轻代，小的年老代会导致一般 GC 很频繁，但每次的 GC 工夫会更短；大的年轻代会缩小 Full GC 的频率

如何抉择应该依赖应用程序 对象生命周期的散布状况：如果利用存在大量的长期对象，应该抉择更大的年老代；如果存在绝对较多的长久对象，年轻代应该适当增大。但很多利用都没有这样显著的个性。

在抉择时应该根 据以下两点：

（1）本着 Full GC 尽量少的准则，让年轻代尽量缓存罕用对象，JVM 的默认比例 1：2 也是这个情理。

（2）通过观察利用一段时间，看其余在峰值时年轻代会占多少内存，在不影响 Full GC 的前提下，依据理论状况加大年老代，比方能够把比例控制在 1：1。但应该给年轻代至多预留 1 / 3 的增长空间。

4. 在配置较好的机器上（比方多核、大内存），能够为年轻代抉择并行收集算法：-XX:+UseParallelOldGC 。

5. 线程堆栈的设置：每个线程默认会开启 1M 的堆栈，用于寄存栈帧、调用参数、局部变量等，对大多数利用而言这个默认值太了，个别 256K 就足用。

实践上，在内存不变的状况下，缩小每个线程的堆栈，能够产生更多的线程，但这实际上还受限于操作系统。

以上

对于作者：mikechen，10 年 + 大厂架构教训，曾就任于阿里、淘宝、百度，分享架构技术教训以及心得！

浏览 mikechen 的更多技术文章合集

所有合集 |Java|JVM|MySQL|Redis| 分布式 | 微服务 | 高并发 | 中间件
| 架构师

关注作者公众号 mikechen 互联网架构，回复【架构】，即可支付作者《原创的 300 期 +BAT 架构技术系列文章与 1000+ 大厂面试题答案合集》。