深入理解Java虚拟机——（7）

上一篇：深入理解Java虚拟机——（6）

jvm调优案例分析与实战

一. 高性能硬件上的调优：

1. 采用64位操作系统，并为JVM分配大内存

我们知道，如果JVM中堆内存太小，那么就会频繁地发生垃圾回收，而垃圾回收都会伴随不同程度的程序停顿，因此，如果扩大堆内存的话可以减少垃圾回收的频率，从而避免程序的停顿。
因此，人们自然而然想到扩大内存容量。而32位操作系统理论上最大只支持4G内存，64位操作系统最大能支持128G内存，因此我们可以使用64位操作系统，并使用64位JVM，并为JVM分配更大的堆内存。但问题也随之而来。
堆内存变大后，虽然垃圾收集的频率减少了，但每次垃圾回收的时间变长。如果堆内存为14G，那么每次Full GC将长达数十秒。如果Full GC频繁发生，那么对于一个网站来说是无法忍受的。
因此，对于使用大内存的程序来说，一定要减少Full GC的频率，如果每天只有一两次Full GC，而且发生在半夜， 那完全可以接受。

要减少Full GC的频率，就要尽量避免太多对象进入老年代，可以有以下做法：

• 确保对象都是“朝生夕死”的
  一个对象使用完后应尽快让他失效，然后尽快在新生代中被Minor GC回收掉，尽量避免对象在新生代中停留太长时间。
• 提高大对象直接进入老年代的门槛
  通过设置参数-XX:PretrnureSizeThreshold来提高大对象的门槛，尽量让对象都先进入新生代，然后尽快被Minor GC回收掉，而不要直接进入老年代。

注意：使用64位JDK的注意点

1. 64位JDK支持更大的堆内存，但更大的堆内存会导致一次垃圾回收时间过长。
   现阶段，64位JDK的性能普遍比32位JDK低。
2. 堆内存过大无法在发生内存溢出时生成内存快照
3. 若将堆内存设为10G，那么当堆内存溢出时就要生成10G的大文件，这基本上是不可能的。
4. 相同程序，64位JDK要比32位JDK消耗更大的内存

2. 使用32位JVM集群

针对于64位JDK种种弊端，我们更多选择使用32位JDK集群来充分利用高性能机器的硬件资源。

如何实现？

在一台服务器上运行多个服务器程序，这些程序都运行在32位的JDK上。然后再运行个服务器作为反向代理服务器，由它来实现负载均衡。
由于32位JDK最多支持2G内存，因此每个虚拟结点的堆内存可以分配1.6G，一共运行10个虚拟结点的话，这台物理服务器可以拥有16G的堆内存。

有啥弊端？

1. 多个虚拟节点竞争共享资源时容易出现问题
   如多个虚拟节点共同竞争IO操作，很可能会引起IO异常。
2. 很难高效地使用资源池,
   如果每个虚拟节点使用各自的资源池，那么无法实现各个资源池的负载均衡。如果使用集中式资源池，那么又存在竞争的问题。
3. 每个虚拟节点最大内存为2G

二. 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. 不断的分析和调整

通过不断的试验和试错，分析并找到最合适的参数，如果找到了最合适的参数，则将这些参数应用到所有服务器

三. JVM调优参数参考

1. 针对JVM堆的设置，一般可以通过-Xms -Xmx限定其最小、最大值，为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间，通常把最大、最小设置为相同的值;

2. 年轻代和年老代将根据默认的比例（1：2）分配堆内存， 可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代。
   比如年轻代，通过 -XX:newSize -XX:MaxNewSize来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小。

3. 年轻代和年老代设置多大才算合理

   • 更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC
   • 更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次的GC时间会更短；大的年老代会减少Full GC的频率

   如何选择应该依赖应用程序对象生命周期的分布情况： 如果应用存在大量的临时对象，应该选择更大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大。但很多应用都没有这样明显的特性。
   在抉择时应该根 据以下两点：
   （1）本着Full GC尽量少的原则，让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理 。
   （2）通过观察应用一段时间，看其他在峰值时年老代会占多少内存，在不影响Full GC的前提下，根据实际情况加大年轻代，比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间。

4. 在配置较好的机器上（比如多核、大内存），可以为年老代选择并行收集算法： -XX:+UseParallelOldGC 。

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