JVM调优6大步骤

对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。

参考博客: https://www.cnblogs.com/Darrenblog/p/10712125.html
1.Full GC

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

2.导致Full GC的原因

1)年老代（Tenured）被写满

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

2)持久代Permanent 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就足用。

理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

######################

JVM调优面试题

一,你接触过JVM调优吗?

答: 接触过,用的不是很多吧.
当我们遇到了OutOfMemory等内存异常,GC停顿时间过长,Full GC次数频繁,或系统吞吐量与响应性能不高时,首先我们查找代码有没有问题,进行代码优化,如果代码没问题,我们就要考虑进行JVM调优.
首先我们要打印出GC日志,还有使用分析各种性能参数,判断是否需要优化,确定瓶颈问题.
然后我们需要确定JVM调优量化的目标;
然后我们根据他的历史参数来调整JVM的参数;现在一台机器上进行测试;
然后通过不断地分析和调整,直到找到合适的JVM参数配置;
最后我们将参数应用到所有的服务器,并进行后续的跟踪.

//一般我们在谈到JVM调优时会涉及三个指标: 内存占用量,系统延迟和系统吞吐量.
1,内存占用: 系统运行时,java虚拟机需要的内存.
2,延迟: 系统运行过程中由于垃圾收集引起的暂停时间.
3,吞吐量: 单位时间内完成的任务数量.
jvm调优的目的是追求更低的系统延迟和更高的系统吞吐量,衡量锡系统在稳定状态下所需要的最低内存占用量.

二,触发Full GC的场景及应对策略
触发Full GC的场景及应对策略:
1>System.gc()方法的调用. 应对策略: 垃圾回收不要手动触发,尽量依靠JVM自身的机制.
2>老年代空间不足, 应对策略: 调优时尽量让对象在新生代GC时被回收,让对象在新生代多存活一段时间和不要创建过大的对象及数组,避免直接在老年代创建对象.
3>永久区空间不足,应对策略: 增大持久代空间,避免太多静态对象,控制好新生代和老年代的比例.
4>内存持续增长达到上限导致Full GC, 应对策略: 通过dumpheap分析是否存在内存泄漏.
5>GC时出现promotionfailed和concurrent mode failure, 应对策略: 增大survivor space
6>Minor GC后晋升到旧生代的对象大小大于老年代的剩余空间, 应对策略: 增大老年代空间或下调CMSInitiatingOccupancyFraction=60;

三java的虚拟机堆的结构
java虚拟机把堆内存划分为三个区域:年轻代,老年代,和永久代.
1,年轻代:
年轻代又分为一个Eden区和两个Survivor区(一个from Survivor和一个to Survivor),每次只会使用Eden和其中一个Survivor区,这么分配的原因是年轻代采用了”复制”算法来回收.当创建新的对象时,(大部分情况下)这个对象所占的空间会在Eden区分配,如果Eden区的空闲空间不足,这时虚拟机会触发一次Minor GC,将Eden区和from Survivor区中还存活的对象转移到to Survivor区中. 在经历若干次Minor GC之后,如果对象还是存活,那就会被移到老年代中去.
2,老年代(old)
存放系统中长期存活的对象,比如通过spring托管的一些单例对象,如service对象,dao对象等.还有一部分是在Minor GC后年轻代的空间仍然不足时,从年轻代转移过来的对象,这部分对象一般是导致系统发生Full GC的主要原因.
3,永久代(perm)
存储已被虚拟机加载的类信息,常量,静态变量,即时编译器编译后的代码等数据.

参考博客:http://ouyblog.com/2016/10/JVM%E8%B0%83%E4%BC%98
https://www.jianshu.com/p/c6a04c88900a
https://www.jianshu.com/p/1045d8a24765
https://blog.csdn.net/jisuanjiguoba/article/details/80176223