学习之 JVM原理基础以及GC回收原理

迷南。 2022-03-20 10:30 229阅读 0赞

转载至：Java烂猪皮  百家号

转载：[传送门][Link 1]

**目录**

1：什么是JVM

2：JRE/JDK/JVM是什么关系

3：JVM原理

4：JVM的体系结构

5：JVM运行时数据区

第一块：PC寄存器

第二块：JVM栈

第三块：堆（Heap）

第四块：方法区域（Method Area）

第五块：运行时常量池（Runtime Constant Pool）

第六块：本地方法堆栈（Native Method Stacks）

6：对象“已死”的判定算法

有两种算法可以判定对象是否存活：

7：JVM垃圾回收

8：垃圾收集算法

1、标记-清除算法

2、复制算法

3、标记-整理算法

4、分代收集算法

9：垃圾收集器

1.Serial收集器

2.ParNew收集器

3.Parallel Scavenge收集器

4.Serial Old收集器

5.Parallel Old收集器

6.CMS收集器

CMS收集器有3个缺点：

7.G1收集器

G1收集器特性：

10：基本结构

--------------------

# 1：什么是**JVM** #

**JVM**是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收堆和一个存储方法域。 JVM屏蔽了与具体操作系统平台相关的信息，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行。

# 2：**JRE/JDK/JVM**是什么关系 #

**JRE**(JavaRuntimeEnvironment，Java运行环境)，也就是Java平台。所有的Java 程序都要在JRE下才能运行。普通用户只需要运行已开发好的java程序，安装JRE即可。

**JDK**(Java Development Kit)是程序开发者用来来编译、调试java程序用的开发工具包。JDK的工具也是Java程序，也需要JRE才能运行。为了保持JDK的独立性和完整性，在JDK的安装过程中，JRE也是 安装的一部分。所以，在JDK的安装目录下有一个名为jre的目录，用于存放JRE文件。

**JVM**(JavaVirtualMachine，Java虚拟机)是JRE的一部分。它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java语言最重要的特点就是跨平台运行。使用JVM就是为了支持与操作系统无关，实现跨平台。

# 3：JVM原理 #

JVM是java的核心和基础，在java编译器和os平台之间的虚拟处理器。它是一种利用软件方法实现的抽象的计算机基于下层的操作系统和硬件平台，可以在上面执行java的字节码程序。

![u_3384408353_2699854077_fm_173_app_25_f_JPEG_w_640_h_524_s_5EA8346301DFC1CA1EF5F0CA0000A0B1][]

java编译器只要面向JVM，生成JVM能理解的代码或字节码文件。Java源文件经编译成字节码程序，通过JVM将每一条指令翻译成不同平台机器码，通过特定平台运行。（比如jre java运行环境）

# 4：JVM的体系结构 #

![u_2437359893_1046499749_fm_173_app_25_f_JPEG_w_639_h_386_s_6840ED1E015C51C81A5CACF403004031][]

**类装载器**（ClassLoader）（用来装载.class文件）

**执行引擎**（执行字节码，或者执行本地方法）

**运行时数据区**（方法区、堆、java栈、PC寄存器、本地方法栈）

# 5：JVM运行时数据区 #

![u_2930353890_3785557893_fm_173_app_25_f_JPEG_w_428_h_379_s_05106532110E5549565520DA010080B2][]

## 第一块：PC寄存器 ##

**PC寄存器**是用于存储每个线程下一步将执行的JVM指令，如该方法为native的，则PC寄存器中不存储任何信息。

ps： 什么是Native Method 简单地讲，一个Native Method就是一个java调用非java代码的接口。一个Native Method是这样一个java的方法：该方法的实现由非java语言实现，比如C。这个特征并非java所特有，很多其它的编程语言都有这一机制，比如在C＋＋中，你可以用extern "C"告知C＋＋编译器去调用一个C的函数。  
"A native method is a Java method whose implementation is provided by non-java code."  
在定义一个native method时，并不提供实现体（有些像定义一个java interface），因为其实现体是由非java语言在外面实现的。

## 第二块：JVM栈 ##

**JVM栈**是线程私有的，每个线程创建的同时都会创建JVM栈，JVM栈中存放的为当前线程中局部基本类型的变量（java中定义的八种基本类型：boolean、char、byte、short、int、long、float、double）、部分的返回结果以及Stack Frame，非基本类型的对象在JVM栈上仅存放一个指向堆上的地址。

## 第三块：堆（Heap） ##

它是JVM用来存储对象实例以及数组值的区域，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中的对象的内存需要等待GC进行回收

![u_1096113343_900608897_fm_173_app_25_f_JPEG_w_472_h_212_s_F1B58B749B586C4954FCC1C60300E0BF][]

（1） **堆是JVM中所有线程共享的**，因此在其上进行对象内存的分配均需要进行加锁，这也导致了new对象的开销是比较大的

（2） Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配

（3） TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。

（4） 所有新创建的Object 都将会存储在新生代Yong Generation中。如果Young Generation的数据在一次或多次GC后存活下来，那么将被转移到OldGeneration。新的Object总是创建在Eden Space。

**总结 **

**1  栈是运行时的单位 , ****而堆是存储的单元**。

2 **栈解决程序的运行问题，即程序如何执行，或者说如何处理数据，**

**    堆解决的是数据存储的问题，即数据怎么放，放在哪儿**。

在**java**中一个线程就会相应有一个线程栈与之对应，这点很容易理解，因为不同的线程执行逻辑有所不同，因此需要一个独立的线程栈。

而堆则是所有线程共享的。

## 第四块：方法区域（Method Area） ##

（1）在Sun JDK中这块区域对应的为PermanetGeneration，又称为持久代。

（2）方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，当开发人员在程序中通过Class对象中的getName、isInterface等方法来获取信息时，这些数据都来源于方法区域，同时方法区域也是全局共享的，在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。

## 第五块：运行时常量池（Runtime Constant Pool） ##

存放的为类中的固定的常量信息、方法和Field的引用信息等，其空间从方法区域中分配。

## 第六块：本地方法堆栈（Native Method Stacks） ##

JVM采用本地方法堆栈来支持native方法的执行，此区域用于存储每个native方法调用的状态。

[navitive method解释][navitive method]

本地方法非常有用，因为它有效地扩充了jvm.事实上，我们所写的java代码已经用到了本地方法，在sun的java的并发（多线程）的机制实现中，许多与操作系统的接触点都用到了本地方法，这使得java程序能够超越java运行时的界限。有了本地方法，java程序可以做任何应用层次的任务。  
 JVM支持着java语言本身和运行时库，它是java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。然而不管怎 样，它毕竟不是一个完整的系统，它经常依赖于一些底层（underneath在下面的）系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的，还有，如果我们要使用一些java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法。  
ps: 最后需要提示的是，使用本地方法是有开销的，它丧失了java的很多好处。如果别无选择，我们可以选择使用本地方法。

# 6：对象“已死”的判定算法 #

由于程序计数器、Java虚拟机栈、本地方法栈都是线程独享，其占用的内存也是随线程生而生、随线程结束而回收。而Java堆和方法区则不同，线程共享，是GC的所关注的部分。

在堆中几乎存在着所有对象，GC之前需要考虑哪些对象还活着不能回收，哪些对象已经死去可以回收。

## 有两种算法可以判定对象是否存活： ##

1.）引用计数算法：给对象中添加一个引用计数器，每当一个地方应用了对象，计数器加1；当引用失效，计数器减1；当计数器为0表示该对象已死、可回收。但是它很难解决两个对象之间相互循环引用的情况。

2.）可达性分析算法：通过一系列称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连（即对象到GC Roots不可达），则证明此对象已死、可回收。Java中可以作为GC Roots的对象包括：虚拟机栈中引用的对象、本地方法栈中Native方法引用的对象、方法区静态属性引用的对象、方法区常量引用的对象。

在主流的商用程序语言（如我们的Java）的主流实现中，都是通过可达性分析算法来判定对象是否存活的。

# 7：JVM垃圾回收 #

**GC (Garbage Collection)的基本原理**：将内存中不再被使用的对象进行回收，GC中用于回收的方法称为收集器，由于GC需要消耗一些资源和时间，Java在对对象的生命周期特征进行分析后，按照新生代、旧生代的方式来对对象进行收集，以尽可能的缩短GC对应用造成的暂停

（1）对新生代的对象的收集称为minor GC；

（2）对旧生代的对象的收集称为Full GC；

（3）程序中主动调用System.gc()强制执行的GC为Full GC。

不同的对象引用类型， GC会采用不同的方法进行回收，JVM对象的引用分为了四种类型：

（1）强引用：默认情况下，对象采用的均为强引用（这个对象的实例没有其他对象引用，GC时才会被回收）

（2）软引用：软引用是Java中提供的一种比较适合于缓存场景的应用（只有在内存不够用的情况下才会被GC）

（3）弱引用：在GC时一定会被GC回收

（4）虚引用：由于虚引用只是用来得知对象是否被GC

## 8：垃圾收集算法 ##

解释：

jvm区域总体分两类，heap区和非heap区。heap区又分：Eden Space（伊甸园）、SurvivorSpace(幸存者区)、Tenured Gen（老年代-养老区）。 非heap区又分：Code Cache(代码缓存区)、PermGen（永久代）、Jvm Stack(。

HotSpot虚拟机GC算法采用分代收集算法：

1、一个人（对象）出来（new 出来）后会在EdenSpace（伊甸园）无忧无虑的生活，直到GC到来打破了他们平静的生活。GC会逐一问清楚每个对象的情况，有没有钱（此对象的引用）啊，因为GC想赚钱呀，有钱的才可以敲诈嘛。然后富人就会进入SurvivorSpace（幸存者区），穷人的就直接kill掉。

2、并不是进入SurvivorSpace（幸存者区）后就保证人身是安全的，但至少可以活段时间。GC会定期（可以自定义）会对这些人进行敲诈，亿万富翁每次都给钱，GC很满意，就让其进入了GenuredGen(养老区)。万元户经不住几次敲诈就没钱了，GC看没有啥价值啦，就直接kill掉了。

3、进入到养老区的人基本就可以保证人身安全啦，但是亿万富豪有的也会挥霍成穷光蛋，只要钱没了，GC还是kill掉。

分区的目的：新生区由于对象产生的比较多并且大都是朝生夕灭的，所以直接采用标记-清理算法。而养老区生命力很强，则采用复制算法，针对不同情况使用不同算法。

非heap区域中Perm Gen中放着类、方法的定义，jvmStack区域放着方法参数、局域变量等的引用，方法执行顺序按照栈的先入后出方式。  
原文：https://blog.csdn.net/zilaike/article/details/78227905

## 1、标记-清除算法 ##

最基础的算法，分标记和清除两个阶段：首先标记处所需要回收的对象，在标记完成后统一回收所有被标记的对象。

它有两点不足：一个效率问题，标记和清除过程都效率不高；一个是空间问题，标记清除之后会产生大量不连续的内存碎片（类似于我们电脑的磁盘碎片），空间碎片太多导致需要分配大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾回收动作。

![u_359042570_543545927_fm_173_app_25_f_JPG_w_376_h_323_s_6BA43D62C2EE54AA3A53E26F0200607F][]

## 2、复制算法 ##

为了解决效率问题，出现了“复制”算法，他将可用内存按容量划分为大小相等的两块，每次只需要使用其中一块。当一块内存用完了，将还存活的对象复制到另一块上面，然后再把刚刚用完的内存空间一次清理掉。这样就解决了内存碎片问题，但是代价就是可以用内容就缩小为原来的一半。

![u_2967745545_1523066655_fm_173_app_25_f_JPG_w_445_h_363_s_0BA47D22C2EF64AA586DCA7D02008077][]

## 3、标记-整理算法 ##

复制算法在对象存活率较高时就会进行频繁的复制操作，效率将降低。因此又有了标记-整理算法，标记过程同标记-清除算法，但是在后续步骤不是直接对对象进行清理，而是让所有存活的对象都向一侧移动，然后直接清理掉端边界以外的内存。

![u_1536382190_4047801599_fm_173_app_25_f_JPG_w_418_h_331_s_4BA53C62CAEE748A2E56E26F0200D07F][]

## 4、分代收集算法 ##

当前商业虚拟机的GC都是采用分代收集算法，这种算法并没有什么新的思想，而是根据对象存活周期的不同将堆分为：新生代和老年代，方法区称为永久代（在新的版本中已经将永久代废弃，引入了元空间的概念，永久代使用的是JVM内存而元空间直接使用物理内存）。

这样就可以根据各个年代的特点采用不同的收集算法。

![u_3211645559_2668684895_fm_173_app_25_f_JPG_w_343_h_288_s_4BE6336248FEBEC81AAB7640020090EA][]

新生代中的对象“朝生夕死”，每次GC时都会有大量对象死去，少量存活，使用复制算法。新生代又分为Eden区和Survivor区（Survivor from、Survivor to），大小比例默认为8:1:1。

老年代中的对象因为对象存活率高、没有额外空间进行分配担保，就使用标记-清除或标记-整理算法。

新产生的对象优先进去Eden区，当Eden区满了之后再使用Survivor from，当Survivor from 也满了之后就进行Minor GC（新生代GC），将Eden和Survivor from中存活的对象copy进入Survivor to，然后清空Eden和Survivor from，这个时候原来的Survivor from成了新的Survivor to，原来的Survivor to成了新的Survivor from。复制的时候，如果Survivor to 无法容纳全部存活的对象，则根据老年代的分配担保（类似于银行的贷款担保）将对象copy进去老年代，如果老年代也无法容纳，则进行Full GC（老年代GC）。

大对象直接进入老年代：JVM中有个参数配置-XX:PretenureSizeThreshold，令大于这个设置值的对象直接进入老年代，目的是为了避免在Eden和Survivor区之间发生大量的内存复制。

长期存活的对象进入老年代：JVM给每个对象定义一个对象年龄计数器，如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳，将被移入Survivor并且年龄设定为1。没熬过一次Minor GC，年龄就加1，当他的年龄到一定程度（默认为15岁，可以通过XX:MaxTenuringThreshold来设定），就会移入老年代。但是JVM并不是永远要求年龄必须达到最大年龄才会晋升老年代，如果Survivor 空间中相同年龄（如年龄为x）所有对象大小的总和大于Survivor的一半，年龄大于等于x的所有对象直接进入老年代，无需等到最大年龄要求。

# 9：垃圾收集器 #

垃圾收集算法是方法论，垃圾收集器是具体实现。JVM规范对于垃圾收集器的应该如何实现没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器差别较大，这里只看HotSpot虚拟机。

JDK7/8后，HotSpot虚拟机所有收集器及组合（连线）如下：

![u_487085512_1721060508_fm_173_app_25_f_JPG_w_433_h_210_s_35A2FF170824610B580FF0E30300602B][]

JVM有两种运行模式Server与Client。两种模式的区别在于，Client模式启动速度较快，Server模式启动较慢；但是启动进入稳定期长期运行之后Server模式的程序运行速度比Client要快很多。这是因为Server模式启动的JVM采用的是重量级的虚拟机，对程序采用了更多的优化；而Client模式启动的JVM采用的是轻量级的虚拟机。所以Server启动慢，但稳定后速度比Client远远要快。

使用[Java][] -version命令就能显示出当前虚拟机处于哪种模式。

VM启动时采用何种模式是在名为jvm.cfg的配置文件中配置的。   
在64位JDK中，jvm.cfg位置为：JAVA\_HOME/jre/lib/amd64/jvm.cfg。

ps: 64位因为只支持server模式，如果我们修改了配置，启动JVM时会报错，无法启动。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FsaWNlX3FpeGlu_size_16_color_FFFFFF_t_70][]

具体请看链接：[https://www.cnblogs.com/wxw7blog/p/7221756.html][https_www.cnblogs.com_wxw7blog_p_7221756.html]

## 1.Serial收集器 ##

Serial收集器是最基本、历史最久的收集器，曾是新生代手机的唯一选择。他是单线程的，只会使用一个CPU或一条收集线程去完成垃圾收集工作，并且它在收集的时候，必须暂停其他所有的工作线程，直到它结束，即“Stop the World”。停掉所有的用户线程，对很多应用来说难以接受。比如你在做一件事情，被别人强制停掉，你心里奔腾而过的“羊驼”还数的过来吗？

尽管如此，它仍然是虚拟机运行在client模式下的默认新生代收集器：简单而高效（与其他收集器的单个线程相比，因为没有线程切换的开销等）。

**工作示意图：**

![u_135532066_2786984977_fm_173_app_25_f_JPEG_w_445_h_168_s_4D42CD1A9CA0790B46D419DE030090B3][]

## 2.ParNew收集器 ##

ParNew收集器是Serial收集器的多线程版本，除了使用了多线程之外，其他的行为（收集算法、stop the world、对象分配规则、回收策略等）同Serial收集器一样。

是许多运行在Server模式下的JVM中首选的新生代收集器，其中一个很重还要的原因就是除了Serial之外，只有他能和老年代的CMS收集器配合工作。

**工作示意图：**

![u_1203340157_4083282235_fm_173_app_25_f_JPEG_w_477_h_203_s_6D428E1A86E04D0B00FCF8DC030050B1][]

## 3.Parallel Scavenge收集器 ##

新生代收集器，并行的多线程收集器。它的目标是达到一个可控的吞吐量（就是CPU运行用户代码的时间与CPU总消耗时间的比值，即 吞吐量=行用户代码的时间/\[行用户代码的时间+垃圾收集时间\]），这样可以高效率的利用CPU时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务。

## 4.Serial Old收集器 ##

Serial 收集器的老年代版本，单线程，“标记整理”算法，主要是给Client模式下的虚拟机使用。

另外还可以在Server模式下：

JDK 1.5之前的版本中雨Parallel Scavenge 收集器搭配使用

可以作为CMS的后背方案，在CMS发生Concurrent Mode Failure是使用

**工作示意图：**

![u_109463354_2893042386_fm_173_app_25_f_JPEG_w_442_h_161_s_4D928D1A9CA24D0314D00DCE030070B2][]

## 5.Parallel Old收集器 ##

Parallel Scavenge的老年代版本，多线程，“标记整理”算法，JDK 1.6才出现。在此之前Parallel Scavenge只能同Serial Old搭配使用，由于Serial Old的性能较差导致Parallel Scavenge的优势发挥不出来，尴了个尬~~

Parallel Old收集器的出现，使“吞吐量优先”收集器终于有了名副其实的组合。在吞吐量和CPU敏感的场合，都可以使用Parallel Scavenge/Parallel Old组合。

**组合的工作示意图如下：**

![u_3662245_3282035343_fm_173_app_25_f_JPEG_w_498_h_186_s_ED228C1AC4A05D0342F955E80300E022][]

## 6.CMS收集器 ##

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器，停顿时间短，用户体验就好。

基于“标记清除”算法，并发收集、低停顿，运作过程复杂，分4步：

1)初始标记：仅仅标记GC Roots能直接关联到的对象，速度快，但是需要“Stop The World”

2)并发标记：就是进行追踪引用链的过程，可以和用户线程并发执行。

3)重新标记：修正并发标记阶段因用户线程继续运行而导致标记发生变化的那部分对象的标记记录，比初始标记时间长但远比并发标记时间短，需要“Stop The World”

4)并发清除：清除标记为可以回收对象，可以和用户线程并发执行

由于整个过程耗时最长的并发标记和并发清除都可以和用户线程一起工作，所以总体上来看，CMS收集器的内存回收过程和用户线程是并发执行的。

**工作示意图：**

![u_3234730303_4042113782_fm_173_app_25_f_JPEG_w_515_h_211_s_4512453286E07D035C5001C40300E0B1][]

### CMS收集器有3个缺点： ###

**1)对CPU资源非常敏感**

并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低。

CMS的默认收集线程数量是=(CPU数量+3)/4；当CPU数量多于4个，收集线程占用的CPU资源多于25%，对用户程序影响可能较大；不足4个时，影响更大，可能无法接受。

**2)无法处理浮动垃圾**（在并发清除时，用户线程新产生的垃圾叫浮动垃圾）,可能出现"Concurrent Mode Failure"失败。

并发清除时需要预留一定的内存空间，不能像其他收集器在老年代几乎填满再进行收集；如果CMS预留内存空间无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败；这时JVM启用后备预案：临时启用Serail Old收集器，而导致另一次Full GC的产生；

**3)产生大量内存碎片**：CMS基于"标记-清除"算法，清除后不进行压缩操作产生大量不连续的内存碎片，这样会导致分配大内存对象时，无法找到足够的连续内存，从而需要提前触发另一次Full GC动作。

## 7.G1收集器 ##

**G1**（Garbage-First）是JDK7-u4才正式推出商用的收集器。G1是面向服务端应用的垃圾收集器。它的使命是未来可以替换掉CMS收集器。

### G1收集器特性： ###

**并行与并发**：能充分利用多CPU、多核环境的硬件优势，缩短停顿时间；能和用户线程并发执行。

**分代收集**：G1可以不需要其他GC收集器的配合就能独立管理整个堆，采用不同的方式处理新生对象和已经存活一段时间的对象。

**空间整合：**整体上看采用标记整理算法，局部看采用复制算法（两个Region之间），不会有内存碎片，不会因为大对象找不到足够的连续空间而提前触发GC，这点优于CMS收集器。

可预测的停顿：除了追求低停顿还能建立可以预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超N毫秒，这点优于CMS收集器。

**为什么能做到可预测的停顿？**

是因为可以有计划的避免在整个Java堆中进行全区域的垃圾收集。

G1收集器将内存分大小相等的独立区域（Region），新生代和老年代概念保留，但是已经不再物理隔离。

G1跟踪各个Region获得其收集价值大小，在后台维护一个优先列表；

每次根据允许的收集时间，优先回收价值最大的Region（名称Garbage-First的由来）；

这就保证了在有限的时间内可以获取尽可能高的收集效率。

对象被其他Region的对象引用了怎么办？

判断对象存活时，是否需要扫描整个Java堆才能保证准确？在其他的分代收集器，也存在这样的问题（而G1更突出）：新生代回收的时候不得不扫描老年代？无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描：每个Region都有一个对应的Remembered Set；每次Reference类型数据写操作时，都会产生一个Write Barrier 暂时中断操作；然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的 Region（其他收集器：检查老年代对象是否引用了新生代对象）；如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中；进行垃圾收集时，在GC根节点的枚举范围加入 Remembered Set ，就可以保证不进行全局扫描，也不会有遗漏。

**不计算维护Remembered Set的操作，回收过程可以分为4个步骤（与CMS较为相似）：**

**1)初始标记**：仅仅标记GC Roots能直接关联到的对象，并修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发运行时能在正确可用的Region中创建新对象，需要“Stop The World”

**2)并发标记**：从GC Roots开始进行可达性分析，找出存活对象，耗时长，可与用户线程并发执行

**3)最终标记**：修正并发标记阶段因用户线程继续运行而导致标记发生变化的那部分对象的标记记录。并发标记时虚拟机将对象变化记录在线程Remember Set Logs里面，最终标记阶段将Remember Set Logs整合到Remember Set中，比初始标记时间长但远比并发标记时间短，需要“Stop The World”

**4)筛选回收**：首先对各个Region的回收价值和成本进行排序，然后根据用户期望的GC停顿时间来定制回收计划，最后按计划回收一些价值高的Region中垃圾对象。回收时采用复制算法，从一个或多个Region复制存活对象到堆上的另一个空的Region，并且在此过程中压缩和释放内存；可以并发进行，降低停顿时间，并增加吞吐量。

工作示意图：

![u_1568821232_3529410632_fm_173_app_25_f_JPEG_w_511_h_205_s_6510C43294E06D0B1CD001CC0300E0B2][]

# 10：基本结构 #

从Java平台的逻辑结构上来看，我们可以从下图来了解JVM：

![u_660715579_524441876_fm_173_app_25_f_JPEG_w_640_h_382_s_679A378E14D8F5C806B21F6C0300B06C][]

从上图能清晰看到Java平台包含的各个逻辑模块，也能了解到JDK与JRE的区别。

[Link 1]: https://baijiahao.baidu.com/s?id=1605937053950156833&wfr=spider&for=pc
[u_3384408353_2699854077_fm_173_app_25_f_JPEG_w_640_h_524_s_5EA8346301DFC1CA1EF5F0CA0000A0B1]: /images/20220320/b3d3336cc9e74ceabc1d25f2e0cecd24.png
[u_2437359893_1046499749_fm_173_app_25_f_JPEG_w_639_h_386_s_6840ED1E015C51C81A5CACF403004031]: /images/20220320/d300c6c4a3964329a1717ab9caa04d36.png
[u_2930353890_3785557893_fm_173_app_25_f_JPEG_w_428_h_379_s_05106532110E5549565520DA010080B2]: /images/20220320/ca953dda5afd48be9a1555a67935c68d.png
[u_1096113343_900608897_fm_173_app_25_f_JPEG_w_472_h_212_s_F1B58B749B586C4954FCC1C60300E0BF]: /images/20220320/76a70f9913844f8e847745c030df9292.png
[navitive method]: https://blog.csdn.net/itmrchen/article/details/53065883
[u_359042570_543545927_fm_173_app_25_f_JPG_w_376_h_323_s_6BA43D62C2EE54AA3A53E26F0200607F]: /images/20220320/cd9470930eb846b88dced59e231002a7.png
[u_2967745545_1523066655_fm_173_app_25_f_JPG_w_445_h_363_s_0BA47D22C2EF64AA586DCA7D02008077]: /images/20220320/2c2a78c8d33c4db598f371c919b2593e.png
[u_1536382190_4047801599_fm_173_app_25_f_JPG_w_418_h_331_s_4BA53C62CAEE748A2E56E26F0200D07F]: /images/20220320/3a5bdd8bada34d339e8614817fb888a1.png
[u_3211645559_2668684895_fm_173_app_25_f_JPG_w_343_h_288_s_4BE6336248FEBEC81AAB7640020090EA]: /images/20220320/e9d819ce0d284fd59bcaad19b028a191.png
[u_487085512_1721060508_fm_173_app_25_f_JPG_w_433_h_210_s_35A2FF170824610B580FF0E30300602B]: /images/20220320/ffda141b60ad4ad68c0fe5be6a42f070.png
[Java]: http://lib.csdn.net/base/java
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FsaWNlX3FpeGlu_size_16_color_FFFFFF_t_70]: /images/20220320/7a1970dc2a184f52be926af7d0bf200d.png
[https_www.cnblogs.com_wxw7blog_p_7221756.html]: https://www.cnblogs.com/wxw7blog/p/7221756.html
[u_135532066_2786984977_fm_173_app_25_f_JPEG_w_445_h_168_s_4D42CD1A9CA0790B46D419DE030090B3]: /images/20220320/c2ed8dcf7dbd43ee9e59c615f767daab.png
[u_1203340157_4083282235_fm_173_app_25_f_JPEG_w_477_h_203_s_6D428E1A86E04D0B00FCF8DC030050B1]: /images/20220320/d087612f2692443aa0b3a2b0237e51db.png
[u_109463354_2893042386_fm_173_app_25_f_JPEG_w_442_h_161_s_4D928D1A9CA24D0314D00DCE030070B2]: /images/20220320/84a243d9668e486090f02a3986f9d1f0.png
[u_3662245_3282035343_fm_173_app_25_f_JPEG_w_498_h_186_s_ED228C1AC4A05D0342F955E80300E022]: /images/20220320/63146099d4054f60ab07a1019258468a.png
[u_3234730303_4042113782_fm_173_app_25_f_JPEG_w_515_h_211_s_4512453286E07D035C5001C40300E0B1]: /images/20220320/d6bb2a83c3f9457eb9876730e6b8cafb.png
[u_1568821232_3529410632_fm_173_app_25_f_JPEG_w_511_h_205_s_6510C43294E06D0B1CD001CC0300E0B2]: /images/20220320/ef7cbf141a1549079e69838034ad7270.png
[u_660715579_524441876_fm_173_app_25_f_JPEG_w_640_h_382_s_679A378E14D8F5C806B21F6C0300B06C]: /images/20220320/e970d42cf8534a64bb0021fe19ee3627.png