深入理解Java虚拟机：JVM内存管理与垃圾收集理论

男娘i 2022-10-17 10:38 108阅读 0赞

### 文章目录 ###

*  阅读的疑问？？？
 *  第二部分 自动内存管理
 *   *   *  第2章 Java内存区域与内存溢出异常
         *   *  1.程序计数器
             *  2.Java虚拟机栈
             *  3.本地方法栈
             *  4.Java堆
             *  5.方法区
             *  6.直接内存（我理解就是堆外内存吧）
         *  HotSpot虚拟机对象探秘
         *   *  1.对象的创建
             *  2.对象的内存布局
             *   *  对象头
                 *  实例数据
                 *  对齐填充
             *  3.对象的访问定位
         *  实战:OutOfMemoryError异常
         *   *   *  1.Java堆溢出（最常见）
                 *  2.虚拟机栈和本地方法栈溢出
                 *  3.方法区和运行时常量池溢出（常见）
                 *  4.本机直接内存溢出
         *  第3章 垃圾收集器与内存分配策略
         *   *  1.可达性分析算法
             *  2.引用
             *  3.finalize()方法（可与编程思想联动啦）
             *  4.回收方法区
             *  5.垃圾收集算法
             *   *  5.1 分代收集理论
                 *  5.2 标记-清除算法
                 *  5.3 标记-复制算法
                 *  5.4 标记-整理算法
             *  6. HotSpot的算法细节实现（就是如何找到存活对象，以及如何进行垃圾回收的）
             *   *  6.1根/GC roots节点枚举
                 *  6.2 安全点
                 *  6.3 安全区域
                 *  6.4 记忆集与卡表
                 *  6.5 写屏障（如何维护卡表?何时变脏？谁让他变脏）
                 *  6.6 并发的可达性分析

1.  HotSpot虚拟机中含有两个即时编译器，分别是编译耗时短但输出代码优化程度较低的客户端编译 器(简称为C1)以及编译耗时长但输出代码优化质量也更高的服务端编译器(简称为C2)  
    **- 能提前编译的提前编译，不能提前编译的交给 JVM 去解耦！**

# 阅读的疑问？？？ #

1.  import 导入的背后原理是？
2.  C++ 线程切换时的上下文保存在哪里？java 就是保存在
3.  本地(Native) 方法服务是什么东西？
4.  即时编译技术，逃逸分析技术，栈上分配、标量替换优化，轻量级锁、重量级锁，元空间
5.  对类型的卸载是什么意思？
6.  String 类的 intern() 方法怎么玩？
7.  对象的内存布局中对齐填充(Padding)与 OS 中内存对齐的关系？
8.  为什么对象头需要存储这么多的东西呐？
9.  基本类型与包装的基本类型有什么区别？为什么说基本类型快？
10. 为什么对于不同版本的Java虚拟机和不同的操作系统，栈容量最小值可能会有所限制，这主要取决于操作系统内存分页大小。
11. 如何自定义类加载器？比如：大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类框架
12.

# 第二部分 自动内存管理 #

### 第2章 Java内存区域与内存溢出异常 ###

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

#### 1.程序计数器 ####

1.  当前线程所执行的字节码的行号指示器。协程应该就是通过控制它来实现的。
2.  如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地 址;如果正在执行的是本地(N at ive)方法，这个计数器值则应为空(U ndefined)。此内存区域是唯 一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。

#### 2.Java虚拟机栈 ####

虚拟机栈描述的是Java方法执行的线程内存模型:每个方法被执行的时候，Java虚拟机都 会同步创建一个栈帧用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。  
14. 局部变量表（存放了编译期可知的各种Java虚拟机基本数据类型(boolean、byte、char、short、int、 float、long、double)、对象引用(reference类型，它并不等同于对象本身，可能是一个指向对象起始 地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置)和returnAddress 类型(指向了一条字节码指令的地址)）所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定 的，在方法运行期间不会改变局部变量表的大小。  
15. 在《Java虚拟机规范》中，对这个内存区域规定了两类异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常;如果Java虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够的内存会抛出 OutOfMemoryError异常。  
16. 只要是申请到内存就只会发生 StackOverflowError异常，如果无法申请到才会发生 OutOfMemoryError 异常。

#### 3.本地方法栈 ####

1.  作用同Java虚拟机栈，区别只是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则是为虚拟机使用到的本地(Native) 方法服务。

#### 4.Java堆 ####

1.  根据《Java虚拟机规范》的规定，Java堆可以处于物理上不连续的内存空间中
2.  在Java堆中没有内存完成实例分配，并且堆也无法再 扩展时，Java虚拟机将会抛出 OutOfMemoryError 异常。

#### 5.方法区 ####

1.  方法区(Method Area)与Java堆一样，是**各个线程共享的内存区域**，它用于存储已被虚拟机加载 的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
2.  这区域的内存回收目标主要是针对**常量池的回收和对类型的卸载**，一般来说这个区域的回收效果比较难令人满意，尤 其是类型的卸载，条件相当苛刻，但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列 表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存 泄漏。
3.  6.运行时常量池（属于方法区的一部分）：Class文件中除了有类的版本、字 段、方法、接口等描述信息外，还有一项信息是**常量池表**(Constant Pool Table)，用于**存放编译期生成的各种字面量与符号引用**，这部分内容将在类加载后存放到方法区的运行时常量池中。
4.  Java语言并不要求常量 一定只有编译期才能产生，也就是说，并非预置入Class文件中常量池的内容才能进入方法区运行时常 量池，运行期间也可以将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的  
    intern()方法。

#### 6.直接内存（我理解就是堆外内存吧） ####

### HotSpot虚拟机对象探秘 ###

#### 1.对象的创建 ####

1.  检查这个指令的参数是否能在常量池中定位到 一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程
2.  Java编译器会在遇到new关键字的地方同时生成new指令和invokesp ecial指令，这两条字节码指令

#### 2.对象的内存布局 ####

在HotSpot虚拟机里，对象在堆内存中的存储布局可以划分为三个部分:**对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)**。

##### 对象头 #####

1.  HotSpot虚拟机对象的对象头部分包括两类信息。第一类是用于**存储对象自身的运行时数据**，如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部 分数据的长度在32位和64位的虚拟机(未开启压缩指针)中分别为32个比特和64个比特，官方称它 为“Mark Word”。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 1]
2.  对象头的另外一部分是**类型指针，即对象指向它的类型元数据的指针，Java虚拟机通过这个指针 来确定该对象是哪个类的实例**
3.  如果对象是一个Java数组，那**在对象头中还必须有一块用于记录数组长度的数据**，因为虚拟机可以通过普通 Java对象的元数据信息确定Java对象的大小，但是如果数组的长度是不确定的，将无法通过元数据中的信息推断出数组的大小（我理解应该也是为了能够快速获取长度size等值）。

##### 实例数据 #####

实例数据部分是对象真正存储的有效信息，即我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的字段都必须记录起来。这部分的存储顺序会 受到虚拟机**分配策略参数(-XX:FieldsAllocationSty le参数)和字段在Java源码中定义顺序的影响**。 HotSpot虚拟机默认的分配顺序为longs/doubles、ints、shorts/chars、bytes/booleans、oops(Ordinary Object Pointers，OOPs)，从以上默认的分配策略中可以看到，相同宽度的字段总是被分配到一起存放（**其实可以看出真的是为了内存对齐**），在满足这个前提条件的情况下，**在父类中定义的变量会出现在子类之前。如果HotSpot虚拟机的 +XX:CompactFields参数值为true(默认就为true)，那子类之中较窄的变量也允许插入父类变量的空 隙之中，以节省出一点点空间。**

##### 对齐填充 #####

占位的作用！

#### 3.对象的访问定位 ####

对象访问方式也是由虚拟机实 现而定的，主流的访问方式主要有使用**句柄和直接指针**两种:  
29. 使用句柄来访问的最大好处就是reference中存储的是稳定句柄地址，在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针，而 reference本身不需要被修改。（解耦啦）

### 实战:OutOfMemoryError异常 ###

##### 1.Java堆溢出（最常见） #####

1.  第一步首先应确认内存中导致OOM的对象是否是必要的，也就是要先**分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)**
2.  如果是内存泄漏，可**进一步通过工具查看泄漏对象到GC Roots的引用链，找到泄漏对象是通过怎样的引用路径、与哪些GC Roots相关联，才导致垃圾收集器无法回收它们，根据泄漏对象的类型信息 以及它到GC Roots引用链的信息**，一般可以比较准确地定位到这些对象创建的位置，进而找出产生内存泄漏的代码的具体位置。

##### 2.虚拟机栈和本地方法栈溢出 #####

由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此对于HotSpot来说，**-Xoss参数**(设置 本地方法栈大小)虽然存在，但实际上是没有任何效果的，**栈容量只能由-Xss参数来设定**。一共存在两种异常：  
32. 如 果 线 程 请 求 的 栈 深 度 大 于 虚 拟 机 所 允 许 的 最 大 深 度 ， 将 抛 出 St a c k O v e r f l o w E r r o r 异 常 。  
33. 如果虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出 OutOfMemoryError 异常。

##### 3.方法区和运行时常量池溢出（常见） #####

1.  使用\*\*-Xmx参数限制最大堆\*\*到6M B
2.  Caused by: java.lang.OutOfMemoryError: PermGen space

##### 4.本机直接内存溢出 #####

1.  直接内存(Direct Memory)的容量大小可通过\*\*-XX:MaxDirectMemorySize参数来指定\*\*，如果不 去指定，则默认与Java堆最大值(由-Xmx指定)一致

/** * VM Args:-Xmx20M -XX:MaxDirectMemorySize=10M * @author zzm */
        public class DirectMemoryOOM { 
            private static final int _1MB = 1024 * 1024;
            
            public static void main(String[] args) throws Exception { 
                Field unsafeField = Unsafe.class.getDeclaredFields()[0];
                unsafeField.setAccessible(true);
                Unsafe unsafe = (Unsafe) unsafeField.get(null);
                while (true) { 
                    unsafe.allocateMemory(_1MB);
                }
            }
        }

由直接内存导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见有什么明显的异常 情况，如果读者发现**内存溢出之后产生的Dump文件很小，而程序中又直接或间接使用了DirectM emory(典型的间接使用就是NIO)**，那就可以考虑重点检查一下直接内存方面的原因了。

### 第3章 垃圾收集器与内存分配策略 ###

#### 1.可达性分析算法 ####

算法的基本思路就是通过 一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过 程所走过的路径称为“引用链”(Reference Chain)，如果某个对象到GC Roots间没有任何引用链相连， 或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 2]

#### 2.引用 ####

在JDK 1.2版之前，Java里面的引用是很传统的定义: 如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称该reference数据是代表 某块内存、某个对象的引用。这种定义并没有什么不对，只是现在看来有些过于狭隘了，一个对象在 这种定义下只有“被引用”或者“未被引用”两种状态，对于描述一些“食之无味，弃之可惜”的对象就显 得无能为力。譬如我们希望能描述一类对象:**当内存空间还足够时，能保留在内存之中，如果内存空 间在进行垃圾收集后仍然非常紧张，那就可以抛弃这些对象**——很多系统的缓存功能都符合这样的应用场景。  
在JDK 1.2版之后，扩充了四种引用类型：

1.  ·强引用是最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回 收掉被引用的对象。
2.  ·软引用是用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，**在系统将要发生内 存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存， 才会抛出内存溢出异常**。在JDK 1.2版之后提供了SoftReference类来实现软引用。
3.  弱引用也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，**被弱引用关联的对象只 能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只 被弱引用关联的对象**。在JDK 1.2版之后提供了WeakReference类来实现弱引用。
4.  ·虚引用也称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用的 存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。**为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知**。在JDK 1.2版之后提供 了Phant omReference类来实现虚引用。

#### 3.finalize()方法（可与编程思想联动啦） ####

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，这时候它们暂时还处于“缓 刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

1.  如果对象在进行可达性分析后发现没 有与GC Roots相连接的引用链，那它将会被第一次标记。
2.  随后进行一次筛选，**筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”**

一次对象的自我拯救演示：

/** 1. 此代码演示了两点: 2. 1.对象可以在被GC时自我拯救。 3. 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次 * @author zzm */
    public class FinalizeEscapeGC { 
        public static FinalizeEscapeGC SAVE_HOOK = null;
    
        public void isAlive() { 
            System.out.println("yes, i am still alive :)");
        }
    
        @Override
        protected void finalize() throws Throwable { 
            super.finalize();
            System.out.println("finalize method executed!");
            FinalizeEscapeGC.SAVE_HOOK = this;
        }
    
        public static void main(String[] args) throws Throwable { 
            SAVE_HOOK = new FinalizeEscapeGC();
    //对象第一次成功拯救自己
            SAVE_HOOK = null;
            System.gc();
    // 因为Finalizer方法优先级很低，暂停0.5秒，以等待它
            Thread.sleep(500);
            if (SAVE_HOOK != null) { 
                SAVE_HOOK.isAlive();
            } else { 
                System.out.println("no, i am dead :(");
            }
    // 下面这段代码与上面的完全相同，但是这次自救却失败了
    
        }
    }
    // SAVE_HOOK=null;
    // System.gc();
    // // 因为Finalizer方法优先级很低，暂停0.5秒，以等待它 Thread.sleep(500);
    // if(SAVE_HOOK!=null){ 
    // SAVE_HOOK.isAlive();}else{ 
    // System.out.println("no, i am dead :(");}

#### 4.回收方法区 ####

堆的一次垃圾回收可以回收掉70%至99%的内存空间。  
方法区的垃圾收集主要回收两部分内容:**废弃的常量和不再使用的类型**。

*  举个常量池中字面量回收的例子，假如一个字符串“ java”曾经进入常量池中，但是当前系统又没有任何一个字符串对象的值是“ java”，换句话说，已经没有任何字符串对象引用 常量池中的“ java”常量，且虚拟机中也没有其他地方引用这个字面量。如果在这时发生内存回收，而且 垃圾收集器判断确有必要的话，这个“ java”常量就将会被系统清理出常量池。常量池中其他类(接 口)、方法、字段的符号引用也与此类似。
 *  判定一个类型是否属于“不再被使用的类”的条件就 比较苛刻了。需要同时满足下面三个条件:
    
    1.  该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例
    2.  加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的
    3.  ·该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

关于是否要对类型进行回收，HotSpot虚拟机提供了- Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClass-Loading、-XX: +TraceClassUnLoading查看类加载和卸载信息，其中-verbose:class和-XX:+TraceClassLoading可以在  
Product版的虚拟机中使用，-XX:+TraceClassUnLoading参数需要FastDebug版\[1\]的虚拟机支持。

#### 5.垃圾收集算法 ####

##### 5.1 分代收集理论 #####

建立在两个分 代假说之上:

1.  弱分代假说(Weak Generational Hypothesis):绝大多数对象都是朝生夕灭的。
2.  强分代假说(Strong Generational Hypothesis):熬过越多次垃圾收集过程的对象就越难以消亡。  
    在Java堆划分出不同的区域之后，垃圾收集器才可以每次只回收其中某一个或者某些部分的区域 ——因而才有了“Minor GC”“Major GC”“Full GC”这样的回收类型的划分;也才能够**针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法**——因而发展出了\*\*“标记-复制算法”“标记-清除算 法”“标记-整理算法\*\*”等针对性的垃圾收集算法。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 3]

##### 5.2 标记-清除算法 #####

算法分为“标记”和“清除”两个阶段:首先标记出所有需要回 收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回 收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。  
但是有两个缺点：

1.  第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低。（**感觉这个问题怎么做都是这样啊？除非是大部分需要回收时，我只快速的先回收一部分**）
2.  内存空间的碎片化问题，标记、清除之后会产生大 量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找 到足够的连续内存而不得不提前触发另一次垃圾收集动作。

##### 5.3 标记-复制算法 #####

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，1969年Fenichel提出了一种称为“半区复制”(Semispace Copying)的垃圾收集算法，它将可用 内存按容量划分为大小相等的**两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着 的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉**。如果内存中多数对象都是存 活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复 制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有 空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效，不过其缺陷 也显而易见，这种复制回收算法的代价是将可用内存缩小为了原来的一半，空间浪费未免太多了一 点。

##### 5.4 标记-整理算法 #####

方法与标记清除基本相同，但是他是一种移动式的方法，就是**将所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。** 移动需要时间，以及需要更新所有引用这些对象的地方，而且在移动的过程中程序是不可用的（这个和我们现在做的私有化一样）。不移动，那就是造成很多的内存锁片，需要类似于slab分配器之类的东西来进行内存管理。

#### 6. HotSpot的算法细节实现（就是如何找到存活对象，以及如何进行垃圾回收的） ####

##### 6.1根/GC roots节点枚举 #####

固定可作为GC Roots的节点主要在**全局性的引用(例如常量或类静态属性)与执行上下文(例如 栈帧中的本地变量表)中**，尽管目标明确，但查找过程要做到高效并非一件容易的事情，现在Java应用越做越庞大，光是方法区的大小就常有数百上千兆，里面的类、常量等更是恒河沙数，若要逐个检查以这里为起源的引用肯定得消耗不少时间。  
**Q：问什么从这些根节点开始呐？**

*  枚举根节点时也是必须要停顿的
 *  当用户线程停顿下来之后，其实并不需要一个不漏地检查完所有 执行上下文和全局的引用位置，**虚拟机应当是有办法直接得到哪些地方存放着对象引用的**。在HotSpot 的解决方案里，是使用一组称为OopMap的数据结构来达到这个目的。一旦类加载动作完成的时候， HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，在即时编译(见第11章)过程中，也 会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样收集器在扫描时就可以直接得知这些信 息了，并不需要真正一个不漏地从方法区等GC Roots开始查找。

##### 6.2 安全点 #####

引用关系会发生变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成 对应的OopMap，那将会需要大量的额外存储空间，这样垃圾收集伴随而来的空间成本就会变得无法忍受的高昂。  
实际上HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录 了这些信息，这些位置被称为安全点(Safep oint)

因此：是**在安全点的时候，JVM进行的垃圾收集**。

安全点的两个思考问题：

1.  如何选择安全点？
2.  如何在垃圾收集发生时让所有线程(这里其实不包括 执行JNI调用的线程)都跑到最近的安全点，然后停顿下来。  
    答：

*  安全点位置的选取基本上是以“**是否具有让程序长时间执行的特征”为标准** 进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而 长时间执行，**“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转 等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点**。
 *  第二个问题有两种解决解决方案：（1）抢先式中断不需要线程的执行代码 主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地 方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎没有虚 拟机实现采用抢先式中断来暂停线程响应GC事件。（2）主动式中断的思想是当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一 个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最 近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的。

##### 6.3 安全区域 #####

**如何确定安全区域？为什么会这样检查虚拟机？收到的信号是什么？从哪里来？**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 4]

##### 6.4 记忆集与卡表 #####

记忆集：只需在新生代上建立一个全局的数据结构(该结构被称 为“记忆集”，Remembered Set)，这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。此后当发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。

收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，并不需要了解这些跨代指针的全部细节。因此有了下面的这些记录精度：

1.  字长精度:每个记录精确到一个机器字长(就是处理器的寻址位数，如常见的32位或64位，这个 精度决定了机器访问物理内存地址的指针长度)，该字包含跨代指针。
2.  对象精度:每个记录精确到一个对象，该对象里有字段含有跨代指针。
3.  卡精度（卡表）:每个记录精确到一块内存区域，该区域内有对象含有跨代指针。

卡表最简单的形式可以只是一个字节数组，而HotSpot虚拟机确实也是这样做的。  
字节数组 CARD\_TABLE 的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个 内存块被称作“卡页”(Card Page)。一般来说，卡页大小都是以2的N次幂的字节数。  
**一个卡页的内存中通常包含不止一个对象，只要卡页内有一个(或更多)对象的字段存在着跨代 指针，那就将对应卡表的数组元素的值标识为1，称为这个元素变脏(Dirty)，没有则标识为0**。在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它 们加入GC Roots中一并扫描。

##### 6.5 写屏障（如何维护卡表?何时变脏？谁让他变脏） #####

**何时变脏**：有其他分代区域中对象引用了本区域对象时，其对应的卡表元素就应该变脏，变脏时间点原则上应该发生在引用类型字段赋值的那一刻。  
**如何变脏**：如果是解释执行的字节码，JVM介入处理。如果是编译执行的场景，那就使用**写屏障**(Write Barrier)技术维护卡表状态。写屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个环形(Around)通知，供程序执行额外的动作，也就是说赋值的 前后都在写屏障的覆盖范畴内。在赋值前的部分的写屏障叫作写前屏障(Pre-Write Barrier)，在赋值 后的则叫作写后屏障(Post-Write Barrier)。

// 写后屏障更新卡表
    void oop_field_store(oop* field, oop new_value) {  // 引用字段赋值操作
    *field = new_value;
    // 写后屏障，在这里完成卡表状态更新 post_write_barrier(field, new_value);
    }

**伪共享问题**：其实就是缓存行冲突的问题。具体见书吧。

##### 6.6 并发的可达性分析 #####

在根节点枚举这个步骤中，由于GC Roots相比 起整个Java堆中全部的对象毕竟还算是极少数，且在各种优化技巧(如OopMap)的加持下，它带来 的停顿已经是非常短暂且相对固定(不随堆容量而增长)的了。可从GC Roots再继续往下遍历对象 图，这一步骤的停顿时间就必定会与Java堆容量直接成正比例关系了:堆越大，存储的对象越多，对 象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70]: /images/20221014/9a4c91b15d4d4898b5fb0fd2c2b0673e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 1]: /images/20221014/01e7e46b88424844a25241e8dde4a141.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 2]: /images/20221014/704ae945ef1a49109eb8b362158203a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 3]: /images/20221014/1fa4945d50174e51b428a3b68ab2ed5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXNoZW5neGlfcm9vdA_size_16_color_FFFFFF_t_70 4]: /images/20221014/b4a4062747bb494c88a27ff530e8d50b.png