线上JVM性能优化详解
概述
jvm中除了程序计数器，其他的区域都有可能会发生内存溢出
内存溢出是什么？
当程序需要申请内存的时候，由于没有足够的内存，此时就会抛出OutOfMemoryError，这就是内存溢出
内存溢出和内存泄漏有什么区别？
内存泄漏是由于使用不当，把一部分内存“丢掉了”，导致这部分内存不可用。
当在堆中创建了对象，后来没有使用这个对象了，又没有把整个对象的相关引用设为null。此时垃圾收集器会认为这个对象是需要的，就不会清理这部分内存。这就会导致这部分内存不可用。
所以内存泄漏会导致可用的内存减少，进而会导致内存溢出。
用到的jvm参数
下面为了说明溢出的情景，会执行一些实例代码，同时需要给jvm指定参数
- -Xms 堆最小容量(heap min size)
- -Xmx 堆最大容量(heap max size)
- -Xss 栈容量(stack size)
- -XX:PermSize=size 永生代最小容量
- -XX:MaxPermSize=size 永生代最大容量
堆溢出
堆是存放对象的地方，那么只要在堆中疯狂的创建对象，那么堆就会发生内存溢出。
下面做一个堆溢出的实验
执行这段代码的时候，要给jvm指定参数
//jvm参数：-Xms20m -Xmx20m
public class HeapOOMTest {
public static void main(String[] args){
LinkedList<HeapOOMTest> l=new LinkedList<HeapOOMTest>();//作为GC Root
while(true){
l.add(new HeapOOMTest());//疯狂创建对象
}
}
}
-Xms20m -Xmx20m作用是将jvm的最小堆容量和最大堆容量都设定为20m，这样就不会动态扩展jvm堆了
这段代码疯狂的创建对象，虽然对象没有声明变量名引用，但是将对象添加到队列l中，这样队列l就持有了一份对象的引用
通过可达性算法(jvm判断对象是否可被收集的算法)分析，队列l作为GC Root，每一个对象都是l的一个可达的节点，所以疯狂创建的对象不会被收集，这就是内存泄漏，这样总有一天堆就溢出了。
运行结果：
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.LinkedList.linkLast(Unknown Source)
at java.util.LinkedList.add(Unknown Source)
at test.HeapOOMTest.main(HeapOOMTest.java:23)
程序发生内存溢出，并提示发生在Java heap space
分析解决方法
思路
用visualVM工具分析堆快照
如果发生内存泄漏：
step1:找出泄漏的对象
step2:找到泄漏对象的GC Root
step3:根据泄漏对象和GC Root找到导致内存泄漏的代码
step4:想法设法解除泄漏对象与GCRoot的连接
如果不存在泄漏:
- 看下是否能增大jvm堆的最大容量
- 优化程序，减小对象的生命周期
前期准备
当发生堆溢出的时候，可以让程序在崩溃时产生一份堆内存快照
产生堆内存快照的方法：
给jvm加上参数XX:+HeapDumpOnOutofMemoryError，这样就会在程序崩溃的时候，产生一份堆内存快照
分析堆内存快照我建议用jdk自带的可视化监视工具visualVM，位置在jdk安装目录下的bin，如果是在linux环境的话，可以把快照传到window。因为分析工具会占用很大的内存，不建议在服务端进行分析。
栈溢出
调用方法的时候，会在栈中入栈一个栈帧，如果当前栈的容量不足，就会发生栈溢出StackOverFlowError
那么只要疯狂的调用方法，并且有意的不让栈帧出栈就可以导致栈溢出了。
下面来一次栈溢出
//jvm参数:-Xss128k
public class StackSOFTest {
public void stackLeak(){
stackLeak();//递归，疯狂的入栈，有意不让出栈
}
public static void main(String[] args){
StackSOFTest s=new StackSOFTest();
s.stackLeak();
}
}
jvm设置参数-Xss128k，目的是缩小栈的空间，这样栈溢出“来的快一点”
程序中用了递归，让栈帧疯狂的入栈，又不让栈帧出栈，这样就会栈溢出了。
运行结果：
Exception in thread "main" java.lang.StackOverflowError
at test.StackSOFTest.stackLeak(StackSOFTest.java:17)
at test.StackSOFTest.stackLeak(StackSOFTest.java:17)
运行时常量池溢出
这里储存的是一些常量、字面量。如果运行时常量池内存不足，就会发生内存溢出。从jdk1.7开始，运行时常量池移动到了堆中，所以如果堆的内存不足，也会导致运行时常量池内存溢出。
下面来一次运行时常量池溢出，环境是jdk8
只要创建足够多的常量，就会发生溢出
/**
* jvm参数：
* jdk6以前：-XX:PermSize=10M -XX:MaxPermSize=10M
* jdk7开始：-Xms10m -Xmx10m
* */
public class RuntimePoolOOM {
public static void main(String[] args){
int i=1;
LinkedList<String> l=new LinkedList<String>();//保持常量的引用，防止被fullgc收集
while(true){
l.add(String.valueOf(i++).intern());//将常量添加到常量池
}
}
}
因为jdk6以前，运行时常量池是在方法区（永生代）中的，所以要限制永生代的容量，让内存溢出来的更快。
从jdk7开始，运行时常量池是在堆中的，那么固定堆的容量就好了
这里用了链表去保存常量的引用，是因为防止被fullgc清理，因为fullgc会清理掉方法区和老年代
intern()方法是将常量添加到常量池中去，这样运行时常量池一直都在增长，然后内存溢出
运行结果：
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.lang.Integer.toString(Unknown Source)
at java.lang.String.valueOf(Unknown Source)
at test.RuntimePoolOOM.main(RuntimePoolOOM.java:30)
提示在heap区域发生内存溢出，果然运行时常量池被移到了堆中
方法区溢出
方法区是存放类的信息，而且很难被gc，只要加载了大量类，就有可能引起方法区溢出
这里将不做演示了，想试试的可以用cglib创建大量的代理类
分析
工作中也有可能会遇上方法区溢出：
当多个项目都有相同jar包的时候，又都存放在WEB-INF\lib\下，这样每个项目都会加载一遍jar包。会导致方法区中有大量相同类（被不同的类加载器所加载），又不会被gc掉。
解决方案：
-
在应用服务器中建立一个共享lib库，把项目中常用重复的jar包存放在这里，项目从这里加载jar包，这样就会大大减少类加载的数量，方法区也“瘦身”了
-
如果实在不能瘦身类的话，那可以扩大方法区的容量，给jvm指定参数-XX:MaxPermSize=xxxM
性能调优
性能调优包含多个层次，比如：架构调优、代码调优、JVM调优、数据库调优、操作系统调优等。
架构调优和代码调优是JVM调优的基础，其中架构调优是对系统影响最大的。
性能调优基本上按照以下步骤进行：明确优化目标、发现性能瓶颈、性能调优、通过监控及数据统计工具获得数据、确认是否达到目标。
何时进行JVM调优
遇到以下情况，就需要考虑进行JVM调优了：
- Heap内存（老年代）持续上涨达到设置的最大内存值；
- Full GC 次数频繁；
- GC 停顿时间过长（超过1秒）；
- 应用出现OutOfMemory 等内存异常；
- 应用中有使用本地缓存且占用大量内存空间；
- 系统吞吐量与响应性能不高或下降。
JVM调优的基本原则
JVM调优是一个手段，但并不一定所有问题都可以通过JVM进行调优解决，因此，在进行JVM调优时，我们要遵循一些原则：
- 大多数的Java应用不需要进行JVM优化；
- 大多数导致GC问题的原因是代码层面的问题导致的（代码层面）；
- 上线之前，应先考虑将机器的JVM参数设置到最优；
- 减少创建对象的数量（代码层面）；
- 减少使用全局变量和大对象（代码层面）；
- 优先架构调优和代码调优，JVM优化是不得已的手段（代码、架构层面）；
- 分析GC情况优化代码比优化JVM参数更好（代码层面）；
通过以上原则，我们发现，其实最有效的优化手段是架构和代码层面的优化，而JVM优化则是最后不得已的手段，也可以说是对服务器配置的最后一次“压榨”。
JVM调优目标
调优的最终目的都是为了令应用程序使用最小的硬件消耗来承载更大的吞吐。jvm调优主要是针对垃圾收集器的收集性能优化，令运行在虚拟机上的应用能够使用更少的内存以及延迟获取更大的吞吐量。
- 延迟：GC低停顿和GC低频率；
- 低内存占用；
- 高吞吐量;
其中，任何一个属性性能的提高，几乎都是以牺牲其他属性性能的损为代价的，不可兼得。具体根据在业务中的重要性确定。
JVM调优量化目标
下面展示了一些JVM调优的量化目标参考实例：
- Heap 内存使用率 <= 70%;
- Old generation内存使用率<= 70%;
- avgpause <= 1秒;
- Full gc 次数0 或 avg pause interval >= 24小时 ;
注意：不同应用的JVM调优量化目标是不一样的。
JVM调优的步骤
一般情况下，JVM调优可通过以下步骤进行：
- 分析GC日志及dump文件，判断是否需要优化，确定瓶颈问题点；
- 确定JVM调优量化目标；
- 确定JVM调优参数（根据历史JVM参数来调整）；
- 依次调优内存、延迟、吞吐量等指标；
- 对比观察调优前后的差异；
- 不断的分析和调整，直到找到合适的JVM参数配置；
- 找到最合适的参数，将这些参数应用到所有服务器，并进行后续跟踪。
以上操作步骤中，某些步骤是需要多次不断迭代完成的。一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。
JVM参数
JVM调优最重要的工具就是JVM参数了。先来了解一下JVM参数相关内容。
-XX 参数被称为不稳定参数，此类参数的设置很容易引起JVM 性能上的差异，使JVM存在极大的不稳定性。如果此类参数设置合理将大大提高JVM的性能及稳定性。
不稳定参数语法规则包含以下内容。
布尔类型参数值：
- -XX:+
- -XX:-
数字类型参数值：
- -XX:
字符串类型参数值：
- -XX:
JVM参数解析及调优
比如以下参数示例：
-Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15上面为Java7及以前版本的示例，在Java8中永久代的参数-XX:PermSize和-XX：MaxPermSize已经失效。这在前面章节中已经讲到。
参数解析：
- -Xmx4g：堆内存最大值为4GB。
- -Xms4g：初始化堆内存大小为4GB。
- -Xmn1200m：设置年轻代大小为1200MB。增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
- -Xss512k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1MB，以前每个线程堆栈大小为256K。应根据应用线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
- -XX:NewRatio=4：设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
- -XX:SurvivorRatio=8：设置年轻代中Eden区与Survivor区的大小比值。设置为8，则两个Survivor区与一个Eden区的比值为2:8，一个Survivor区占整个年轻代的1/10
- -XX:PermSize=100m：初始化永久代大小为100MB。
- -XX:MaxPermSize=256m：设置持久代大小为256MB。
- -XX:MaxTenuringThreshold=15：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
新生代、老生代、永久代的参数，如果不进行指定，虚拟机会自动选择合适的值，同时也会基于系统的开销自动调整。
可调优参数：
-Xms：初始化堆内存大小，默认为物理内存的1/64(小于1GB)。
-Xmx：堆内存最大值。默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。
-Xmn：新生代大小，包括Eden区与2个Survivor区。
-XX:SurvivorRatio=1：Eden区与一个Survivor区比值为1:1。
-XX:MaxDirectMemorySize=1G：直接内存。报java.lang.OutOfMemoryError: Direct buffer memory异常可以上调这个值。
-XX:+DisableExplicitGC：禁止运行期显式地调用System.gc()来触发fulll GC。
注意: Java RMI的定时GC触发机制可通过配置-Dsun.rmi.dgc.server.gcInterval=86400来控制触发的时间。
-XX:CMSInitiatingOccupancyFraction=60：老年代内存回收阈值，默认值为68。
-XX:ConcGCThreads=4：CMS垃圾回收器并行线程线，推荐值为CPU核心数。
-XX:ParallelGCThreads=8：新生代并行收集器的线程数。
-XX:MaxTenuringThreshold=10：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
-XX:CMSFullGCsBeforeCompaction=4：指定进行多少次fullGC之后，进行tenured区 内存空间压缩。
-XX:CMSMaxAbortablePrecleanTime=500：当abortable-preclean预清理阶段执行达到这个时间时就会结束。
在设置的时候，如果关注性能开销的话，应尽量把永久代的初始值与最大值设置为同一值，因为永久代的大小调整需要进行FullGC才能实现。
内存优化示例
当JVM运行稳定之后，触发了FullGC我们一般会拿到如下信息:
以上gc日志中，在发生fullGC之时，整个应用的堆占用以及GC时间。为了更加精确需多次收集，计算平均值。或者是采用耗时最长的一次FullGC来进行估算。上图中，老年代空间占用在93168kb（约93MB），以此定为老年代空间的活跃数据。则其他堆空间的分配，基于以下规则来进行。
- java heap：参数-Xms和-Xmx，建议扩大至3-4倍FullGC后的老年代空间占用。
- 永久代：-XX:PermSize和-XX:MaxPermSize，建议扩大至1.2-1.5倍FullGc后的永久带空间占用。
- 新生代：-Xmn，建议扩大至1-1.5倍FullGC之后的老年代空间占用。
- 老年代：2-3倍FullGC后的老年代空间占用。
基于以上规则，则对参数定义如下：
java -Xms373m -Xmx373m -Xmn140m -XX:PermSize=5m -XX:MaxPermSize=5m延迟优化示例
对延迟性优化，首先需要了解延迟性需求及可调优的指标有哪些。
- 应用程序可接受的平均停滞时间: 此时间与测量的Minor
- GC持续时间进行比较。可接受的Minor GC频率：Minor
- GC的频率与可容忍的值进行比较。
- 可接受的最大停顿时间:最大停顿时间与最差情况下FullGC的持续时间进行比较。
- 可接受的最大停顿发生的频率：基本就是FullGC的频率。
其中，平均停滞时间和最大停顿时间，对用户体验最为重要。对于上面的指标，相关数据采集包括：MinorGC的持续时间、统计MinorGC的次数、FullGC的最差持续时间、最差情况下，FullGC的频率。
如上图，Minor GC的平均持续时间0.069秒，MinorGC的频率为0.389秒一次。
新生代空间越大，Minor GC的GC时间越长，频率越低。如果想减少其持续时长，就需要减少其空间大小。如果想减小其频率，就需要加大其空间大小。
这里以减少了新生代空间10%的大小，来减小延迟时间。在此过程中，应该保持老年代和持代的大小不变化。调优后的参数如下变化:
java -Xms359m -Xmx359m -Xmn126m -XX:PermSize=5m -XX:MaxPermSize=5m吞吐量调优
吞吐量调优主要是基于应用程序的吞吐量要求而来的，应用程序应该有一个综合的吞吐指标，这个指标基于整个应用的需求和测试而衍生出来的。
评估当前吞吐量和目标差距是否巨大，如果在20%左右，可以修改参数，加大内存，再次从头调试，如果巨大就需要从整个应用层面来考虑，设计以及目标是否一致了，重新评估吞吐目标。
对于垃圾收集器来说，提升吞吐量的性能调优的目标就是尽可能避免或者很少发生FullGC或者Stop-The-World压缩式垃圾收集（CMS），因为这两种方式都会造成应用程序吞吐降低。尽量在MinorGC 阶段回收更多的对象，避免对象提升过快到老年代。
调优工具
借助GCViewer日志分析工具，可以非常直观地分析出待调优点。可从以下几方面来分析：
Memory,分析Totalheap、Tenuredheap、Youngheap内存占用率及其他指标，理论上内存占用率越小越好；
Pause，分析Gc pause、Fullgc pause、Total pause三个大项中各指标，理论上GC次数越少越好，GC时长越小越好；
