java-JVM-虚拟机全面解读

1.JVM简介

JVM-JAVA Virtual Machine 就是java虚拟机的意思。

1.1虚拟机是什么？

看看百度百科的解释：

虚拟机（Virtual-Machine）指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机中能够完成的工作在虚拟机中都能够实现。在计算机中创建虚拟机时，需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量。每个虚拟机都有独立的CMOS、硬盘和操作系统，可以像使用实体机一样对虚拟机进行操作。

1.2常用的虚拟机都有哪些呢？

JVM、VMwave、Virtual Box；
而JVM与其他虚拟机之间的区别是什么呢？

• a.VMwave与VirtualBox是通过软件模拟物理CPU的指令集,物理系统中会有很多的寄存器
• b.JVM则是通过软件模拟Java字节码的指令集,JVM中只是主要保留了PC寄存器，其他的寄存器都进行了 裁剪
  简而言之；JVM就是一台被定制的现实中不存在的计算机。

2.JAVA内存区域

2.1运行时的数据区域

JVM会在执行Java程序的过程中把它管理的内存划分为若干个不同的数据区域。这些数据区域各有各的
用处，各有各的创建与销毁时间，有的区域随着JVM进程的启动而存在，有的区域则依赖用户线程的启
动和结束而创建与销毁。一般来说，JVM所管理的内存将会包含以下几个运行时数据区域
线程私有区域:程序计数器、Java虚拟机栈、本地方法栈
线程共享区域: Java堆、方法区、运行时常量池
什么是线程私有？
由于JVM的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现，因此在任何一个确定的时
刻，一个处理器(多核处理器则指的是一个内核)都只会执行一条线程中的指令。因此为了切换线程后能
恢复到正确的执行位置，每条线程都需要独立的程序计数器，各条线程之间计数器互不影响，独立存
储。我们就把类似这类区域称之为"线程私有"的内存。

2.1.1 java堆

新生代：新建的对象由新生代分配内存；
老年代：存放经过多次垃圾回收器回收仍然存活的对象；
永久代：存放静态文件，如java类、方法等，永久代存放在方法区，对垃圾回收没有显著的影响

堆⾥⾯分为两个区域：新⽣代和⽼⽣代，新⽣代放新建的对象，当经过⼀定 GC 次数之后还存活的对象会放⼊⽼⽣代。新⽣代还有 3 个区域：⼀个Endn + 两个 Survivor（S0/S1）。 垃圾回收的时候会将 Endn 中存活的对象放到⼀个未使⽤的 Survivor 中，并把当前的 Endn 和正在使⽤的 Survivor 清除掉。

java堆是java虚拟机关机的内存中最大的一块，且是被所有的线程共享的一块内存区域，
堆在虚拟机启动的时候就创建好了，
堆的作用：存放对象实例，几乎所有的对象实例都存放在堆中；
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。

如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

2.1.2 方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在JDK8以前的HotSpot虚拟机中，方法区也被称为"永久代"(JDK8已经被元空间取代)。
并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

2.1.2.1 运行时常量池–方法区的一部分

运行时常量池是方法区的一部分，存放字面量与符号引用。
字面量 : 字符串(JDK1.7后移动到堆中) 、final常量、基本数据类型的值。
符号引用 : 类和结构的完全限定名、字段的名称和描述符、方法的名称和描述符。

2.1.3 程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果当前线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；
如果正在执行的是一个Native方法，这个计数器值为空。

程序计数器内存区域是唯一一个在JVM规范中没有规定任何OOM情况的区域！

2.1.4 JVM栈–java虚拟机栈

与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，虚拟机栈描述的是Java方法执行的内存模型；它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

• 局部变量表：存放⽅法参数和局部变量。
• 操作栈：每个⽅法会⽣成⼀个先进后出的操作栈。
• 动态链接：指向运⾏时常量池的⽅法引⽤。
• ⽅法返回地址：PC 寄存器的地址。

2.1.4.2 局部变量表

存放了编译器可知的各种基本数据类型(8大基本数据类型–boolean,byte,char,short,int,float,long,double)、对象引用。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在执行期间不会改变局部变量表大小。
long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。
在Java虚拟机规范中，对这个区域规定了两种异常状况：

1. 如果线程请求的栈深度大于虚拟机所允许的深度(-Xss设置栈容量)，将会抛出StackOverFlowError
   异常。
2. 虚拟机在动态扩展时无法申请到足够的内存，会抛出OOM(OutOfMemoryError)异常

2.1.5 本地方法栈

本地方法栈与虚拟机栈的作用完全一样，他俩的区别：
本地方法栈为虚拟机使用的Native方法服务，
虚拟机栈为JVM执行的Java方法服务。
在HotSpot虚拟机中，本地方法栈与虚拟机栈是同一块内存区域。

2.2java的内存溢出问题

2.2.1 java堆溢出

Java堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免来GC
清除这些对象，那么在对象数量达到最大堆容量后就会产生内存溢出异常。

Exception in thread “main”: java.lang.OutOfMemoryError: Java heap space

Java堆内存的OOM异常是实际应用中最常见的内存溢出情况。当出现Java堆内存溢出时，异常堆栈信
息"java.lang.OutOfMemoryError"会进一步提示"Java heap space"。当出现"Java heap space"则很明
确的告知我们，OOM发生在堆上。
此时要对Dump出来的文件进行分析，以MAT为例。分析问题的产生到底是出现了内存泄漏(Memory
Leak)还是内存溢出(Memory Overflow)
**内存泄漏 **: 泄漏对象无法被GC
内存溢出 : 内存对象确实还应该存活。此时要根据JVM堆参数与物理内存相比较检查是否还应该把JVM堆
内存调大；或者检查对象的生命周期是否过长。

2.2.2虚拟栈和本地方法栈溢出

由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于HotSpot来说，虽然-Xoss参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈，
在Java虚拟机规范中描述了两种异常：

• 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
• 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
  出现StackOverflowError异常时有错误堆栈可以阅读，比较好找到问题所在。如果使用虚拟机默认参数，栈深度在多多数情况下达到1000-2000完全没问题，对于正常的方法调用（包括递归），完全够用。
  如果是因为多线程导致的内存溢出问题，在不能减少线程数的情况下，只能减少最大堆和减少栈容量的方式来换取更多线程。

内存布局总结

3.垃圾回收器和内存分配策略

垃圾回收器(Garbage Collection)，简称GC;对于程序计数器、虚拟机栈、本地方法栈这三部分区域而言，其生命周期与相关线程有关，随线程而生，随线程而灭。并且这三个区域的内存分配与回收具有确定性，因为当方法结束或者线程结束时，内存就自然跟着线程回收了。因此，我们的内存垃圾回收主要集中于 java 堆和方法区中，在程序运行期间，这部分内存的分配和使用都是动态的.

3.1 对象存活判断

垃圾回收器在进行回收之前，需要对回收的对象进行存活判断，可使用的算法如下：

3.1.1 引用计数法

每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。虽然简单，但引用计数法无法解决对象的循环引用问题。

3.1.2 可达性分析算法

此从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。不可达对象。GC Roots包括：

• 虚拟机栈中引用的对象。

• 方法区中类静态属性实体引用的对象。

• 方法区中常量引用的对象。

• 本地方法栈中JNI引用的对象。
  如下图所示：
  
  对象Object5-Object7之间虽然彼此还有关联，但是它们到GC Roots是不可达的，因此他们会被判定为可回收对象。

3.2 回收方法区

方法区(永久代)的垃圾回收主要收集两部分内容 : 废弃常量和无用的类。
回收废弃常量和回收Java堆中的对象十分类似。以常量池中字面量(直接量)的回收为例，假如一个字符串"abc"已经进入了常量池中，但是当前系统没有任何一个String对象引用常量池的"abc"常量，也没有在其他地方引用这个字面量，如果此时发生GC并且有必要的话，这个"abc"常量会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
无用类需要经过判定，需要同时满足以下3个条件才会被算为无用类：

1. 该类所有实例都已经被回收(即在Java堆中不存在任何该类的实例)
2. 加载该类的ClassLoader已经被回收
3. 该类对应的Class对象没有在任何其他地方被引用，无法在任何地方通过反射访问该类的方法

JVM可以对同时满足上述3个条件的无用类进行回收，也仅仅是"可以"而不是必然。在大量使用反射、动态代理等场景都需要JVM具备类卸载的功能来防止永久代的溢出

3.3垃圾回收算法

关于新生代-老年代和永久代的了解

GC可分为三种：Minor GC Major GC 和 Full GC

垃圾分代回收策略：

Minor GC ：是清理新生代。触发条件：当Eden区满时，触发Minor GC。

Major GC：是清理老年代。是 Major GC 还是 Full GC，大家应该关注当前的 GC是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。

Full GC ：是清理整个堆空间—包括年轻代和老年代。触发条件：调用System.gc时，系统建议执行FullGC，但是不必然执行;老年代空间不足;方法区空间不足；通过Minor GC后进入老年代的平均大小大于老年代的可用内存；由Eden区、FromSpace区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。

新生代

分为三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。

老年代

老年代的对象比较稳定，所以MajorGC不会频繁执行。在进行MajorGC前一般都先进行了一次MinorGC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次MajorGC进行垃圾回收腾出空间。
当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）异常。

永久代

指内存的永久保存区域，主要存放Class和Meta（元数据）的信息,Class在被加载的时候被放入永久区域. 它和存放实例的区域不同,GC不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的Class的增多而胀满，最终抛出OOM异常。

3.3.1标记-清除算法

"标记-清除"算法是最基础的收集算法。算法分为"标记"和"清除"两个阶段 : 首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象(标记过程见3.1.2章节)。后续的收集算法都是基于这种思路并对其不足加以改进而已。

"标记-清除"算法的不足主要有两个 :

1. 效率问题 : 标记和清除这两个过程的效率都不高
2. 空间问题 : 标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集

3.3.2 复制算法–新生代回收算法

"复制"算法是为了解决"标记-清理"的效率问题。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这块内存需要进行垃圾回收时，会将此区域还存活着的对象复制到另一块上面，然后再把已经使用过的内存区域一次清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配时也就不需要考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配即可。此算法实现简单，运行高效。算法的执行流程如下图 :

这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。

现在的商用虚拟机(包括HotSpot都是采用这种收集算法来回收新生代)；
新生代中98%的对象都是"朝生夕死"的，所以并不需要按照1 : 1的比例来划分内存空间，而是将内存(新生代内存)分为一块较大的Eden(伊甸园)空间和两块较小的Survivor(幸存者)空间，每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区域）。当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。
当Survivor空间不够用时，需要依赖其他内存(老年代)进行分配担保。
HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说Eden:Survivor From : Survivor To = 8:1:1。所以每次新生代可用内存空间为整个新生代容量的90%,而剩下的10%用来存放回收后存活的对象。
HotSpot实现的复制算法流程如下:

1. 当Eden区满的时候,会触发第一次Minor gc,把还活着的对象拷贝到Survivor From区；当 Eden区再次触发Minor gc的时候,会扫描Eden区和From区域,对两个区域进行垃圾回收,经过这次回收后还存活的对象,则直接复制到To区域,并将Eden和From区域清空。
2. 当后续Eden又发生Minor gc的时候,会对Eden和To区域进行垃圾回收,存活的对象复制到 From区域,并将Eden和To区域清空。
3. 部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数 MaxTenuringThreshold决定,这个参数默认15),最终如果还是存活,就存入到老年代
   

3.3.3 标记整理算法–老年代回收算法

针对老年代的特点，提出的一种称之为"标记-整理算法"。标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。

3.4 垃圾回收器

上述垃圾回收算法只是内存回收的方法，垃圾回收器是内存回收的具体实现，以下的垃圾回收器都是基于JDK1.7的G1回收器之后的HotSpot虚拟机，此JVM包含的垃圾回收器如下：

以上7种用于不同分代的回收器，如果两个收集器之间存在连线，说明可以搭配使用，上半部分属于新生代回收器，下半部分属于老年代回收器。首先了解三个概念：

• 并行(Parallel) : 指多条垃圾收集线程并行工作，用户线程仍处于等待状态
• 并发(Concurrent) :指用户线程与垃圾收集线程同时执行(不一定并行，可能会交替执行)，用户程序继续运行，而垃圾收集程序在另外一个CPU上。
• 吞吐量:就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

3.4.1 Serial串行–新生代回收器

Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。
特性：
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束(Stop The World).
应用场景:
Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。
优势:
简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。 实际上到现在为止 : 它依然是虚拟机运行在Client模式下的默认新生代收集器

3.4.2 ParNew–新生代回收器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。
**特性 **:
Serial收集器的多线程版本
应用场景 :
ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器。作为Server的首选收集器之中有一个与性能无关的很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。
在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。
对比分析:
与Serial收集器对比:
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。然而，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。

3.4.3 Parallel Scavenge收集器(新生代收集器,并行)

特性：
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。Parallel Scavenge收集器使用两个参数控制吞吐量：
XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
XX:GCRatio 直接设置吞吐量的大小
直观上，只要最大的垃圾收集停顿时间越小，吞吐量是越高的，但是GC停顿时间的缩短是以牺牲吞吐量和新生代空间作为代价的。比如原来10秒收集一次，每次停顿100毫秒，现在变成5秒收集一次，每次停顿70毫秒。停顿时间下降的同时，吞吐量也下降了。
应用场景：
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
对比分析：
Parallel Scavenge收集器 VS CMS等收集器：
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。
Parallel Scavenge收集器 VS ParNew收集器：Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略
GC自适应的调节策略：
Parallel Scavenge收集器有一个参数- XX:+UseAdaptiveSizePolicy 。当这个参数打开之后，就
不需要手工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚
拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或
者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。

3.4.4 Serial Old收集器(老年代收集器，串行)

特性：
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记－整理算法。
应用场景：
Client模式:Serial Old收集器的主要意义也是在于给Client模式下的虚拟机使用。
Server模式:如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

3.4.5 Parallel Old收集器(老年代收集器，并行)

特性：
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。
应用场景：
在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

3.4.6 CMS收集器（老年代收集器，并发GC)

特性：
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：

初始标记（CMS initial mark）
初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。
并发标记（CMS concurrent mark）
并发标记阶段就是进行GC Roots Tracing的过程。
重新标记（CMS remark）
重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短，仍然需要“Stop The World”。
并发清除（CMS concurrent sweep）
并发清除阶段会清除对象

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
优点：
CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。
缺点：

CMS收集器对CPU资源非常敏感
CMS收集器无法处理浮动垃圾
CMS收集器会产生大量空间碎片

3.3.7 G1收集器(唯一一款全区域的垃圾回收器)

G1（Garbage First）垃圾回收器是用在heap memory很大的情况下，把heap划分为很多很多的region块，然后并行的对其进行垃圾回收。G1垃圾回收器在清除实例所占用的内存空间后，还会做内存压缩。

一个region有可能属于Eden，Survivor或者Tenured内存区域。图中的E表示该region属于Eden内存区域，S表示属于Survivor内存区域，T表示属于Tenured内存区域。图中空白的表示未使用的内存空间。G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。这种内存区域主要用于存储大对象-即大小超过一个region大小的50%的对象。

年轻代垃圾收集

在G1垃圾收集器中，年轻代的垃圾回收过程使用复制算法。把Eden区和Survivor区的对象复制到新的Survivor区域。

老年代垃收集

对于老年代上的垃圾收集，G1垃圾收集器也分为4个阶段，基本跟CMS垃圾收集器一样，但略有不同

初始标记(Initial Mark)阶段 - 同CMS垃圾收集器的Initial
Mark阶段一样，G1也需要暂停应用程序的执行，它会标记从根对象出发，在根对象的第一层孩子节点中标记所有可达的对象。但是G1的垃圾收集器的Initial
Mark阶段是跟minor gc一同发生的。也就是说，在G1中，你不用像在CMS那样，单独暂停应用程序的执行来运行Initial
Mark阶段，而是在G1触发minor gc的时候一并将年老代上的Initial Mark给做了。 并发标记(Concurrent
Mark)阶段 - 在这个阶段G1做的事情跟CMS一样。但G1同时还多做了一件事情，就是如果在Concurrent
Mark阶段中，发现哪些Tenured
region中对象的存活率很小或者基本没有对象存活，那么G1就会在这个阶段将其回收掉，而不用等到后面的clean
up阶段。这也是Garbage First名字的由来。同时,在该阶段，G1会计算每个 region的对象存 活率，方便后面的clean
up阶段使用 。 最终标记(CMS中的Remark阶段) - 在这个阶段G1做的事情跟CMS一样,
但是采用的算法不同，G1采用一种叫做SATB(snapshot-at-the-begining)的算法能够在Remark阶段更快的标记可达对象。
筛选回收(Clean up/Copy)阶段 - 在G1中，没有CMS中对应的Sweep阶段。相反 它有一个Clean
up/Copy阶段，在这个阶段中,G1会挑选出那些对象存活率低的region进行回收，这个阶段也是和minor gc一同发生的,

如下图所示：

3.5内存分布策略

之前有内存的结构，内存的回收，现在我们看看内存是怎样给对象分配的。

3.5.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发生一次Minor GC

3.5.2 大对象直接进入老年代

所谓的大对象是指，需要大量连续空间的Java对象，最典型的大对象就是那种很长的字符串以及数组(上述代码中的byte[] 数组就是典型的大对象)。大对象对虚拟机的内存分配是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发GC以获取足够的连续空间来放置大对象。虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的在于避免Eden区以及两个Survivor区之间发生大量的内存复制(新生代采用复制算法收集内存)

3.5.3 长期存活的对象将进入老年代

既然虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且把对象年龄设为1.对象在Survivor空间中每"熬过"一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。

3.5.4 动态对象年龄判定

为了能更好的适应不同程序的内存状况，JVM并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

3.5.5 空间分配担保

在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，

如果大于，则此次Minor GC是安全的
如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次MinorGC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。

上面提到了Minor GC依然会有风险，是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（最极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。取平均值仍然是一种概率性的事件，如果某次Minor GC后存活对象陡增，远高于平均值的话，必然导致担保失败，如果出现了分配担保失败，就只能在失败后重新发起一次Full GC。虽然存在发生这种情况的概率，但大部分时候都是能够成功分配担保的，这样就避免了过于频繁执行Full GC。

4. 类加载机制

4.1 类加载的定义

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的 Class对象， Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。

4.2 类的生命周期

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

4.2.1 加载

类加载指的是将类的class文件读入内存，并为之创建一个java.lang.Class对象，作为方法区这个类的数据访问的入口。也就是说，当程序中使用任何类时，系统都会为之建立一个java.lang.Class对象。具体包括以下三个部分：
（1）通过类的全名产生对应类的二进制数据流。（根据early load原理，如果没找到对应的类文件，只有在类实际使用时才会抛出错误）
（2）分析并将这些二进制数据流转换为方法区方法区特定的数据结构
（3）创建对应类的java.lang.Class对象，作为方法区的入口（有了对应的Class对象，并不意味着这个类已经完成了加载链接）

4.2.2 链接

链接指的是将Java类的二进制文件合并到jvm的运行状态之中的过程。在链接之前，这个类必须被成功加载。
类的链接包括验证、准备、解析这三步。

4.2.2.1 验证

验证是用来确保Java类的二进制表示在结构上是否完全正确（如文件格式、语法语义等）确保Class文件的字节流中包含的信息符合当前虚拟机的要求。如果验证过程出错的话，会抛出java.lang.VertifyError错误。验证阶段大致会完成4个阶段的检验动作：

• 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以 0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。

• 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。

• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。

• 符号引用验证：确保解析动作能正确执行。

4.2.2.2 准备

为类的 静态变量分配内存，并将其初始化为默认值，同时在方法区中分配内存空间。准备过程并不会执行代码。
注意这里是做默认初始化，不是做显式初始化。例如：

public static int value = 12;

上面的代码中，在准备阶段，会给value的值设置为0（默认初始化）。在后面的初始化阶段才会给value的值设置为12（显式初始化）。

但是有个特殊情况：

public static final int value = 12;

在编译阶段会为value生成ConstantValue属性，在准备阶段虚拟机会根据ConstantValue属性将value赋值为100。

4.2.2.3 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。解析的过程可能会导致其它的Java类被加载。

符号引用就是一组符号来描述目标，可以是任何字面量。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

4.2.3 初始化

初始化阶段是类加载过程的最后一步。到了初始化阶段，才真正执行类中定义的Java程序代码（或者说是字节码）。
初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：

声明类变量是指定初始值
使用静态代码块为类变量指定初始值

JVM初始化步骤

1、假如这个类还没有被加载和连接，则程序先加载并连接该类

2、假如该类的直接父类还没有被初始化，则先初始化其直接父类

3、假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：

创建类的实例，也就是new的方式

访问某个类或接口的静态变量，或者对该静态变量赋值

调用类的静态方法

反射（如 Class.forName(“com.shengsiyuan.Test”)）

初始化某个类的子类，则其父类也会被初始化

Java虚拟机启动时被标明为启动类的类（ JavaTest），直接使用 java.exe命令来运行某个主类

举例：

Student s = new Student();在内存中做了哪些事情?

1. 加载Student.class文件进内存
2. 在栈内存为s开辟空间
3. 在堆内存为学生对象开辟空间
4. 对学生对象的成员变量进行默认初始化
5. 对学生对象的成员变量进行显示初始化
6. 通过构造方法对学生对象的成员变量赋值
7. 学生对象初始化完毕，
8. 把对象地址赋值给s变量