大家好，又见面了，我是你们的朋友全栈君。

一、JVM架构图

1. JVM总体概述

JVM总体上是由类装载子系统（ClassLoader）、运行时数据区、执行引擎、内存回收这四个部分组成。其中我们最为关注的运行时数据区，也就是JVM的内存部分则是由方法区（Method Area）、JAVA堆（Heap）、虚拟机栈（Stack）、程序计数器、本地方法栈这几部分组成；除此以外，在概念中还有一个直接内存的概念，事实上这部分内存并不属于虚拟机规范中定义的内存区域，但是因为在JDK1.4+后新加的NIO类，以及JDK1.8+后的Metaspace的关系，所以在讨论JVM时也经常会被放到一起讨论。

2 .JVM内存概述

各内存部分的功能及具体组成部分，总结如下：

二、 详解

1. 栈（线程私有）

也是线程私有的。
每个方法在执行的时候也会创建一个栈帧，存储了局部变量，操作数，动态链接，方法返回地址。
每个方法从调用到执行完毕，对应一个栈帧在虚拟机栈中的入栈和出栈。
通常所说的栈，一般是指在虚拟机栈中的局部变量部分。
局部变量所需内存在编译期间完成分配，
如果线程请求的栈深度大于虚拟机所允许的深度，则StackOverflowError。
如果虚拟机栈可以动态扩展，扩展到无法申请足够的内存，则OutOfMemoryError。

1.1 栈图

1.2 栈中的名词解释：

1.2.1.局部变量表：

存放编译期可知的各种基本数据类型、对象引用类型和returnAddress类型（指向一条字节码指令的地址：函数返回地址）。
long、double占用两个局部变量控件Slot。
局部变量表所需的内存空间在编译期确定，当进入一个方法时，方法在栈帧中所需要分配的局部变量控件是完全确定的，不可动态改变大小。
异常：线程请求的栈帧深度大于虚拟机所允许的深度—StackOverFlowError，如果虚拟机栈可以动态扩展（大部分虚拟机允许动态扩展，也可以设置固定大小的虚拟机栈），但是无法申请到足够的内存—OutOfMemorError。

1.2.2 操作数栈：

后进先出LIFO，最大深度由编译期确定。栈帧刚建立使，操作数栈为空，执行方法操作时，操作数栈用于存放JVM从局部变量表复制的常量或者变量，提供提取，及结果入栈，也用于存放调用方法需要的参数及接受方法返回的结果。
操作数栈可以存放一个jvm中定义的任意数据类型的值。
在任意时刻，操作数栈都一个固定的栈深度，基本类型除了long、double占用两个深度，其它占用一个深度

1.2.3 动态连接：

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接。Class文件的常量池中存在有大量的符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用为参数。这些符号引用，一部分会在类加载阶段或第一次使用的时候转化为直接引用（如final、static域等），称为静态解析，另一部分将在每一次的运行期间转化为直接引用，这部分称为动态连接。

1.2.4 方法返回地址：

当一个方法被执行后，有两种方式退出该方法：执行引擎遇到了任意一个方法返回的字节码指令或遇到了异常，并且该异常没有在方法体内得到处理。无论采用何种退出方式，在方法退出之后，都需要返回到方法被调用的位置，程序才能继续执行。方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。一般来说，方法正常退出时，调用者的PC计数器的值就可以作为返回地址，栈帧中很可能保存了这个计数器值，而方法异常退出时，返回地址是要通过异常处理器来确定的，栈帧中一般不会保存这部分信息。
方法退出的过程实际上等同于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作数栈，如果有返回值，则把它压入调用者栈帧的操作数栈中，调整PC计数器的值以指向方法调用指令后面的一条指令。

2.方法区（元空间）（线程共享）

被所有方法线程共享的一块内存区域。
用于存储已经被虚拟机加载的类信息，常量，静态变量等。
这个区域的内存回收目标主要针对常量池的回收和堆类型的卸载。

2.1元数据区域

元数据区域取代了1.7版本及以前的永久代。元数据和永久代本质上都时方法区的实现。方法区皴法虚拟机加载的类型西，静态变量，常量数据。
参数设置：-XX:MetaspaceSize=18m
-XX:MaxMetaspaceSize=60m

3.本地方法栈（线程私有）

和虚拟机栈类似，主要为虚拟机使用到的Native方法服务。也会抛出StackOverflowError 和OutOfMemoryError。

4.程序计数器(线程私有)

是当前线程锁执行字节码的行号治时期，每条线程都有一个独立的程序计数器，这类内存也称为“线程私有”的内存。正在执行java方法的话，计数器记录的是虚拟机字节码指令的地址(当前指令的地址)。如果是Natice方法，则为空。

5. 堆（线程共享）

被所有线程共享的一块内存区域，在虚拟机启动的时候创建，用于存放对象实例。
对可以按照可扩展来实现（通过-Xmx 和-Xms 来控制）
当队中没有内存可分配给实例，也无法再扩展时，则抛出OutOfMemoryError异常
堆时JVM内存占用最大，管理最复杂的一个区域。唯一的途径就是存放对象实例：所有的对象实例以及数组都在堆上进行分配。jdk1.7以后，字符串常量从永久代中剥离出来，存放在堆中。堆具有进一步的内存划分。按照GC分代手机角度划分。

默认值：
老年代：2/3的堆空间
年轻代：1/3的堆空间
eden区：8/10 的年轻代
survivor0: 1/10 的年轻代
survivor1:1/10的年轻代

正确理解并发问题

在了解了JVM结构，特别是内存结构后，我们再说说并发问题产生的原因。在上面的内容中我们分析了Java堆、Java栈，知道Java堆存储的是对象，而Java栈内存是方法执行时所需要的局部变量，其中就包括堆中对象的引用，如果多个线程同时修改堆中同一引用对象的数据，就可能会产生并发问题，导致多个线程中某些线程得到的数据值与实际值不符，造成脏数据。

那么这种问题为什么会发生呢？

实际上，线程操作堆中共享对象数据时并不是直接操作对象所在的那块内存，这里称之为主内存；而是将对象拷贝到线程私有的工作内存中进行更新，完成后再将最新的数据值同步回主内存，而多个线程在同一时刻将一个对象的值改得七七八八，然后再同时同步给对象所在的内存区域，那么以谁更新的为准就成了问题了。

所以，为了防止这种情况出现，Java提供了同步机制，确保各个线程按照一定的机制同一时刻只能运行一个线程更新主内存的值。

具体逻辑示意图如下：

注意，这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈内存、方法区等并不是同一个层次的内存划分。如果勉强类比，从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中对象实例数据部分，而工作内存则对应于虚拟机栈中使用的部分内存区域；从更低层次类比，主内存就直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（甚至是硬件系统本身的优化措施）可能会让内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

而主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之间的实现细节，Java内存模型中定义了8种操作来完成。

而且还规定在执行上述8种基本操作时必须满足如下规则：

• 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起了回写了但主内存不接受的情况出现。

• 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。

• 不允许一个线程无原因地（没有发生任何assign操作）把数据从线程的工作内存同步回主内存中。

• 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说，就是对一个变量实施use、store操作之前，必须先执行过了assign和load操作。

• 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。

• 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。

• 如果一个变量事先没有被lock操作锁定,那就不允许对它执行unlock操作,也不允许去unlock一个被其他线程锁定住的变量。

• 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

以上8种内存访问操作以及上述规则限定，再加上volatile的一些特殊规定以及final不可变特性，就已经完成确定了JAVA程序中那些内存访问操作在并发下是安全的！

三、 GC

Java堆是GC回收的“重点区域”。堆中基本存放着所有对象实例，gc进行回收前，第一件事就是确认哪些对象存活，哪些死去[即不可能再被引用]

1.堆的回收区域

为了高效的回收，jvm将堆分为三个区域
1.新生代（Young Generation）NewSize和MaxNewSize分别可以控制年轻代的初始大小和最大的大小
2.老年代（Old Generation）
3.永久代（Permanent Generation）【1.8以后采用元空间，就不在堆中了】

判断对象是否存活算法

2.引用计数算法

早期判断对象是否存活大多都是以这种算法，这种算法判断很简单，简单来说就是给对象添加一个引用计数器，每当对象被引用一次就加1，引用失效时就减1。当为0的时候就判断对象不会再被引用。
优点:实现简单效率高，被广泛使用与如python何游戏脚本语言上。
缺点:难以解决循环引用的问题，就是假如两个对象互相引用已经不会再被其它其它引用，导致一直不会为0就无法进行回收。

3.可达性分析算法

目前主流的商用语言[如java、c#]采用的是可达性分析算法判断对象是否存活。这个算法有效解决了循环利用的弊端。
它的基本思路是通过一个称为“GC Roots”的对象为起始点，搜索所经过的路径称为引用链，当一个对象到GC Roots没有任何引用跟它连接则证明对象是不可用的。

1）可作为GC Roots的对象有四种

①虚拟机栈(栈桢中的本地变量表)中的引用的对象，就是平时所指的java对象，存放在堆中。
②方法区中的类静态属性引用的对象，一般指被static修饰引用的对象，加载类的时候就加载到内存中。
③方法区中的常量引用的对象,
④本地方法栈中JNI（native方法)引用的对象

即使可达性算法中不可达的对象，也不是一定要马上被回收，还有可能被抢救一下。网上例子很多，基本上和深入理解JVM一书讲的一样对象的生存还是死亡
要真正宣告对象死亡需经过两个过程。
1.可达性分析后没有发现引用链
2.查看对象是否有finalize方法，如果有重写且在方法内完成自救[比如再建立引用]，还是可以抢救一下，注意这边一个类的finalize只执行一次，这就会出现一样的代码第一次自救成功第二次失败的情况。[如果类重写finalize且还没调用过，会将这个对象放到一个叫做F-Queue的序列里，这边finalize不承诺一定会执行，这么做是因为如果里面死循环的话可能会时F-Queue队列处于等待，严重会导致内存崩溃，这是我们不希望看到的。]

更详细了解 参考：
https://www.jianshu.com/p/76959115d486

四、JVM内存调优

.监控GC的状态
对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调优的方法和步骤。

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

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

4.cms参数优化步流程

下面我再继续介绍下JVM的关键参数配置(仅用于参考)。

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的频率

如何选择应该依赖应用程序对象生命周期的分布情况： 如果应用存在大量的临时对象，应该选择更大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大。但很多应用都没有这样明显的特性。

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

• 本着Full GC尽量少的原则，让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理 。

• 通过观察应用一段时间，看其他在峰值时年老代会占多少内存，在不影响Full GC的前提下，根据实际情况加大年轻代，比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间。

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

-XX:+UseParallelOldGC 。

5）.线程堆栈的设置：

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

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

为了方便大家对于JVM有关参数有一个参照，如下：