JVM原理探究及调优方法论

1 此文目的

本文不许备从盘古开天地开始讲述JVM的种种，相关的文章网上太多了，大多也无非转来转去，连图都差很少。笔者只整理个提纲挈领的学习路线指南，并对本身学习过程当中遇到的坑和容易混淆和忽视的地方做个总结。

2 JVM内存模型

2.1 内存模型

内存区域划分有多个维度，相同区域在不一样维度的名称并不同。以下图所示

能够看到，survivor区被划分为了survivor0和survivor1两个区域，可是在讲MinorGC的原理时，咱们又会说survvior to和survivor from两个区域。事实上，survivor0和survivor1是物理维度的划分，而survivor to和survivor from是逻辑维度的划分，在MinorGC的过程当中，survivor0和survivor1交替担当to区和from区。 来仔细解释一下MinorGC的过程： 在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中全部存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到必定值(年龄阈值，能够经过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。通过此次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。无论怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满以后，会将全部对象移动到年老代中。大体以下图所示：

2.2 方法区和永久代

这两个概念，不少时候都被当作是同一个概念。实际上，“方法区”是java虚拟机规范中对存放类信息，字段，方法，常量，静态变量，接口和常量池的内存区域的定义，而“永久代”则是HotSpot VM在1.8版本之前对于方法区的具体实现。因为java虚拟机规范并无对方法区的具体实现做限制，因此HotSpot VM和JRocket VM对于方法区的实现都是不同的，JRocket中就没有永久代的概念。而在1.8及1.8之后的版本中，HotSpot VM用"元空间"--metaspace来代替永久代，实现方法区。 这个变化带来的就是VM参数的变化，全部的PermGen都被替换成了MetaSpace。而且metaSpace再也不使用堆内存，而是使用系统内存。可是该发生的OOM同样会发生。缘由也基本都是加载到内存中的 class 数量太多或者体积太大。

3.GC

3.1 GC算法

GC算法和GC收集器也是两个维度的概念。 GC算法包括清除算法（也叫标记清除算法），复制算法，标记-整理算法。 不一样垃圾收集器针对不一样的内存区域，采用不一样的GC算法。 具体介绍，网上相关资料不少，能够参考这篇文章:blog.csdn.net/xiaoping091…

3.2 垃圾收集器

垃圾收集器经历了从串行收集器到并行收集器，再到并发收集器的进化过程。这三者的区别以下图所示

串行和并行的区别比较容易理解，而CMS垃圾收集器的原理要注意的是，虽然它是并发收集器，但它的GC线程并非完彻底全地与应用的进程并发进行，它只是经过用两次短暂停来代替并行GC的一次长暂停，以期达到减小应用线程暂停的目的，详见 CMS垃圾回收机制

不一样版本默认使用的垃圾收集器以及支持开发者定制的垃圾收集器都是不同的 jdk1.7 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代） jdk1.8 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代） jdk1.9 默认垃圾收集器G1 与此同时，经过设置JVM参数也能够本身选择垃圾收集器。如要开启G1垃圾回收器，能够用-XX:+UseG1GC，支持G1垃圾回收器的JDK最低版本为JDK 7u4。在用户本身选择垃圾收集器的时候，要注意JDK版本的问题。 笔者用表格的形式列出了新生代和老年代的GC收集器的常见搭配方案：

3.3 Full GC触发条件

频繁FullGC致使的stop the world的现象，会大大影响系统的稳定性。尽管一代又一代的垃圾收集器的优化，使得stop the world的时间愈来愈短，可是在大型应用中，仍是避之不及。 出发FullGC的状况有如下几种：

1. System.gc()方法的调用
2. 老年代不足
3. 方法区不足
4. concurrent mode failure concurrent mode failure是在执行CMS GC的过程当中同时有对象要放入老年代，而此时老年代空间不足形成的（有时候“空间 不足”是CMS GC时当前的浮动垃圾过多致使暂时性的空间不足触发Full GC）。
5. promotion failed minor gc时年轻代的存活区空间不足而晋升老年代，老年代又空间不足而触发full gc
6. 统计获得的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间 当准备要触发一次young GC时，若是发现统计数听说以前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（由于HotSpot VM的GC里，除了CMS的concurrent collection以外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，因此不须要事先触发一次单独的young GC）。

3.3.1 OOM的类型

一般状况下，JVM的GC机制能保证应用的正常运行，致使系统频繁FullGC的缘由百分之九十都是内存溢出（OOM）。OOM分为如下几类：

1. Java.lang.OutOfMemeoryError:Java heap space 堆空间的内存溢出，可能的缘由是某个可达性分析认为不能被回收的对象随着时间推移变得愈来愈大，例如某个static类型的map对象，被不停地塞入键值对，也多是大循环或者死循环不断建立对象，而对象分配内存的速度超过了GC清理内存的速度。
2. Java.lang.OutOfMemeoryError:GC overhead limit exceeded 这种OOM异常是Hotspot VM 1.6定义的一个策略，经过统计GC时间来预测是否要OOM了，提早抛出异常，防止OOM发生。Sun 官方对此的定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来作GC而且回收了不到2%的堆内存。用来避免内存太小形成应用不能正常工做。” 那么为何会出现这种GC效率低下的现象呢？一般是由于老年代内存占有过多致使的频繁GC，这种状况下，能够增长-verbose:gc -XX:+PrintGCDetails来分析具体缘由，也能够加-XX:+HeapDumpOnOutOfMemoryError，这样OOM时会自动作Heap Dump，第二种方法适用于全部OOM异常的排查。
3. Java.lang.OutOfMemoryError: PermGen space（JAVA8引入了Metaspace区域）方法区内存溢出，一般是由于加载的类过多，能够先排除程序问题致使的重复类加载，或者加大方法区内存的分配
4. Java.lang.OutOfMemoryError: unable to create new native thread 产生这种异常的缘由是因为系统在不停地建立大量的线程，且不进行释放。

4. JVM调优

4.1 调优参数

正确设置JVM参数，能够尽量多地避免系统资源浪费，尽量详细地掌握系统运行状况，而且对可能出现的问题防患于未然。

Xms：堆初始空间

Xmx：堆最大空间

Xmn：年轻代大小

XX：MaxNewSize 新生代最大空间 建议设置为整个堆的1/3到1/4

XX：NewSize

XX：MaxTenuringThreshold survivor中到老年代中的年龄阈值

Xss：每一个线程的栈大小

java -XX:+PrintCommandLineFlags -version 获得JDK建议的内存分配大小

tomcat设置catalina.sh：

export JAVA_OPTS="-server –Xms1024m -Xmx1024m -XX:+UseParallelOldGC -verbose:gc -Xloggc:../logs/gc.log

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps"

-XX:+PrintCommandLineFlagsjvm参数可查看默认设置收集器类型

-XX:+PrintGCDetails亦可经过打印的GC日志的新生代、老年代名称判断

4.2 JVM监控

• 1.本机环境下，推荐一款idea上的插件VisualVM Launcher，实际就是联动了JDK开发包中自带的jvisualvm.exe监控软件。也能够设置远程监控。具体使用方法，能够参考这篇文章https://blog.csdn.net/wngpenghao/article/details/82884874IDEA Java性能分析插件VisualVM Launcher 配置（JAVA VisualVM 与Jconsole配置相同）

• 2.Linux的相关命令： jstat命令能够对jvm从各维度进行统计，详细使用参考jstat命令查看jvm的GC状况

• 3.VM参数设置时，指定打印出gc日志 -Xloggc:../logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 详细的参数设置以及gc日志该如何阅读，能够参考java之GC日志该怎么看

4.3 JVM异常排查

1. 保存dump 当使用监控软件或者命令查看发现JVM异常时，应第一时间保存下dump现场。 命令是jmap -dump:format=b,file=文件名[pid] pid是服务进程

若是是使用jvisualvm就更方便了，直接点击如图所示的按钮便可：

2. 分析dump eclipse有一款插件叫作Memory Analyzer（MAT），可是目前idea并无这款插件 此外，jhat是sun 1.6及以上版本中自带的一个用于分析JVM 堆DUMP 文件的工具，基于此工具可分析JVM HEAP 中对象的内存占用状况 jhat -J-Xmx1024M [file] 执行后等待console 中输入start HTTP server on port 7000 便可使用浏览器访问 IP：7000 能够特别关心下图标出的这个选项 这对于排查堆内存溢出很是有效

4.4 实战例子

因为实际工做中，能接触到JVM机会的机会并很少，因此笔者整理了一些经典实例

Metaspace溢出排查过程

分享一次 Java 内存泄漏的排查

一次生产的 JVM 优化案例

JVM成长之路,记录一次内存溢出致使频繁FGC的问题排查及解决

很是详细的jvm调优实例，性能瓶颈定位