JVM常见问题

﹏ヽ暗。殇╰゛Y 2023-02-11 07:24 11阅读 0赞

### 文章目录 ###

*  一. 回顾
 *  二. 常见问题
 *   *  2.1 jvm内存模型以及分区，需要详细到每个分区放什么
     *  2.2 堆里面的分区：Eden，survival(from) to，老年代，各自的特点。
     *   *  2.2.1 Eden区
         *  2.2.2 survival区里面的from区和to区
         *  2.2.3 老年代
     *  2.3 对象的创建，对象的内存布局，对象的访问定位
     *   *  2.3.1 对象的创建
         *   *  2.3.1.1 判断是否已经执行类加载
             *  2.3.1.2 内存分配
             *  2.3.1.3 防止并发：同步锁（CAS）或TLAB
             *  2.3.1.4 初始化对象内存空间
             *  2.3.1.5 对象头的设置
             *  2.3.1.6 执行Java的init方法
         *  2.3.2 对象的内存布局
         *   *  2.3.2.1 对象头（Object Header）
             *   *  2.3.2.1.1 Mark Word
                 *  2.3.2.1.2 Klass Word（指向类的指针）
                 *  2.3.2.1.3 array length（数组长度）
             *  2.3.2.2 实例数据（Instance Data）
             *  2.3.2.3 对齐填充字节（Padding）
         *  2.3.3 对象的访问定位
         *   *  2.3.3.1 使用句柄访问
             *  2.3.3.2 直接指针访问
     *  2.4 GC的两种判定方法
     *   *  2.4.1 引用计数法
         *  2.4.2 可达性算法（引用链法）
         *   *  2.4.2.1 Java中哪些对象可以作为GC Roots
     *  2.5 简述垃圾回收机制
     *  2.6 Java中垃圾收集的算法有哪些
     *   *  2.6.1 标记-清除
         *  2.6.2 复制算法
         *  2.6.3 标记-整理
         *  2.6.4 分代收集
         *   *  2.6.4.1 新生代
             *  2.6.4.2 老年代
     *  2.7 内存分配策略与回收策略
     *  2.8 垃圾收集器
     *   *  2.8.1 Serial收集器
         *  2.8.2 ParNew收集器
         *  2.8.3 Parallel Scavenge收集器（吞吐量优先）
         *  2.8.4 Serial Old收集器
         *  2.8.5 Parallel Old收集器
         *  2.8.6 CMS收集器
         *   *  2.8.6.1 简介
             *  2.8.6.2 收集过程
             *  2.8.6.3 优缺点
         *  2.8.7 G1收集器
         *  2.8.8 垃圾收集器参数总结
     *  2.9 简述Java类加载机制
     *  2.10 Java内存模型（JMM）

# 一. 回顾 #

在[java中级程序员必会的教程，解密JVM【黑马程序员出品】][java_JVM]粗略学习了jvm，现做笔记总结。

**此笔记仅供自己参考，如有错误请指正**

# 二. 常见问题 #

## 2.1 jvm内存模型以及分区，需要详细到每个分区放什么 ##

<table> 
 <thead> 
  <tr> 
   <th>分区</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>程序计数器(PC)</strong></td> 
   <td>存放下一条jvm指令的地址。特点：是 <strong>线程私有</strong> 的； <strong>不会发生OOM</strong> (<code>OutOfMemory</code>，内存溢出)</td> 
  </tr> 
  <tr> 
   <td><strong>本地方法栈(Native Method Stacks)</strong></td> 
   <td>主要为native方法服务</td> 
  </tr> 
  <tr> 
   <td><strong>虚拟机栈(JVM Stacks)</strong></td> 
   <td><strong>虚拟机栈：</strong> 线程运行所需要的内存空间，所以每个虚拟机栈是线程私有的。<br> <strong>栈帧：</strong> 虚拟机栈由栈帧组成，每调用一个方法都会压入一个栈帧，栈帧存放局部变量表，操作数栈，方法出口等信息。<br> <strong>局部变量表：</strong> 存放8大基础数据类型加上一个引用类型(reference，一个指向地址的指针)，还有一个returneAddress(方法返回的地址)</td> 
  </tr> 
  <tr> 
   <td><strong>堆(Heap)</strong></td> 
   <td>new出来的对象，初始化的对象，成员变量(非static)，所有实例化对象和数组都分配在堆区。</td> 
  </tr> 
  <tr> 
   <td><strong>方法区(Method Area)</strong></td> 
   <td>它是堆中的一个逻辑概念。以前采用永久代实现(方法区是接口，永久代是具体实现)，java8之后采用Metaspace替代(方法区是接口，Metaspace是具体实现)。方法区存储类信息(比如特殊的方法：构造器)，常量，静态变量，编译后的代码(字节码)等数据。</td> 
  </tr> 
 </tbody> 
</table>

*注：常量池在方法区中，实际上分为两种形态：静态常量池；运行时常量池。所谓静态常量池，即`*.class`文件中的常量池，class文件中的常量池不仅仅包含字符串(数字)字面量，还包含类、方法的信息，占用class文件绝大部分空间。这种常量池主要用于存放两大类常量：字面量(Literal)和符号引用量(Symbolic References)，字面量相当于Java语言层面常量的概念，如文本字符串，声明为final的常量值等，符号引用则属于编译原理方面的概念，包括了如下三种类型的常量：类和接口的全限定名；字段名称和描述符；方法名称和描述符。运行时常量池，则是jvm虚拟机在完成类装载操作后，将class文件中的常量池载入到内存中，并保存在方法区中，我们常说的常量池，就是指方法区中的运行时常量池。参考自[深入浅出java常量池][java]。*

**总结：**

1.  **程序计数器存下一条jvm指令的地址**
2.  **本地方法栈为本地方法服务**
3.  **虚拟机栈存栈帧，栈帧存局部变量表、操作数栈、方法出口等信息。局部变量表存放8大基础类型和1个reference引用类型(指向地址的指针)，和方法返回地址(returnAddress)**
4.  **堆区存储所有的实例对象和数组**
5.  **方法区存类信息、常量池、编译后的字节码等数据**

## 2.2 堆里面的分区：Eden，survival(from) to，老年代，各自的特点。 ##

jvm的堆区分为`年轻代`和`老年代`。年轻代包含`Eden区`、`survival区(幸存区)`。survival区分为`from区`和`to区`。Eden区：from区：to区默认是8：1：1 。如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70]

### 2.2.1 Eden区 ###

*  Eden区位于堆的年轻代，是新对象分配内存的地方。由于堆是所有线程共享的，所以在堆上分配内存需要加锁。
 *  而jdk为提升效率，提供了逃逸分析技术以及TLAB。逃逸分析技术以及TLAB详情见：[对象分配流程\_以及\_栈分配与TLAB的区别][TLAB]
 *  经过逃逸分析，如果一个对象的作用域没有离开当前方法或者当前线程，那么证明该对象不会被其他线程引用到。随后jvm会将移除该对象的锁（即锁消除`EliminateLocks`）；然后将该对象分解成标量（即标量替换`Scalar Replacement`，Java基本数据类型和引用类型为标量）；最后给标量分配内存时会在栈上面分配（即栈分配）。对象随栈帧出栈而销毁，无需GC参与进来，从而减轻GC压力==。
 *  jvm会为每个新建的线程在堆上分配一个该线程独自占有的空间，这个空间就是TLAB（Thread Local Allocation Buffer）。
 *  如果一个对象逃离当前方法或者当前线程，jvm对该对象分配内存时会在TLAB上分配。因为TLAB对线程是私有的，所以在TLAB上面分配内存时不需要加锁。
 *  TLAB的大小是确定不变的（缺省情况下仅占Eden区的1%），在TLAB上分配内存给对象时，需要判断TLAB的剩余空间是否足够存储该对象，因此开发人员在TLAB里面设计了一个最大浪费空间的字段。
 *  当剩余空间 < 最大浪费空间，当前线程会重新申请一个TLAB，若当前对象所需的内存还是比新申请的TLAB大，则将Eden区上的内存（即TLAB外的Eden区内存）分配给该对象。
 *  TLAB的出现虽然提高了分配内存的效率，但是由于TLAB的剩余空间是分散的，随着时间推移Eden区出现很多内存碎片，这样GC就要参与进来。
 *  Eden区满了后，将会进行Minor GC（也叫Young GC）

### 2.2.2 survival区里面的from区和to区 ###

*  sruvival区和Eden区一同位于堆的年轻代，survival区包含from区和to区。from区和to区是相对的，经过一次Minor GC后，两者将会互换（即from区的指针改为指向原来的to区，to区的指针改为指向原来的from）。
 *  进行Minor GC时，jvm会将Eden区以及from区仍然存活的对象复制到to区；to区里面足够老（存活次数超过设定的阈值）的对象仍然存活则将其复制到老年代；复制完后，清除无用的对象回收内存。

### 2.2.3 老年代 ###

老年代里面存放的都是存活时间较久、占用内存较大的对象。因此老年代使用标记整理算法。当老年代容量满了的时候，会触发一次Major GC（Full GC），回收老年代以及年轻代不再被使用的对象资源。

## 2.3 对象的创建，对象的内存布局，对象的访问定位 ##

### 2.3.1 对象的创建 ###

#### 2.3.1.1 判断是否已经执行类加载 ####

当jvm遇到一条new指令时，首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析、初始化过。如果没有，那必须执行相应类的加载过程。

#### 2.3.1.2 内存分配 ####

当类加载完成后，会为新对象在堆中分配一个大小确定的内存，具体的分配规则有2中：

<table> 
 <thead> 
  <tr> 
   <th>分配规则</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><a href="https://blog.csdn.net/qq_40634846/article/details/106300702" rel="nofollow">指针碰撞</a></td> 
   <td>假设堆的内存是绝对规整的，已被分配的内存放在一边，未被分配的则在另一边。有一个指针指向分界点，分配内存就是指针向未被分配的那一边移动与新对象大小相等的距离</td> 
  </tr> 
  <tr> 
   <td><a href="https://blog.csdn.net/qq_40634846/article/details/106311900" rel="nofollow">空闲链表</a></td> 
   <td>堆的内存是不规整的，jvm用一个空闲链表维护未被分配的内存。在分配内存时，jvm从空闲链表上划分一块足够大的内存给新对象，然后更新空闲链表。</td> 
  </tr> 
 </tbody> 
</table>

**Java堆中内存是否规整是根据jvm采用的垃圾回收器是否带有压缩整理功能决定的。** Serial（串行垃圾回收器，针对年轻代）、ParNew（高吞吐量垃圾回收器，针对年轻代）带有压缩整理功能，所以它们采用指针碰撞分配内存。CMS（ConcurrentMark-Sweep Controller，并行标记垃圾回收器，高吞吐量高响应）采用空闲链表分配内存。

#### 2.3.1.3 防止并发：同步锁（CAS）或TLAB ####

因为堆是线程共享的，在堆上分配内存则存在并发问题，因此要防止并发，有2种方式：

1.  堆分配内存空间的动作进行同步处理（即给对象加锁，加锁大大降低了效率）。实际上jvm采用CAS（Compare and Set）配上失败重试的方式保证更新操作的原子性。
2.  把分配内存的动作放在[TLAB][TLAB 1]中进行，分配内存时在线程的TLAB中进行，当TLAB的剩余空间容纳不下新对象时会重新申请一个TLAB，若还是容纳不了则要采用同步锁定。

#### 2.3.1.4 初始化对象内存空间 ####

内存分配完成后，jvm将分配到的内存空间都初始化为0值（不包括对象头）。

#### 2.3.1.5 对象头的设置 ####

将对象的类信息，哈希码，对象的GC分代年龄设置到对象头中。

#### 2.3.1.6 执行Java的init方法 ####

设置完对象头后，从jvm的角度来看已经是创建完一个对象。但是从Java程序角度来看则并非如此。此时需要执行类的init()方法，调用构造方法等过程，这样一个真正可用的对象才算创建完成。

### 2.3.2 对象的内存布局 ###

创建完对象后，对象对分配给自己的内存是如何分配的呢？详情见[Java的对象组成简介][Java]。

**对象在堆中的布局分为3个部分：对象头（Object Header）；实例数据（Instance Data）；对齐填充字节（Padding）。**

#### 2.3.2.1 对象头（Object Header） ####

**对象头又包含3个部分：Mark Word；Klass Word（指向类的指针）；array length（数组长度）。**

##### 2.3.2.1.1 Mark Word #####

如果jvm是32bit/64bit，那么Mark Word是32bit/64bit。

Mark Word存储对象自身运行时的数据，比如锁标志位；是否偏向锁；GC分代年龄；对象的hashCode；获得该对象的锁的线程ID；偏向时间戳等等。详情见[Java的对象组成简介][Java]。

*注：对象头有关锁标志位的信息涉及到并发编程原理，目前暂未详细了解，日后再作深入学习。*

##### 2.3.2.1.2 Klass Word（指向类的指针） #####

如果jvm是32bit/64bit，那么Klass Word是32bit/64bit。

Java的对象存储在堆中，而其类信息存储在方法区中，因此这里记录当前对象的类信息所在的地址。

##### 2.3.2.1.3 array length（数组长度） #####

如果jvm是32bit/64bit，那么array length是32bit/64bit。

如果当前对象不是数组则没有此数组长度

#### 2.3.2.2 实例数据（Instance Data） ####

存储当前对象在Java代码中的属性（包括父类的属性以及自己的属性）与值

#### 2.3.2.3 对齐填充字节（Padding） ####

jvm要求Java对象占用内存的大小是8bit的倍数，因此某些时候需要将其补齐至8bit的倍数

### 2.3.3 对象的访问定位 ###

Java程序需要通过栈帧上的reference引用来操作堆上的实例对象。reference是一个指向堆中对象的引用。不同的虚拟机有不同的对象访问方式，主流有2种：使用句柄；直接指针。**HotSpot使用的是直接指针访问方式。**

#### 2.3.3.1 使用句柄访问 ####

如果通过使用句柄方式访问，那么堆中将划分一块区域作为句柄池，栈帧中的reference引用则存储句柄地址，而句柄中包含对象实例数据与对象类型数据各自的地址，如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 1]

#### 2.3.3.2 直接指针访问 ####

reference引用存储对象实例数据的地址，对象实例数据中包含对象类型数据的地址，如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 2]  
**HotSpot使用的是直接指针访问方式。**

## 2.4 GC的两种判定方法 ##

### 2.4.1 引用计数法 ###

所谓引用计数法就是给每个对象设置一个引用计数器。每当有一个地方法引用这个对象时，就将这个对象的引用计数器加1，当引用失效时，这个对象的引用计数减1。当一个对象的引用计数器为0时，说明此对象没有被引用，也就是“死对象”，将会被垃圾回收。

**缺点：** 无法解决循环引用的问题。如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 3]

### 2.4.2 可达性算法（引用链法） ###

**从一个被称为GC Roots的对象开始向下搜索，一个对象到GC Roots没有任何引用链相连，则说明此对象不可用，可以被垃圾回收。**

*  即使对象在可达性分析中被判为不可达，但并非是真正死了，此时对象进入“缓刑阶段”。要真正死亡需要经过2次标记过程。
 *  如果对象经过可达性分析后没有与GC Roots有任何引用链，那么它将被第一次标记 并 进行一次筛选
 *  筛选的条件是：是否有必要执行对象的finalize()方法
 *  如果对象没有覆盖finalize()方法 或 finalize()方法已经被虚拟机调用过了，虚拟机将这2种情况视为 没有必要
 *  如果有必要执行finalize()方法，那么此对象被放入名为F-Queue队列中。并稍后由虚拟机自行创建的、低优先级的FinalizeHandler线程执行finalize()方法。所谓的执行，是指虚拟机会触发这个方法，但不承诺会等待它运行结束。因为如果对象在finalize()方法中执行缓慢，或者进入死循环，那么F-Queue队列中的其他对象则会永久等待下去，甚至导致内存回收系统崩溃。
 *  finalize()是对象逃脱死亡的最后一次机会。稍后GC将对F-Queue中的对象进行第二次小规模的标记。如果对象要拯救自己——只需将自己重新与引用链上的任何一个对象建立关联即可。比如把自己（关键字this）赋值给类变量或者对象的成员变量。那么在第二次标记时，它将被移除出“即将回收”的集合。如果此对象还没有逃脱，那基本上是没机会了。

**总结：finalize并不是一定要执行，它只能执行1次或者0次。如果对象能在finalize()中建立对象关联，则当前对象可以复活1次。** 详情见[Java对象什么时候死亡\_以及\_finalize()方法的执行过程][Java_finalize]

#### 2.4.2.1 Java中哪些对象可以作为GC Roots ####

*  **虚拟机栈中引用的对象**
 *  **方法区类属性引用的对象**
 *  **方法区常量池引用的对象**
 *  **本地方法栈JNI引用的对象**

## 2.5 简述垃圾回收机制 ##

java程序中，程序员是不需要显式地释放内存的，而是由jvm虚拟机自由执行的。在jvm中，有一个垃圾回收线程，优先级非常低，在正常情况下是不会执行的。只有当虚拟机空闲或当前堆内存不足时，才会触发执行，扫描那些没有被任何引用的对象，并将它们添加到要回收的集合中，进行回收。

## 2.6 Java中垃圾收集的算法有哪些 ##

垃圾收集算法有4种：标记-清除；复制算法；标记-整理；分代收集。

### 2.6.1 标记-清除 ###

标记-清除算法分为2个阶段：标记；清除。该算法首先从根集合（GC Roots集合，涉及可达性算法）开始扫描，对存活的对象进行标记（即引用链上的对象），标记完成后，再重新扫描整个空间未被标记的对象并回收内存。

**总结：从根集合开始扫描，标记存活的对象，扫描完整个根集合后，第二次扫描整个空间，回收没被标记的对象的内存。**

过程如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 4]  
从上图可以看出该算法有2个不足之处：效率问题；空间问题

**效率问题：** 标记和清除2个过程效率都不高

**空间问题：** 标记清除算法仅对不存活对象进行处理，不会移动对象，因此标记清除之后会产生大量不连续的内存碎片。空间碎片太多可能会导致以后分配大对象时，无法找到足够的连续内存给它。因而不得不提前触发一次垃圾回收。

### 2.6.2 复制算法 ###

复制算法将可用内存按容量划分为大小相等的两块。每次只使用其中的一块，当一块的内存用完了，就将还存活的对象复制到另一块中，然后把已使用过的内存空间一次清理掉。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 5]  
**适用场景：** 从上图看到，此复制算法适用于对象存活率低的场景，比如年轻代，这样使得每次都是对整个半区会回收内存，只需复制少量存活的对象。内存分配时也不用考虑内存碎片。

事实：商用虚拟机都采用复制算法回收年轻代的内存。因为研究发现，年轻代的每次垃圾回收后基本上只有 **10%左右的对象存活**，所以需要复制的对象很少，效率自然很高。jvm中堆区的年轻代分为Eden区、from区以及to区。每次使用Eden区和from区。***垃圾回收时，将Eden区和from区存活的对象复制到to区，然后一次清理掉Eden区和from区，最后原本的from区变成空了，因此变成to区；原本的to区变成from区。HotSpot虚拟机默认的Eden区：from区：to区是8：1：1，即年轻代中有90%（80%+10%)可用内存。***

### 2.6.3 标记-整理 ###

标记-整理与标记清除有点类似，但是后续的步骤不是清除不可用的对象，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。

**适用场景：** 适用于存活率较高的场景（即老年代）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 6]

### 2.6.4 分代收集 ###

首先了解堆中的内存分区。如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 7]  
**分代收集算法基于一个事实：不同对象的生命周期是不同的，而不同生命周期的对象存放在堆中不同的区域。因此对堆中不同的区域采用不同的策略进行回收可以提高jvm的执行效率。**

当代商用虚拟机都是使用分代收集算法：**新生代存活率较低，就采用复制算法；老年代存活率较高，没有额外的空间进行分配担保，采用标记整理 或 标记清除算法。**

#### 2.6.4.1 新生代 ####

一般地，新生成的对象都会放在新生代（更准确地说，一般放在新生代的Eden区，大对象且存活率高可能放在老年代）。垃圾回收时，先将Eden区存活的对象复制到from区，然后清空Eden区。当from区也满时，将Eden区与from区存活的对象复制到to区，然后清空Eden区与from区。from区和to区交换角色（即原来的from区变成to区，原来的to区变成from区）。当to区不足以存放Eden区和from区的对象时，就将存活对象放到老年代。老年代满了，触发一次Full GC（也叫Major GC。新生代、老年代都进行回收）。

#### 2.6.4.2 老年代 ####

新生代中经历了N次垃圾回收后仍存活的对象会被放到老年代中。 新生代：老年代的内存大概是1：2。老年代存放的是存活时间较长的对象。老年代满时会触发Major GC（即Full GC）。

## 2.7 内存分配策略与回收策略 ##

Java体系的自动内存管理归结为2个方面：分配内存；回收内存。一般地，新生成的对象主要被分配到新生代的Eden区上，如果符合栈分配（基于逃逸分析技术） 或 TLAB分配（防止并发申请同一内存区域） ，则优先实行栈分配 或 TLAB分配。总之，内存分配的细节取决于 虚拟机使用了哪一种垃圾收集器集合 以及 虚拟机参数（与内存相关）。

1.  **对象优先在Eden区分配，当Eden区没有足够空间分配内存时，触发一次Minor GC** 。商业虚拟机采用复制算法。堆分为新生代和老年代。新生代包含Eden区、survival区。survival区包含from区、to区。Eden区满了，存活的对象被复制到from区，然后清理Eden区。from区也满时，Eden区与from区存活的对象被复制to区，然后清理Eden区与from区，然后from区与to区角色交换（原本的from区变成to区，原本的to区变成from区）。to区不足以容纳对象时，将存活的对象复制到老年代。
2.  **大对象直接进入老年代。** 大对象指需要大量连续空间的Java对象，典型的有很长的字符串以及数组。
3.  **长期存活的对象将直接进入老年代。** 当对象在新生代经历了一定次数（一般是15）的Minor GC，会被晋升到老年代。
4.  **动态对象年龄判定**。 为了更好地适应不同应用程序的内存状况，虚拟机并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代。如果Survival区中 所有相同年龄（比如12岁）的对象大小总和 > Survival区空间的一半，年龄 >= 该年龄（12岁）的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。
5.  **空间分配担保**。发生Minor GC时，虚拟机会检测 上一次进入老年代的对象的平均大小 是否 > 老年代的剩余空间大小。如果大于则改为直接进行一次Full GC；如果是小于，则检查HandlePromotionFailure设置是否允许担保失败，如果允许，则只会进行Minor GC。如果不允许则改为进行一次Full GC。当大量对象在Minor GC后存活，survivor区无法容量这些存活对象，此时就需要老年代进行空间担保。让survivor无法容纳的对象直接进入老年代。老年代进行这样的担保，前提是得有足够的空间容纳这些存活的对象。但是在实际完成内存回收之前是无法确定到底有多少对象会存活下来，因此只好取之前每一次回收晋升到老年代的对象容量的平均值大小作为经验值，与老年代的剩余空间比较。决定是否进行Full GC让老年代腾出更多的空间。如果某一次Minor GC后存活对象激增，远高于平均值，依然会担保失败（HandlePromotionFailure），那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子比较大，但大部分情况下还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁。

## 2.8 垃圾收集器 ##

### 2.8.1 Serial收集器 ###

在此之前首先了解一下一些知识点：[GC中的STW\_以及\_OopMap\_以及\_safePoint安全点\_以及safeRegion][GC_STW_OopMap_safePoint_safeRegion]

**这是一个单线程的新生代收集器。其单线程不仅仅是指它只会使用一个CPU或一条收集线程去完成垃圾收集工作，还指它在进行垃圾收集时，必须暂停其他所有工作线程（即Stop The World）。Stop The World是由虚拟机自动发起和自动完成的。** 如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 8]

### 2.8.2 ParNew收集器 ###

**ParNew其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾回收之外，其余行为都和Serial收集器一样。它是许多运行在server模式下的虚拟机中首选的新生代收集器。它默认开启的线程数与cpu的数量相同，可以使用`-XX:ParllelGCThreads`参数限制垃圾收集的线程数。** 如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 9]

### 2.8.3 Parallel Scavenge收集器（吞吐量优先） ###

**Parallel Scavenge是一个新生代收集器。它是并行的多线程收集器，采用复制算法。** 看上去和ParNew一样，两者有什么区别？

**Parallel Scavenge的特点是达到一个可控制的吞吐量（吞吐量优先，即用户工作线程运行得越久越多，吞吐量就越高）。CMS垃圾收集器则是尽可能缩短垃圾收集时用户工作线程的停顿时间。**

**吞吐量：** 是指运行用户代码的时间/CPU消耗总时间，即 `运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)`。比如虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那么吞吐量就是`(100-1)/100=99%`。

**高吞吐量和高响应的区别：**

*  高吞吐量是以最高效率利用CPU完成程序的运算，适合在后台运算而不需要太多的交互。一般是Parallel Scavenge；
 *  高响应是用户工作线程停顿时间越短越适合需要与用户交互的程序，良好的响应速度能提升用户的体验。一般是CMS垃圾收集器

**虚拟机参数：**

*  `-XX:MaxGCPauseMillis`：最大垃圾收集停顿时间。一般是一个大于0的毫秒数。垃圾收集器尽量保证垃圾收集花费的时间不超过设定值。GC停顿时间缩短是牺牲吞吐量和新生代空间换取的。要想缩短停顿时间，那么就要 **使堆空间减小** ，但是堆空间小了则代表进行垃圾收集更频繁了，从而吞吐量也下降了。 比如系统把新生代调小，收集300M新生代比500M快，但是新生代调小导致发生垃圾收集更频繁了（即虽然每次垃圾回收时间都很短，但是发生垃圾回收的次数更多了）。
 *  `-XX:GCTimeRatio`：垃圾收集时间的占比。也就是垃圾收集的时间占了总时间的多少。其计算公式是`1/(1+ratio)`，比如ratio默认设置是99，则`1/(1+99)=0.01`，那么假如虚拟机总共运行100分钟，则其垃圾收集时间尽量不能超过1分钟，否则需要调大堆空间。此虚拟机参数与`-XX:MaxGCPauseMillis`是矛盾，因为`-XX:MaxGCPauseMillis`追求的是尽可能缩短停顿时间（即缩短垃圾收集时间），则需要将堆调小；而`-XX:GCTimeRatio`追求的是缩小垃圾时间占比，即垃圾收集的时间尽可能小，则需要将堆调大。一个是将堆调大，一个是将堆调小，所以它们是矛盾的。
 *  `-XX:UseAdaptiveSizePolicy`：设置此参数，虚拟机会动态调整新生代大小（-Xmn），Eden区与survivor区的比例（-XX:SurvivorRatio），晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数以提供最适合的停顿时间或最大的吞吐量。这种调节方式称为GC自适应调节策略（GC Ergonomics）。**自适应调节策略也是Parallel Scavenge与ParNew的一个重要区别。**

### 2.8.4 Serial Old收集器 ###

**这是Serial的老年代版本。它同样是一个单线程收集器。使用标记-整理算法**。如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 10]

### 2.8.5 Parallel Old收集器 ###

**这是Parallel的老年代版本。使用多线程和标记-整理算法。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 11]

### 2.8.6 CMS收集器 ###

#### 2.8.6.1 简介 ####

CMS，Concurrent Mark Sweep，该收集器是一种以获取最短回收停顿时间为目标的收集器（即重视响应速度）。

#### 2.8.6.2 收集过程 ####

从名字上可看出该收集器基于标记-清除算法。它的运作过程分为4个步骤：

1.  初始标记（CMS initial mark）
2.  并发标记（CMS concurrent mark）
3.  重新标记（CMS remark）
4.  并发清除（CMS concurrent sweep）

**解析：** **初始标记和重新标记仍需要stop the world。初始标记仅仅是标记一下GC Roots能直接关联到的对象（速度很快） 。并发标记就是进行GC Root Tracing的过程，而重新标记是为了修正并发标记期间，因用户程序继续运作而导致标记变动的那一部分对象的标记记录（该阶段的停顿时间比初始标记稍长，但远比并发标记的时间短）。**

如下图:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 12]

#### 2.8.6.3 优缺点 ####

**CMS的优点：并发收集、低停顿。**  
**但是它有3个显著的缺点：**

1.  **CMS收集器对CPU资源非常敏感**。面向并发设计的程序都对CPU资源非常敏感。虽然不会导致线程停顿，但是因为占用了部分CPU资源导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是`(CPU数量+3)/4`，当CPU数量在4个以上时，并发垃圾回收时线程最多占用不超过25%的CPU资源。但是当不足4个时（比如2个），如果CPU负载本来就比较大的时候，还需要分出一部分资源来执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，这也很让人受不了。为了解决此情况，虚拟机提供了一种“增量式并发收集器”（i-CMS）的CMS收集器变种，其思想是单CPU采用抢占式来模拟多任务机制的思想。即在并发标记和并发清理的时候让GC线程和用户线程交替运行，**尽量减少GC线程独占CPU资源的时间** ，虽然这样整个垃圾回收的时间变长，但是对用户程序的影响会少一些。
2.  **CMS收集器无法处理浮动垃圾**。在并发收集的过程中，用户线程继续运行从而导致新的垃圾不断产生，这一部分垃圾出现在标记过程之后，因此CMS无法在本次垃圾收集清理掉它们，只能留到下一次GC再将其清理掉。这一部分垃圾被称为 “浮动垃圾”。也是由于并发收集时，其他用户线程还能继续运行，因此需要预留一部分的空间给用户线程使用，因此CMS收集器不能像其他垃圾收集器等到老年代几乎全满了才进行垃圾回收。默认设置下，CMS收集器在老年代使用了68%的空间后就会被激活。如果应用程序中老年代增长不是太快，可以适当调高`-XX:CMSInitiatingOccupancyFraction`的值来提高触发百分比，以便降低垃圾回收的次数来获取更好的性能。CMS运行期间如果预留的内存无法满足程序的需要，就会出现一次“**Concurrent Mode Failure”失败**，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，但是这样停顿时间就很长。因此如果`-XX:CMSInitiatingOccupancyFraction`调得太高（即预留的内存很小），那么会导致大量的“Concurrent Mode Failure”失败，性能反而降低。
3.  **CMS收集器垃圾收集结束后会产生大量的碎片空间**。 CMS采用标记-清除算法，所以会有大量的空间碎片。在分配大对象时，即使老年代有足够大的内存空间，但是无法找到一块连续的内存空间分配给它，不得不提前触发一次Full GC。为了解决此问题，CMS收集器提供了一个参数`-XX:UseCMSCompactAtFullCollection`开关参数，用于享受完Full GC后额外免费附送一个碎片整理过程。内存整理的过程是无法并发的，因此虽然没有碎片了，但停顿的时间会变长。另外还有一个参数`-XX:CMSFullGCsBeforeCompaction`，此参数用于设置多少次不压缩的Full GC后，跟着来一次压缩。

### 2.8.7 G1收集器 ###

**G1收集器，Garbage First，它与CMS收集器相比有2个显著的改进：**

1.  基于标记-整理算法实现垃圾收集，所以不会有空间碎片；
2.  它可以非常精确控制停顿，即能让使用者明确指定一个长度为M毫秒的时间片段内，消耗垃圾回收的时间不得超过N毫秒，这几乎是实时Java（RTSJ）的垃圾收集器的特征了。

**G1收集器可以实现基本不牺牲吞吐量的情况下完成低停顿的内存回收，这是因为它极力避免全区域的垃圾回收（之前的垃圾收集器的收集范围是整个新生代或者老年代）。G1将堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域的垃圾堆积度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾堆积最多的区域（这就是Garbage First名称的由来）。**

**区域划分以及有优先级的垃圾回收，保证了垃圾收集器在有限的时间内获得最高的收集效率。**

### 2.8.8 垃圾收集器参数总结 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 13]  
![在这里插入图片描述][20200531214659377.png]

## 2.9 简述Java类加载机制 ##

详情参考1. [jvm类加载][jvm]；2. [jvm类加载器][jvm 1]

## 2.10 Java内存模型（JMM） ##

详情见笔者的博文：[Java内存模型Java Memory Model（JMM）][Java_Java Memory Model_JMM]

[java_JVM]: https://www.bilibili.com/video/BV1yE411Z7AP?p=1
[java]: https://www.cnblogs.com/syp172654682/p/8082625.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200523211635471.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[TLAB]: https://blog.csdn.net/qq_40634846/article/details/106304096
[TLAB 1]: https://blog.csdn.net/qq_40634846/article/details/106300160
[Java]: https://blog.csdn.net/qq_40634846/article/details/106314921
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2020052416391370.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200524164110967.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200525144503510.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[Java_finalize]: https://blog.csdn.net/qq_40634846/article/details/106321803
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200525205711422.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/202005252128386.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200525221144642.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/2020052616441650.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[GC_STW_OopMap_safePoint_safeRegion]: https://blog.csdn.net/qq_40634846/article/details/106451671
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20200531135921588.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20200531140738697.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20200531193655560.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/20200531194001406.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 12]: https://img-blog.csdnimg.cn/20200531201359900.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70 13]: https://img-blog.csdnimg.cn/20200531214610474.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2,size_16,color_FFFFFF,t_70
[20200531214659377.png]: https://img-blog.csdnimg.cn/20200531214659377.png
[jvm]: https://blog.csdn.net/qq_40634846/article/details/106425738
[jvm 1]: https://blog.csdn.net/qq_40634846/article/details/106438170
[Java_Java Memory Model_JMM]: https://blog.csdn.net/qq_40634846/article/details/106471720