JVM详解

1. JVM内存模型

JDK1.8和JDK1.7相比最大的区别是：元空间区取代了永久代，永久代原本主要存放Class和Meta的信息。而元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制

1.1 程序计数器

程序计数器可以看作当前线程所执行的字节码的行号指示器。如果线程执行的是Java方法那么这个计数器记录的是正在执行的虚拟机字节码指令地址。如果执行的是Native方法，这个计数器为空。（该内存区是唯一没有规定任何OutOfMemoryError情况的区域）

1.2 Java虚拟机栈

Java虚拟机栈跟程序计数器一样是线程私有的，它的生命周期和线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用到执行完成的过程，就对应一个栈帧在虚拟机栈中入栈到出栈的过程。
在虚拟机规范中，这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常，如果虚拟机扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

1.3 本地方法栈

本地方法栈与虚拟机栈作用相似，它们之间的区别是虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为虚拟机使用到的Native方法服务。与虚拟机栈一样本地方法也会抛出StackOverflowError异常和OutOfMemoryError异常。

1.4 Java堆

Java堆通常是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。这块区域唯一的目的就是存放对象实例，几乎所有对象实例都在该区域分配内存。（JIT编译器的发展和逃逸分析技术的成熟，栈上分配和标量替换等技术使其不那么绝对。）
Java堆是垃圾收集器管理的主要区域，从内存回收的角度，Java堆还可以细分为：新生代和老年代。新生代再细分有：Eden空间、From Survivor空间、To Survivor空间。
根据虚拟机规范，Java堆可以处于物理上的不连续内存中，只要逻辑上是连续即可。其大小可以通过-Xmx和-Xms控制。如果在堆中没有内存完成实例分配，并且堆也无法扩展时会抛出OutOfMemoryError异常。
需要注意的是在JDK1.7后，字符串常量池从永久代中剥离出来，存放在堆中。
方法区原本跟堆一样是线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量等数据。（有人称之为“永久代”）但是它有一个问题，它很容易出现内存溢出的问题。（永久代有-XX：MaxPermSize的上限）

1.5 直接内存

直接内存不是虚拟机运行时数据区的一部分也不是Java虚拟机规范中定义的内存区域。在Nio中，它可以使用Native函数直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。（可以提高性能，因为避免了Java堆和Native堆中来回赋值数据。）该区域不受堆大小限制但是会受到本机总内存（RAM或SWAP）大小等限制。如果忽略这点将堆大小设置过大使得各个内存区域大小总和大于物理内存，它会在动态扩展时出现OutOfMemoryError异常。

1.6 元空间

在JDK1.8中元空间区取代了永久代，永久代原本主要存放Class和Meta的信息。而元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。
为什么进行替换大致有以下几点原因：

• 字符串存在永久代中，容易出现性能问题和内存溢出。
• 类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
• 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
  堆大小分配:

java -XX:+PrintFlagsFinal -version
-XX:NewRatio:  设置Yong 和 Old的比例，比默认值为2，则Old Generation是 Yong Generation的2倍，即Yong Generation占据内存的1/3
-XX:NewSize : 设置Yong Generation的初始值大小
-XX:MaxNewSize：设置Yong Generation的最大值大小
-XX:SurviorRatio : 设置Eden和一个Suivior的比例，默认值为8，即Eden是To(S2)的比例是8，（From和To是一样大的），此时Eden占据Yong Generation的8/10
-XX:InitialTenuringThreshol : 设置晋升到老年代的对象年龄的最小值，默认为7
-XX:MaxTenuringThreshold : 设置晋升到老年代的对象年龄的最大值
一般情况下，不允许-XX:NewRatio值小于1，即Old要比Yong大

2. 堆模型

年轻代：存放生命周期短的对象及其体积小的对象
老年代：存放生命周期长的 ，体积大的对象
对于新生代和老年代采用了不同的垃圾回收算法。新生代使用复制算法

默认配置下年轻代又按照8：1 ：1的比例划分为三块，最大的称为Eden（伊甸园）区，较小的两块分别称为To Survivor和From Survivor。
首次GC时，只需要将Eden存活的对象复制到To。然后将Eden区整体回收。再次GC时，将Eden和To存活的复制到From，循环往复这个过程。这样每次新生代中可用的内存就占整个新生代的90%，大大提高了内存利用率。但不能保证每次存活的对象就永远少于新生代整体的10%，此时复制过去是存不下的。因此这里会用到老年代，进行分配担保，存不下的话将对象存储到老年代。若还不够，就会抛出OOM。另外如果一个对象在多次内存回收后，都还存活，也会进入老年代，这个次数通过‐XX:+MaxTenuringThreshold控制，最大值为15.（对象头中的4个bit存放）。

3. 垃圾回收算法

• 标记清除
• 复制
• 标记整理
• 分代收集

3.1 标记清除

“标记-清除”（Mark-Sweep）算法分为“标记”和“清除”两个阶段：

1. 首先标记出所有需要回收的对象
2. 在标记完成后统一回收掉所有被标记的对象

缺点：

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

3.2 复制

“复制”（Copying）算法，将可用内存按容量划分为大小相等的两块，每次用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块，然后再把已使用过的内存空间一次清理掉。
优点：
内存分配时不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
缺点：

1. 空间损失，内存缩小为原来的一半，降低了内存的利用率
2. 长生存期对象复制，则导致效率降低
3. 大对象复制，该算法也存在效率低下的问题。

3.3 标记整理

“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存
优点：

1. 克服了复制算法的低效问题
2. 克服了标记清除算法的内存碎片化的问题

3.4 分代收集

“分代收集”（Generational Collection）算法，根据对象不同的特点，采用不同的算法进行回收，取名为分代收集。如堆内存划分为新生代和老年代
对象进入老年代场景：

• 提升：当对象在多次垃圾回收后，依然存活，也就是多次从from->to 又从to->from 这样多次。jvm认为无需让这样的对象继续这样复制，因此将其晋升到老年代。
• 分配担保：默认的Survivor只占整个年轻代的10%，当从eden区复制到from / to的时候，存不下了，这个时候对象会被移动到老年代。-XX:PretenureSizeThreshold
• 大对象：大对象直接在老年代分配。
• 动态对象年龄判定：当eden区中，某一年龄的对象已经占用整个eden的一半了，那么大于或者等于这一年龄的对象都会进入老年代。

4. 垃圾收集器

收集算法是jvm内存回收过程中具体的、通用的方法，垃圾收集器是jvm内存回收过程中具体的执行者，即各种GC算法的具体实现。

• Serial收集器
• ParNew收集器
• Parallel收集器
• Parallel Old 收集器
• CMS 收集器
• G1 收集器

4.1 Serial收集器

串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。新生代、老年代使用串行回收；垃圾收集的过程中会Stop The World（服务暂停）
新生代：复制
老年代：标记-压缩
JVM参数：

-XX:+UseSerialGC	 # 收集器类型

4.2 ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本。新生代并行，老年代串行；
新生代：复制
老年代：标记-压缩
JVM参数：

-XX:+UseParNewGC     # 收集器类型
-XX:ParallelGCThreads  # 限制线程数量

4.3 Parallel收集器

Parallel Scavenge收集器类似ParNew收集器，Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量；也可以通过参数控制GC的时间不大于多少毫秒或者比例；
新生代：复制
老年代：标记-压缩
JVM参数：

-XX:+UseParallelGC	# 收集器类型+老年代串行

4.4 Parallel Old 收集器

Parallel Old是Parallel收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供
JVM参数：

-XX:+UseParallelOldGC  # 使用Parallel收集器+ 老年代并行

4.5 CMS 收集器

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

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
​ 由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器（新生代使用ParNew）
优点：并发收集、低停顿
缺点：产生大量空间碎片、并发阶段会降低吞吐量
JVM参数：

-XX:+UseConcMarkSweepGC 		# 使用CMS收集器
-XX:+ UseCMSCompactAtFullCollection # Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长
-XX:+CMSFullGCsBeforeCompaction     # 设置进行几次Full GC后，进行一次碎片整理
-XX:ParallelCMSThreads 			 # 设定CMS的线程数量（一般情况约等于可用CPU数量）

4.6 G1 收集器

G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点：

1. 空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
2. 可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。
   上面提到的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region的集合。
   
   G1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。和CMS类似，G1收集器收集老年代对象会有短暂停顿。
   收集步骤：
3. 标记阶段，首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event)，并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark)
4. Root Region Scanning，程序运行过程中会回收survivor区(存活到老年代)，这一过程必须在young GC之前完成。
5. Concurrent Marking，在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收(图中打X)。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。
   
6. Remark, 再标记，会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
7. Copy/Clean up，多线程清除失活对象，会有STW。G1将回收区域的存活对象拷贝到新区域，清除Remember Sets，并发清空回收区域并把它返回到空闲区域链表中。
   
8. 复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。
   

5. 对象存活判断

判断对象是否存活一般有两种方式：

• 引用计数：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。此方法简单，无法解决对象相互循环引用（对象A引用对象B，对象B又引用对象A）的问题。
• 可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，即为不可达对象。

GC root包括栈中引用对象和方法区中引用对象。在Java语言中，GC Roots包括：

• 虚拟机栈中引用的对象
• 方法区中类静态属性实体引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI引用的对象

6. 自动jmap参数验证

6.1 jar包测试

JVM参数:

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/tmp

测试机器：2U2G
测试代码：

package com.yao.deploy;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;
import java.util.*;

@SpringBootApplication
public class TestJar {
/**
 * 演示堆的溢出
 * 测试机器：2U2G
 * VM args: -Xmx768m -Xms768m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
 */
   	public static void main(String[] args){
        List<byte[]>  list = new ArrayList<>();
        int i = 0;
        while(true){
          list.add(String.valueOf(i++).intern());
        }
    }
	*/
	    public static void main(String[] args){
			new Thread(() -> {
				List<byte[]> list=new ArrayList<byte[]>();
				while(true){
				System.out.println(new Date().toString()+Thread.currentThread()+"==");
				byte[] b = new byte[1024*1024*1];
				list.add(b);
				try {
					Thread.sleep(1);
				} 
				catch (Exception e) {
					e.printStackTrace();
				}}}).start();
			
			new Thread(() -> {
				while(true){
					System.out.println(new Date().toString()+Thread.currentThread()+"==");
				try {
				Thread.sleep(1);
				} 
				catch (Exception e) {
					e.printStackTrace();
				}}}).start(); 
		}
}

执行命令：

java -Xmx768m -Xms768m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar deploy-test-jar.jar 

执行结果：

6.2 war包测试

测试机器：2U2G
测试代码：

package com.demo;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.demo.testcase.OOMTest;


@WebServlet("/test")
public class TestServlet extends HttpServlet {
	private static final long serialVersionUID = 1L;
       
    public TestServlet() {
        super();
    }

	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		System.out.println("####"+getClass());
		OOMTest.main(null);
		response.getWriter().append("Served at: ").append(request.getContextPath());
	}

	protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		doGet(request, response);
	}

}

package com.demo.testcase;

import java.util.ArrayList;
import java.util.Date;
import java.util.List;

public class OOMTest {

	public static void main(String[] args) {
		new Thread(() -> {
			List<byte[]> list = new ArrayList<byte[]>();
			while (true) {
				System.out.println(new Date().toString() + Thread.currentThread() + "==");
				byte[] b = new byte[1024 * 1024 * 1];
				list.add(b);
				try {
					Thread.sleep(1);
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		}).start();

		new Thread(() -> {
			while (true) {
				System.out.println(new Date().toString() + Thread.currentThread() + "==");
				try {
					Thread.sleep(1);
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		}).start();
	}

}

tomcat配置：

CATALINA_OPTS="-server -Xms768m -Xmx768m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xmn512m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection $CATALINA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8786 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

执行结果：