jvm源码初版

① jvm 基础篇-（4）-对象动态年龄计算规则

还没达到，大牛程度，可以看源码，看动态计算对象年龄的程度呦~

-XX:MaxTenuringThreshold=X X默认是15，15的含义是从eden-->survivor 对象年龄+1，survivor-->eden 对象年龄+1，直到年龄达到15后开始进入old Generation。

Hotspot遍历所有对象时， 按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了survivor区的一半时，取这个年龄和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值。
eg:
eg：Survivor区 = 64M，desired survivor = 32M，此时Survivor区中age<=2的对象累计大小为41M，41M大于32M，所以晋升年龄阈值被设置为2，下次Minor GC时将年龄超过2的对象被晋升到老年代。就会导致old generation 快速填满，触发old gc（old gc 有三处STW），所以这是建议调整 -XX:SurvivorRatio 参数。

1、如果固定按照MaxTenuringThreshold设定的阈值作为晋升条件： a）MaxTenuringThreshold设置的过大，原本应该晋升的对象一直停留在Survivor区，直到Survivor区溢出，一旦溢出发生，Eden+Svuvivor中对象将不再依据年龄全部提升到老年代，这样对象老化的机制就失效了。 b）MaxTenuringThreshold设置的过小，“过早晋升”即对象不能在新生代充分被回收，大量短期对象被晋升到老年代，老年代空间迅速增长，引起频繁的Major GC。分代回收失去了意义，严重影响GC性能。

2、相同应用在不同时间的表现不同：特殊任务的执行或者流量成分的变化，都会导致对象的生命周期分布发生波动，那么固定的阈值设定，因为无法动态适应变化，会造成和上面相同的问题。

总结来说，为了更好的适应不同程序的内存情况， 虚拟机并不总是要求对象年龄必须达到Maxtenuringthreshhold再晋级老年代 。

传送门 jvm-对象年龄(-XX:+PrintTenuringDistribution)

② JVM-安全点

Total time for which application threads were stop 超级长时间，这行日志代表什么，以及为什么时间会这么长

当GC发生时，每个线程只有进入了SafePoint才算是真正挂起，也就是真正的停顿，这个日志的含义是整个GC过程中STW的时间，配置了 -XX:+PrintGCApplicationStoppedTime 这个参数才会打印这个信息。

重点： 第一个 2.81 seconds 是JVM启动后的秒数，第二个 2.6 seconds 是 JVM发起STW的开始到结束的时间。特别地，如果是GC引发的STW，这条内容会紧挨着出现在GC log的下面。

有关安全点的详细说明，请移步：
JVM源码分析之安全点safepoint
[java JVM] Hotspot GC研究- GC安全点 (Safepoint&Stop The World)

等待所有用户线程进入安全点后并阻塞，做一些全局性操作的行为。

配置 -XX:+PrintSafepointStatistics –XX:PrintSafepointStatisticsCount=1 参数，虚拟机会打印如下日志文件:

RevokeBias、BulkRevokeBias、偏向锁取消情况。
Deoptimize、
G1IncCollectionPause GC GC 执行情况。

分析 -XX:+PrintSafepointStatistics –XX:PrintSafepointStatisticsCount=1 产生的日志信息基本上STW的原因都是RevokeBias或者BulkRevokeBias。这个是撤销偏向锁操作，虽然每次暂停的 时间很短，但是特别频繁出现也会很耗时。

一些高并发的系统中，禁掉JVM偏向锁优化，可以提升系统的吞吐量 。禁用偏向锁的参数为: -XX:-UseBiasedLocking

R大分析类似情况
调优建议
各种JVM参数说明
stw分析
R大的博客
安全点 stw说明
偏向锁

③ 简述jvm工作原理

Java是一种技术，它由四方面组成：Java编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API)。

运行期环境代表着Java平台，开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)，再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。

Java平台由Java虚拟机和Java应用程序接口搭建，Java语言则是进入这个平台的通道，用Java语言编写并编译的程序可以运行在这个平台上。

在Java平台的结构中, 可以看出，Java虚拟机(JVM) 处在核心的位置，是程序与底层操作系统和硬件无关的关键。它的下方是移植接口，移植接口由两部分组成：适配器和Java操作系统, 其中依赖于平台的部分称为适配器；JVM 通过移植接口在具体的平台和操作系统上实现；在JVM 的上方是Java的基本类库和扩展类库以及它们的API， 利用Java API编写的应用程序(application) 和小程序(Java applet) 可以在任何Java平台上运行而无需考虑底层平台, 就是因为有Java虚拟机(JVM)实现了程序与操作系统的分离，从而实现了Java 的平台无关性。

JVM在它的生存周期中有一个明确的任务，那就是运行Java程序，因此当Java程序启动的时候，就产生JVM的一个实例；当程序运行结束的时候，该实例也跟着消失了。下面我们从JVM的体系结构和它的运行过程这两个方面来对它进行比较深入的研究。

1、Java虚拟机的体系结构

·每个JVM都有两种机制：

①类装载子系统：装载具有适合名称的类或接口

②执行引擎：负责执行包含在已装载的类或接口中的指令

·每个JVM都包含：

方法区、Java堆、Java栈、本地方法栈、指令计数器及其他隐含寄存器

2、Java代码编译和执行的整个过程

也正如前面所说，Java代码的编译和执行的整个过程大概是：开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)，再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。

（1）Java代码编译是由Java源码编译器来完成，也就是Java代码到JVM字节码（.class文件）的过程。

2）Java字节码的执行是由JVM执行引擎来完成

Java代码编译和执行的整个过程包含了以下三个重要的机制:

·Java源码编译机制

·类加载机制

·类执行机制

 

（1）Java源码编译机制

Java 源码编译由以下三个过程组成：

①分析和输入到符号表

②注解处理

③语义分析和生成class文件

最后生成的class文件由以下部分组成：

①结构信息：包括class文件格式版本号及各部分的数量与大小的信息

②元数据：对应于Java源码中声明与常量的信息。包含类/继承的超类/实现的接口的声明信息、域与方法声明信息和常量池

③方法信息：对应Java源码中语句和表达式对应的信息。包含字节码、异常处理器表、求值栈与局部变量区大小、求值栈的类型记录、调试符号信息

（2）类加载机制 JVM的类加载是通过ClassLoader及其子类来完成的

④ JVM原理是什么

首先这里澄清两个概念：JVM实例和JVM执行引擎实例，JVM实例对应了一个独立运行的Java程序，而JVM执行引擎实例则对应了属于用户运行程序的线程；也就是JVM实例是进程级别，而执行引擎是线程级别的。JVM是什么？—JVM的生命周期JVM实例的诞生：当启动一个Java程序时，一个JVM实例就产生了，任何一个拥有publicstaticvoidmain(String[]args)函数的class都可以作为JVM实例运行的起点，既然如此，那么JVM如何知道是运行classA的main而不是运行classB的main呢？这就需要显式的告诉JVM类名，也就是我们平时运行Java程序命令的由来，如JavaclassAhelloworld,这里Java是告诉os运行SunJava2SDK的Java虚拟机，而classA则指出了运行JVM所需要的类名。JVM实例的运行：main（）作为该程序初始线程的起点，任何其他线程均由该线程启动。JVM内部有两种线程：守护线程和非守护线程，main（）属于非守护线程，守护线程通常由JVM自己使用，Java程序也可以标明自己创建的线程是守护线程。JVM实例的消亡：当程序中的所有非守护线程都终止时，JVM才退出；若安全管理器允许，程序也可以使用Runtime类或者System.exit()来退出。JVM是什么？—JVM的体系结构粗略分来，JVM的内部体系结构分为三部分，分别是：类装载器（ClassLoader）子系统，运行时数据区，和执行引擎。下面将先介绍类装载器，然后是执行引擎，最后是运行时数据区1、类装载器，顾名思义，就是用来装载.class文件的。JVM的两种类装载器包括：启动类装载器和用户自定义类装载器，启动类装载器是JVM实现的一部分，用户自定义类装载器则是Java程序的一部分，必须是ClassLoader类的子类。（下面所述情况是针对SunJDK1.2）动类装载器：只在系统类(JavaAPI的类文件)的安装路径查找要装入的类用户自定义类装载器：系统类装载器：在JVM启动时创建，用来在CLASSPATH目录下查找要装入的类其他用户自定义类装载器：这里有必要先说一下ClassLoader类的几个方法，了解它们对于了解自定义类装载器如何装载.class文件至关重要。(Stringname,bytedata[],intoffset,intlength) (Stringname,bytedata[],intoffset,intlength,);(Stringname) (Classc) defineClass用来将二进制class文件（新类型）导入到方法区,也就是这里指的类是用户自定义的类（也就是负责装载类）findSystemClass通过类型的全限定名，先通过系统类装载器或者启动类装载器来装载，并返回Class对象。ResolveClass:让类装载器进行连接动作（包括验证，分配内存初始化，将类型中的符号引用解析为直接引用），这里涉及到Java命名空间的问题，JVM保证被一个类装载器装载的类所引用的所有类都被这个类装载器装载，同一个类装载器装载的类之间可以相互访问，但是不同类装载器装载的类看不见对方，从而实现了有效的屏蔽。2、执行引擎：它或者在执行字节码，或者执行本地方法要说执行引擎，就不得不的指令集，每一条指令包含一个单字节的操作码，后面跟0个或者多个操作数。（一）指令集以栈为设计中心，而非以寄存器为中心这种指令集设计如何满足Java体系的要求：平台无关性：以栈为中心使得在只有很少register的机器上实现Java更便利compiler一般采用stack向连接优化器传递编译的中间结果，若指令集以stack为基础，则有利于运行时进行的优化工作与执行即时编译或者自适应优化的执行引擎结合，通俗的说就是使编译和运行用的数据结构统一，更有利于优化的开展。网络移动性：class文件的紧凑性。安全性：指令集中绝大部分操作码都指明了操作的类型。（在装载的时候使用数据流分析期进行一次性验证，而非在执行每条指令的时候进行验证，有利于提高执行速度）。（二）执行技术主要的执行技术有:解释，即时编译，自适应优化、芯片级直接执行其中解释属于第一代JVM，即时编译JIT属于第二代JVM，自适应优化（目前Sun的HotspotJVM采用这种技术）则吸取第一代JVM和第二代JVM的经验，采用两者结合的方式自适应优化：开始对所有的代码都采取解释执行的方式，并监视代码执行情况，然后对那些经常调用的方法启动一个后台线程，将其编译为本地代码，并进行仔细优化。若方法不再频繁使用，则取消编译过的代码，仍对其进行解释执行。3、运行时数据区：主要包括：方法区，堆，Java栈，PC寄存器，本地方法栈（1）方法区和堆由所有线程共享堆：存放所有程序在运行时创建的对象方法区：当JVM的类装载器加载.class文件，并进行解析，把解析的类型信息放入方法区。（2）Java栈和PC寄存器由线程独享，在新线程创建时间里（3）本地方法栈：存储本地方法调用的状态上边总体介绍了运行时数据区的主要内容，下边进行详细介绍，要介绍数据区，就不得不说明JVM中的数据类型。JVM中的数据类型：JVM中基本的数据单元是word,而word的长度由JVM具体的实现者来决定数据类型包括基本类型和引用类型，（1）基本类型包括：数值类型(包括除boolean外的所有的Java基本数据类型)，boolean（在JVM中使用int来表示，0表示false，其他int值均表示true）和returnAddress（JVM的内部类型，用来实现finally子句）。（2）引用类型包括：数组类型，类类型，接口类型前边讲述了JVM中数据的表示，下面让我们输入到JVM的数据区首先来看方法区：上边已经提到，方法区主要用来存储JVM从class文件中提取的类型信息，那么类型信息是如何存储的呢？众所周知，Java使用的是大端序（big?endian:即低字节的数据存储在高位内存上，如对于1234，12是高位数据，34为低位数据，则Java中的存储格式应该为12存在内存的低地址，34存在内存的高地址，x86中的存储格式与之相反）来存储数据，这实际上是在class文件中数据的存储格式，但是当数据倒入到方法区中时，JVM可以以任何方式来存储它。类型信息：包括class的全限定名，class的直接父类，类类型还是接口类型，类的修饰符（public,等），所有直接父接口的列表，Class对象提供了访问这些信息的窗口（可通过Class.forName(“”)或instance.getClass()获得），下面是Class的方法，相信大家看了会恍然大悟，（原来如此J）getName(),getSuperClass(),isInterface(),getInterfaces(),getClassLoader();static变量作为类型信息的一部分保存指向ClassLoader类的引用：在动态连接时装载该类中引用的其他类指向Class类的引用：必然的，上边已述该类型的常量池：包括直接常量（String，integer和floatpoint常量）以及对其他类型、字段和方法的符号引用（注意：这里的常量池并不是普通意义上的存储常量的地方，这些符号引用可能是我们在编程中所接触到的变量），由于这些符号引用，使得常量池成为Java程序动态连接中至关重要的部分字段信息：普通意义上的类型中声明的字段方法信息：类型中各个方法的信息编译期常量：指用final声明或者用编译时已知的值初始化的类变量class将所有的常量复制至其常量池或者其字节码流中。方法表：一个数组，包括所有它的实例可能调用的实例方法的直接引用（包括从父类中继承来的）除此之外，若某个类不是抽象和本地的，还要保存方法的字节码，操作数栈和该方法的栈帧，异常表。举例：classLava{ privateintspeed=5; voidflow(){} classVolcano{ publicstaticvoidmain(String[]args){ Lavalava=newLava(); lava.flow(); } } 运行命令JavaVolcano;（1）JVM找到Volcano.class倒入，并提取相应的类型信息到方法区。通过执行方法区中的字节码，JVM执行main（）方法，（执行时会一直保存指向Vocano类的常量池的指针）（2）Main（）中第一条指令告诉JVM需为列在常量池第一项的类分配内存（此处再次说明了常量池并非只存储常量信息），然后JVM找到常量池的第一项，发现是对Lava类的符号引用，则检查方法区，看Lava类是否装载，结果是还未装载，则查找“Lava.class”,将类型信息写入方法区，并将方法区Lava类信息的指针来替换Volcano原常量池中的符号引用，即用直接引用来替换符号引用。（3）JVM看到new关键字，准备为Lava分配内存，根据Volcano的常量池的第一项找到Lava在方法区的位置，并分析需要多少对空间，确定后，在堆上分配空间，并将speed变量初始为0，并将lava对象的引用压到栈中（4）调用lava的flow（）方法好了，大致了解了方法区的内容后，让我们来看看堆Java对象的堆实现：Java对象主要由实例变量（包括自己所属的类和其父类声明的）以及指向方法区中类数据的指针，指向方法表的指针，对象锁（非必需），等待集合（非必需），GC相关的数据（非必需）（主要视GC算法而定，如对于标记并清除算法，需要标记对象是否被引用，以及是否已调用finalize（）方法）。那么为什么Java对象中要有指向类数据的指针呢？我们从几个方面来考虑首先：当程序中将一个对象引用转为另一个类型时，如何检查转换是否允许？需用到类数据其次：动态绑定时，并不是需要引用类型，而是需要运行时类型，这里的迷惑是：为什么类数据中保存的是实际类型，而非引用类型？这个问题先留下来，我想在后续的读书笔记中应该能明白指向方法表的指针：这里和C++的VTBL是类似的，有利于提高方法调用的效率对象锁：用来实现多个线程对共享数据的互斥访问等待集合：用来让多个线程为完成共同目标而协调功过。（注意Object类中的wait(),notify(),notifyAll()方法）。Java数组的堆实现：数组也拥有一个和他们的类相关联的Class实例，具有相同dimension和type的数组是同一个类的实例。数组类名的表示：如[[LJava/lang/Object表示Object[][]，[I表示int[]，[[[B表示byte[][][]至此，堆已大致介绍完毕，下面来介绍程序计数器和Java栈程序计数器：为每个线程独有，在线程启动时创建，若thread执行Java方法，则PC保存下一条执行指令的地址。若thread执行native方法，则Pc的值为undefinedJava栈：Java栈以帧为单位保存线程的运行状态，Java栈只有两种操作，帧的压栈和出栈。每个帧代表一个方法，Java方法有两种返回方式，return和抛出异常，两种方式都会导致该方法对应的帧出栈和释放内存。帧的组成：局部变量区（包括方法参数和局部变量，对于instance方法，还要首先保存this类型，其中方法参数按照声明顺序严格放置，局部变量可以任意放置），操作数栈，帧数据区（用来帮助支持常量池的解析，正常方法返回和异常处理）。本地方法栈：依赖于本地方法的实现，如某个JVM实现的本地方法借口使用C连接模型，则本地方法栈就是C栈，可以说某线程在调用本地方法时，就进入了一个不受JVM限制的领域，也就是JVM可以利用本地方法来动态扩展本身。相信大家都明白JVM是什么了吧。原文链接： http://www.cnblogs.com/chenzhao/archive/2011/08/14/2137713.html

⑤ JVM是什么

JVM是Java虚拟机，所有的Java程序都在Java虚拟机中运。
JDK是Java开发工具包，用来开发Java程序。

jdk中有一个编译器，可以把你的java源代码编译成可以在虚拟机（jvm）
上运行的字节码（中间代码）.

⑥ 求《JVMG1源码分析和调优豆瓣》全文免费下载百度网盘资源,谢谢~

《JVM G1源码分析和调优豆瓣》网络网盘pdf最新全集下载:
链接: https://pan..com/s/1i8sXLpI7Ey-07u7mGCq2WA

⑦ 怎样查看java中for循环jvm的源码

方法：使用break。
public class RecTest {
/**
* @param args
*/
public static void main(String[] args) {
for(int i=0; i< 10; i++){
if(i==5){
break; //
}
System.out.print(i+" ");
}
}
}
解释：本程序实现的是打印：0、1、2、3、4.当i到5的时候满足条件 i==5；此时执行break操作，跳出本次for循环。

⑧ JVM_字节码文件(ClassFile)详解

我们知道 javac 命令可以将 .java 文件编译成 .class 文件，而这个 Class 文件 中包含了 Java虚拟机 指令集、符号表以及若干其他辅助信息；最终将在 Java虚拟机 运行。

本文是以 JVM8 为例的。

每一个 Class文件 都有如下的 ClassFile 文件结构：

先简单介绍一下 ClassFile 文件结构各部分含义：

描述符是表示字段或方法类型的字符串。

字段描述符表示类、实例或局部变量的类型。

从上面文法可以看出，字段描述符中一共有三个类型：

方法描述符包含 0 个或者多个参数描述符以及一个返回值描述符。

看了描述符，可能大家有点疑惑，泛型信息怎么表示啊?

常量池的通用格式如下：

目前 JVM8 中一共用 14 种常量类型，分别如下：

我们知道要使用一个字段或者调用一个方法，就必须知道字段或者方法所属类符号引用，和字段的名字和类型，方法的名字和方法参数类型以及方法返回值类型。
但是我们知道类是能继承的，那么子类调用父类的方法或者字段，这里的所属类符号引用，到底是子类本身还是父类的呢？

我们知道类,方法,字段都有不同的访问标志，在 Class 文件 中使用一个 u2 类型数据项来存储，也就是最多可以有 16 个不同标志位。
在类,方法,字段中有相同的标志，也有不同的标志，总体规划，我们可以借助 Modifier 类的源码来了解：

在 Modifier 类中，类的访问标志：

我们知道在 java 中类可以用的修饰符有: public , protected , private , abstract , static , final , strictfp 。

但是我们再看 Class 文件 中类的访问标志：

仔细看，你会发现有些不同点：

在 Modifier 类中，字段的访问标志：

我们知道在 java 中字段可以用的修饰符有: public , protected , private , static , final , transient 和 volatile 。

但是我们再看 Class 文件 中字段的访问标志：

Class 文件 中字段的访问标志和 java 中字段的修饰符差不多，只是多了 ACC_SYNTHETIC 和 ACC_ENUM 两个标志。

在 Modifier 类中，方法的访问标志：

我们知道在 java 中方法可以用的修饰符有:
public , protected , private , abstract , static , final , synchronized , synchronized 和 strictfp 。

但是我们再看 Class 文件 中方法的访问标志：

字段详情 field_info 的格式如下：

方法详情 method_info 的格式如下：

关于 Class 文件 中属性相关信息，我们再后面章节介绍。

我们可以通过 javap 的命令来阅读 Class 文件 中相关信息。

这个是最简单的一个类，没有任何字段和方法，只继承 Object 类，我们来看看它编译后的字节码信息，通过 javap -p -v T.class 的命令：

我们重点关注常量池相关信息，会发现虽然 T.class 很干净，但是也有 15 个常量，来我们依次分析：

与之前的例子相比较，多了一个字段和方法，那么得到的字节码信息如下：

但是你会发现常量池中怎么没有这个字段 name 的 CONSTANT_Fieldref_info 类型的常量呢？
那是因为我们没有使用这个字段。

多写了一个方法 test1 来调用 name 字段和 test 方法，那么得到的字节码信息如下：

这里定义一个父类 TParent ，有一个公共字段 name 和方法 say 。子类

⑨ G1从入门到放弃（一）

最近在看关于G1垃圾收集的文章，看了很多国内与国外的资料，本文对G1的这些资料进行了整理。这篇合适JVM垃圾回收有一定基础的同学，作为G1入门可以看一下，如果要死磕G1实现的内容细节。大家可以找 R大 。 个人认为R大是目前国内JVM领域研究的先驱了，当然R大也是不建议大家去看JVM的源码的。 为啥别读HotSpot VM的源码
G1系列第一篇文章会介绍G1的理论知识，不会做JVM源码的深入分析。第二篇准备介绍G1实践中的日志分析。

G1（Garbadge First Collector）作为一款JVM最新的垃圾收集器，可以解决CMS中Concurrent Mode Failed问题，尽量缩短处理超大堆的停顿，在G1进行垃圾回收的时候完成内存压缩，降低内存碎片的生成。G1在堆内存比较大的时候表现出比较高吞吐量和短暂的停顿时间，而且已成为Java 9的默认收集器。未来替代CMS只是时间的问题。

G1的内存结构和传统的内存空间划分有比较的不同。G1将内存划分成了多个大小相等的Region（默认是512K），Region逻辑上连续，物理内存地址不连续。同时每个Region被标记成E、S、O、H，分别表示Eden、Survivor、Old、Humongous。其中E、S属于年轻代，O与H属于老年代。
示意图如下：

H表示Humongous。从字面上就可以理解表示大的对象（下面简称H对象）。 当分配的对象大于等于Region大小的一半 的时候就会被认为是巨型对象。H对象默认分配在老年代，可以防止GC的时候大对象的内存拷贝。通过如果发现堆内存容不下H对象的时候，会触发一次GC操作。

在进行Young GC的时候，Young区的对象可能还存在Old区的引用， 这就是跨代引用的问题。为了解决Young GC的时候，扫描整个老年代，G1引入了 Card Table 和 Remember Set 的概念，基本思想就是用空间换时间。这两个数据结构是专门用来处理Old区到Young区的引用。Young区到Old区的引用则不需要单独处理，因为Young区中的对象本身变化比较大，没必要浪费空间去记录下来。

下图展示的是 RSet 与 Card 的关系。每个 Region 被分成了多个 Card ，其中绿色部分的 Card 表示该 Card 中有对象引用了其他 Card 中的对象，这种引用关系用蓝色实线表示。 RSet 其实是一个HashTable，Key是Region的起始地址，Value是 Card Table （字节数组）,字节数组下标表示 Card 的空间地址，当该地址空间被引用的时候会被标记为 dirty_card 。

关于RSet结构的维护，可以参考这篇 文章 ，这里不做过多的深入。

SATB的全称（Snapshot At The Beginning）字面意思是开始GC前存活对象的一个快照。SATB的作用是保证在并发标记阶段的正确性。如何理解这句话？
首先要介绍三色标记算法。

在GC扫描C之前的颜色如下：

在并发标记阶段，应用线程改变了这种引用关系

得到如下结果。

在重新标记阶段扫描结果如下

这种情况下C会被当做垃圾进行回收。Snapshot的存活对象原来是A、B、C，现在变成A、B了，Snapshot的完整遭到破坏了，显然这个做法是不合理。
G1采用的是 pre-write barrier 解决这个问题。简单说就是在并发标记阶段，当引用关系发生变化的时候，通过 pre-write barrier 函数会把这种这种变化记录并保存在一个队列里，在JVM源码中这个队列叫 satb_mark_queue 。在remark阶段会扫描这个队列，通过这种方式，旧的引用所指向的对象就会被标记上，其子孙也会被递归标记上，这样就不会漏标记任何对象，snapshot的完整性也就得到了保证。

这里引用R大对SATB的解释：

SATB的方式记录活对象，也就是那一时刻对象snapshot, 但是在之后这里面的对象可能会变成垃圾, 叫做浮动垃圾（floating garbage），这种对象只能等到下一次收集回收掉。在GC过程中新分配的对象都当做是活的，其他不可达的对象就是死的。
如何知道哪些对象是GC开始之后新分配的呢？
在Region中通过top-at-mark-start（TAMS）指针，分别为prevTAMS和nextTAMS来记录新配的对象。示意图如下：

每个region记录着两个top-at-mark-start（TAMS）指针，分别为prevTAMS和nextTAMS。在TAMS以上的对象就是新分配的，因而被视为隐式marked。 这里引用R大的解释。

其中top是该region的当前分配指针，[bottom, top)是当前该region已用（used）的部分，[top, end)是尚未使用的可分配空间（unused）。
(1): [bottom, prevTAMS): 这部分里的对象存活信息可以通过prevBitmap来得知
(2): [prevTAMS, nextTAMS): 这部分里的对象在第n-1轮concurrent marking是隐式存活的
(3): [nextTAMS, top): 这部分里的对象在第n轮concurrent marking是隐式存活的

Young GC 回收的是所有年轻代的Region。 当E区不能再分配新的对象时就会触发 。E区的对象会移动到S区，当S区空间不够的时候，E区的对象会直接晋升到O区，同时S区的数据移动到新的S区，如果S区的部分对象到达一定年龄，会晋升到O区。
Yung GC过程示意图如下：

Mixed GC 翻译过来叫混合回收。之所以叫混合是因为回收所有的年轻代的Region+部分老年代的Region。
1、为什么是老年代的 部分 Region？
2、什么时候触发Mixed GC?
这两个问题其实可以一并回答。回收 部分 老年代是参数 -XX:MaxGCPauseMillis ，用来指定一个G1收集过程目标停顿时间，默认值200ms，当然这只是一个期望值。G1的强大之处在于他有一个停顿预测模型（Pause Prediction Model），他会有选择的挑选 部分 Region，去尽量满足停顿时间，关于G1的这个模型是如何建立的，这里不做深究。
Mixed GC的触发也是由一些参数控制。比如 XX: 表示老年代占整个堆大小的百分比，默认值是45%，达到该阈值就会触发一次Mixed GC。

Mixed GC主要可以分为两个阶段：
1、全局并发标记（global concurrent marking）
全局并发标记又可以进一步细分成下面几个步骤：

2、拷贝存活对象（Evacuation）
Evacuation阶段是全暂停的。它负责把一部分region里的活对象拷贝到空region里去（并行拷贝），然后回收原本的region的空间。Evacuation阶段可以自由选择任意多个region来独立收集构成收集集合（collection set，简称CSet），CSet集合中Region的选定依赖于上文中提到的 停顿预测模型 ，该阶段并不evacuate所有有活对象的region，只选择收益高的少量region来evacuate，这种暂停的开销就可以（在一定范围内）可控。

Mixed GC的清理过程示意图如下：

G1的垃圾回收过程是和应用程序并发执行的，当Mixed GC的速度赶不上应用程序申请内存的速度的时候，Mixed G1就会降级到Full GC，使用的是Serial GC。Full GC会导致长时间的STW，应该要尽量避免。
导致G1 Full GC的原因可能有两个：

PS: 本文主要参考的国内文章：
java Hotspot G1 GC的一些关键技术
Garbage First G1收集器 理解和原理分析
G1: One Garbage Collector To Rule Them All
请教G1算法的原理
深入理解 Java G1 垃圾收集器
Getting Started with the G1 Garbage Collector !

⑩ 怎样在ide中进行jvm源码的调试

按照的方式配置好Mingw32,将其安装至c:\mingw
将Insight解压至c:\insight
'make clean',删除所有的objs,重置编译环境
'make SYMBOLS=1',编译mame,别忘了符号编译选项'SYMBOLS=1'
启动C:\insight\bin\insight.exe
菜单File->Target Settings->Connection->Target,选择'Exec'
在下面的ExecArguments里面添上mame的命令行启动参数,如ddragon2
File->Open,加载刚刚编译好的mame.exe
Run->Run,启动程序,然后便可以设置断点、单步跟踪了