Review （1）

 

第一阶段：

1.scala闭包

      闭包是一个函数，返回值依赖于声明在函数外部的一个或多个变量。

      闭包通常来讲可以简单的认为是可以访问一个函数里面局部变量的另外一个函数。

      如下面这段匿名的函数：

    val multiplier = (i:Int) => i * 10  

      函数体内有一个变量 i，它作为函数的一个参数。如下面的另一段代码：

    val multiplier = (i:Int) => i * factor

       在 multiplier 中有两个变量：i 和 factor。其中的一个 i 是函数的形式参数，在 multiplier 函数被调用时，i 被赋予一个新的值。然而，factor不是形式参数，而是自由变量，考虑下面代码：

     var factor = 3  
     val multiplier = (i:Int) => i * factor  

    这里我们引入一个自由变量 factor，这个变量定义在函数外面。

    这样定义的函数变量 multiplier 成为一个"闭包"，因为它引用到函数外面定义的变量，定义这个函数的过程是将这个自由变量捕获而构成一个封闭的函数。

运行时从这个函数字面量创建出来的函数值（对象）被称为闭包。该名称源于“捕获”其自由变量从而“闭合”该函数字面量的动作。

  

如果more在闭包创建以后被改变会发生什么？在Scala中，答案是闭包能够看到这个改变，参考下面的例子：

 

scala> more = 9999
more: Int = 9999

scala> addMore(10)
res1: Int = 10009

很符合直觉的是，Scala的闭包捕获的是变量本身，而不是变量引用的值。正如前面示例所展示的，为(x: Int) => x + more创建的闭包能够看到闭包外对more的修改。反过来也是成立的：闭包对捕获到的变量的修改也能在闭包外被看到。参考下面的例子：

scala> val someNumbers = List(-11, -10, -5, 0, 5, 10)
someNumbers: List[Int] = List(-11, -10, -5, 0, 5, 10)

scala> var sum = 0
sum: Int = 0

scala> someNumbers.foreach(sum += _)

scala> sum
res3: Int = -11

这个例子通过遍历的方式来对List中的数字求和。sum这个变量位于函数字面量sum += _的外围作用域，这个函数将数字加给sum。虽然运行时是这个闭包对sum进行的修改，最终的结果-11仍然能被闭包外部看到。

如果一个闭包访问了某个随着程序运行会产生多个副本的变量会如何呢？例如，如果一个闭包使用了某个函数的局部变量，而这个函数又被调用了多次，会怎么样？闭包每次访问到的是这个变量的哪一个实例呢？

答案是：闭包引用的实例是在闭包被创建时活跃的那一个。参考下面的函数，函数创建并返回more闭包的函数

def makeIncreaser(more: Int) = (x: Int) => x + more

该函数每调用一次，就会创建一个新的闭包。每个闭包都会访问那个在它创建时活跃的变量more

scala> val inc1 = makeIncreaser(1)
inc1: Int => Int = $$Lambda$1269/1504482477@1179731c

scala> val inc9999 = makeIncreaser(9999)
inc9999: Int => Int = $$Lambda$1269/1504482477@2dba6013

当调用makeIncreaser(1)时，一个捕获了more的绑定值为1的闭包就被创建并返回。同理，当调用makeIncreaser(9999)时，返回的是一个捕获了more的绑定值9999的闭包。当你将这些闭包应用到入参时，其返回结果取决于闭包创建时more的定义

scala> inc1(10)
res4: Int = 11

scala> inc9999(10)
res5: Int = 10009

这里，more是某次方法调用的入参，而方法已经返回了，不过这并没有影响。Scala编译器会重新组织和安排，让被捕获的参数在堆上继续存活。这样的安排都是由编译器自动完成的，使用者并不需要关心。

2.jdk版本
 

 jdk 1.8

JDK1.8的新特性

一、接口的默认方法
Java 8允许我们给接口添加一个非抽象的方法实现，只需要使用 default关键字即可，这个特征又叫做扩展方法。

二、Lambda 表达式
在Java 8 中你就没必要使用这种传统的匿名对象的方式了，Java 8提供了更简洁的语法，lambda表达式：
Collections.sort(names, (String a, String b) -> {

    return b.compareTo(a);

});

三、函数式接口
Lambda表达式是如何在java的类型系统中表示的呢？每一个lambda表达式都对应一个类型，通常是接口类型。而“函数式接口”是指仅仅只包含一个抽象方法的接口，每一个该类型的lambda表达式都会被匹配到这个抽象方法。因为 默认方法 不算抽象方法，所以你也可以给你的函数式接口添加默认方法。 

四、方法与构造函数引用
Java 8 允许你使用 :: 关键字来传递方法或者构造函数引用，上面的代码展示了如何引用一个静态方法，我们也可以引用一个对象的方法：
converter = something::startsWith;

String converted = converter.convert("Java");

System.out.println(converted);

五、Lambda 作用域
在lambda表达式中访问外层作用域和老版本的匿名对象中的方式很相似。你可以直接访问标记了final的外层局部变量，或者实例的字段以及静态变量。

六、访问局部变量
可以直接在lambda表达式中访问外层的局部变量：

七、访问对象字段与静态变量 
和本地变量不同的是，lambda内部对于实例的字段以及静态变量是即可读又可写。该行为和匿名对象是一致的：

八、访问接口的默认方法
JDK 1.8 API包含了很多内建的函数式接口，在老Java中常用到的比如Comparator或者Runnable接口，这些接口都增加了@FunctionalInterface注解以便能用在lambda上。
Java 8 API同样还提供了很多全新的函数式接口来让工作更加方便，有一些接口是来自Google Guava库里的，即便你对这些很熟悉了，还是有必要看看这些是如何扩展到lambda上使用的。

 3.mysql版本

  

mysql5.7  :  2015年发布，mysql5.7查询性能得以大幅提升，比 MySQL 5.6 提升 1 倍降低了建立数据库连接的时间。

mysql5.6  :  2013年2月发布，mysql5.6版本其中InnoDB可以限制大量表打开的时候内存占用过多的问题InnoDB性能加强。如大内存优化等InnoDB死锁信息可以记录到 error 日志，方便分析InnoDB提供全文索引能力。

 

mysql5.5  :  2010年12月发布mysql5.5版本默认存储引擎更改为InnoDB 多个回滚段（Multiple Rollback Segments）,之前的innodb版本最大能处理1023个并发处理操作，现在mysql5.5可以处理高达128K的并发事物 改善事务处理中的元数据锁定。例如，事物中一个语句需要锁一个表，会在事物结束时释放这个表，而不是像以前在语句结束时释放表。 增加了INFORMATION_SCHEMA[ˈski:mə]]表，新的表提供了与InnoDB压缩和事务处理锁定有关的具体信息。

4.垃圾回收器

  CMS   

 

垃圾回收器从线程运行情况分类有三种：

• 串行回收，Serial回收器，单线程回收，全程stw；
• 并行回收，名称以Parallel开头的回收器，多线程回收，全程stw；
• 并发回收，cms与G1，多线程分阶段回收，只有某阶段会stw；

 

CMS垃圾回收

CMS垃圾回收特点

• cms只会回收老年代和永久带（1.8开始为元数据区，需要设置CMSClassUnloadingEnabled），不会收集年轻带；
• cms是一种预处理垃圾回收器，它不能等到old内存用尽时回收，需要在内存用尽前，完成回收操作，否则会导致并发回收失败；所以cms垃圾回收器开始执行回收操作，有一个触发阈值，默认是老年代或永久带达到92%；

CMS垃圾回收器工作原理

CMS的GC过程有6个阶段（4个并发，2个暂停其它应用程序）：

1. 初次标记(STW initial mark)：标记老年代中所有的GC Roots引用的对象；标记老年代中被年轻代中活着的对象引用的对象(初始标记也会扫描新生代)；会导致stw。

2. 并发标记(Concurrent marking)：从初次标记收集到的‘根’对象引用开始，遍历所有能被引用的对象。

3. 并发可中断预清理(Concurrent precleaning)：改变当运行第二阶段时，由应用程序线程产生的对象引用，以更新第二阶段的结果。标记在并发标记阶段引用发生变化的对象，如果发现对象的引用发生变化，则JVM会标记堆的这个区域为Dirty Card。

那些能够从Dirty Card到达的对象也被标记（标记为存活），当标记做完后，这个Dirty Card区域就会消失。

4. 最终重新标记(STW remark)：由于并发预处理是并发的，对象引用可能发生进一步变化。因此，应用程序线程会再一次被暂停（stw）以更新这些变化，并且在进行实际的清理之前确保一个正确的对象引用视图。这一阶段十分重要，因为必须避免收集到仍被引用的对象。

 

5. 并发清理(Concurrent sweeping)：清理垃圾对象，这个阶段收集器线程和应用程序线程并发执行。

6. 并发重置(Concurrent reset)：CMS清除内部状态，为下次回收做准备。

 

问题思考

1. 并发预处理阶段意义何在？

并发预处理阶段做的工作还是标记，与4的重标记功能相似。既然相似为什么要有这一步？

前面我们讲过，CMS是以获取最短停顿时间为目的的GC。重标记需要STW（Stop The World），因此重标记的工作尽可能多的在并发阶段完成来减少STW的时间。

此阶段标记从新生代晋升的对象、新分配到老年代的对象以及在并发阶段被修改了的对象。

2. 如何确定老年代的对象是活着的？

答案很简单，通过GC ROOT TRACING可到达的对象就是活着的。

老年代进行GC时如何确保上图中Current Obj标记为活着的？答案是必须扫描新生代来确保。这也是为什么CMS虽然是老年代的gc，但仍要扫描新生代的原因。

在CMS日志中我们可以清楚地看到扫描日志：

[GC[YG occupancy: 820 K (6528 K)]

[Rescan (parallel) , 0.0024157 secs]

[weak refs processing, 0.0000143 secs]

[scrub string table, 0.0000258 secs] 

[1 CMS-remark: 479379K(515960K)] 480200K(522488K), 0.0025249 secs] 

[Times: user=0.01 sys=0.00, real=0.00 secs]

 

Rescan阶段（STW remark的一个子阶段）会扫描新生代和老年代中的对象。在日志中可以看到此阶段标识为Rescan (parallel)，说明此阶段是并行进行的。

重点来了：全量的扫描新生代和老年代会不会很慢？肯定会。CMS号称是停顿时间最短的GC，如此长的停顿时间肯定是不能接受的。如何解决呢？那就是必须要有一个能够快速识别新生代和老年代活着的对象的机制。

新生代垃圾回收完剩下的对象全是活着的，并且活着的对象很少。如果能在并发可中断预清理阶段发生一次Minor GC，那STW remark的时间就会缩短很多。

CMS 有两个参数：CMSScheduleRemarkEdenSizeThreshold、CMSScheduleRemarkEdenPenetration，默认值分别是2M、50%。

• -XX:CMSScheduleRemarkEdenSizeThreshold（默认2m）：控制abortable-preclean阶段什么时候开始执行，即当eden使用达到此值时，才会开始abortable-preclean阶段。
• -XX:CMSScheduleRemarkEdenPenetratio（默认50%）：控制abortable-preclean阶段什么时候结束执行。

所以两个参数组合起来的意思是eden空间使用超过2M时启动可中断的并发预清理，直到eden空间使用率达到50%时中断，进入remark阶段。

那可终止的预清理要执行多长时间来保证发生一次Minor GC呢？答案是没法保证。道理很简单，因为垃圾回收是JVM自动调度的，什么时候进行GC我们控制不了。

但此阶段总有一个执行时间吧。CMS提供了一个参数CMSMaxAbortablePrecleanTime ，默认为5S。只要到了5S，不管发没发生Minor GC，有没有到CMSScheduleRemardEdenPenetration都会中止此阶段，进入remark。

如果在5S内还是没有执行Minor GC怎么办？CMS提供CMSScavengeBeforeRemark参数，使remark前强制进行一次Minor GC。

这样做利弊都有：

• 好的一面是减少了remark阶段的停顿时间；
• 坏的一面是Minor GC后紧跟着一个remark pause。如此一来，停顿时间也比较久。

CMS日志如下：

7688.150: [CMS-concurrent-preclean-start]

7688.186: [CMS-concurrent-preclean: 0.034/0.035 secs]

7688.186: [CMS-concurrent-abortable-preclean-start]

7688.465: [GC 7688.465: [ParNew: 1040940K->1464K(1044544K), 0.0165840 secs] 1343593K->304365K(2093120K), 

0.0167509 secs]7690.093: [CMS-concurrent-abortable-preclean: 1.012/1.907 secs]  7690.095: [GC[YG occupancy: 522484 K (1044544 K)]

7690.095: [Rescan (parallel) , 0.3665541 secs]7690.462: [weak refs processing, 0.0003850 secs] [1 CMS-remark: 302901K(1048576K)] 825385K(2093120K), 0.3670690 secs]

7688.186启动了可终止的预清理，在随后的三秒内启动了Minor GC，然后进入了Remark阶段。

实际上为了减少remark阶段的STW时间，预清理阶段会尽可能多做一些事情来减少remark停顿时间。remark的rescan阶段是多线程的，为了便于多线程扫描新生代。

3. 进行Minor GC时如果有老年代引用新生代，怎么识别？

有研究表明，在所有的引用中，老年代引用新生代这种场景不足1%。

CMS将老年代的空间分成大小为512bytes的块，card table中的每个元素对应着一个块。

并发标记时，如果某个对象的引用发生了变化，就标记该对象所在的块为 dirty card。并发预清理阶段就会重新扫描该块，将该对象引用的对象标识为可达。

当有老年代引用新生代，对应的card table被标识为相应的值（card table中是一个byte，有八位，约定好每一位的含义就可区分哪个是引用新生代，哪个是并发标记阶段修改过的。所以，Minor GC通过扫描card table就可以很快的识别老年代引用新生代。

G1

G1垃圾回收器是在Java7 update 4之后引入的一个新的垃圾回收器。G1是一个分代的，增量的，并行与并发的标记-复制垃圾回收器。它的设计目标是为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。G1回收器和CMS比起来，有以下不同：

1. G1垃圾回收器是compacting的，因此其回收得到的空间是连续的。这避免了CMS回收器因为不连续空间所造成的问题。如需要更大的堆空间，更多的floating garbage。连续空间意味着G1垃圾回收器可以不必采用空闲链表的内存分配方式，而可以直接采用bump-the-pointer的方式；
2. G1回收器的内存与CMS回收器要求的内存模型有极大的不同。G1将内存划分一个个固定大小的region，每个region可以是年轻代、老年代的一个。内存的回收是以region作为基本单位的；

G1还有一个及其重要的特性：软实时（soft real-time）。所谓的实时垃圾回收，是指在要求的时间内完成垃圾回收。“软实时”则是指，用户可以指定垃圾回收时间的限时，G1会努力在这个时限内完成垃圾回收，但是G1并不担保每次都能在这个时限内完成垃圾回收。通过设定一个合理的目标，可以让达到90%以上的垃圾回收时间都在这个时限内。

Heap Region

本质上来说，G1垃圾回收器依然是一个分代垃圾回收器。但是它与一般的回收器所不同的是，它引入了额外的概念，Region。G1垃圾回收器把堆划分成一个个大小相同的Region。在HotSpot的实现中，整个堆被划分成2048左右个Region。每个Region的大小在1-32MB之间，具体多大取决于堆的大小。

G1垃圾回收器的分代也是建立在这些Region的基础上的。对于Region来说，它会有一个分代的类型，并且是唯一一个。即，每一个Region，它要么是young的，要么是old的。还有一类十分特殊的Humongous。所谓的Humongous，就是一个对象的大小超过了某一个阈值——HotSpot中是Region的1/2，那么它会被标记为Humongous。如果我们审视HotSpot的其余的垃圾回收器，可以发现这种对象以前被称为大对象，会被直接分配老年代。而在G1回收器中，则是做了特殊的处理。
G1并不要求相同类型的region要相邻。换言之，就是G1回收器不要求它们连续。当然在逻辑上，分代依旧是连续的。因此，一种典型的分配可能是：

其中E代表的是Eden，S代表的是Survivor，H代表的是Humongous，剩余的深蓝色代表的是Old（或者Tenured），灰色的代表的是空闲的region。
每一个分配的Region，都可以分成两个部分，已分配的和未被分配的。它们之间的界限被称为top。总体上来说，把一个对象分配到Region内，只需要简单增加top的值。这个做法实际上就是bump-the-pointer。过程如下：

Region可以说是G1回收器一次回收的最小单元。即每一次回收都是回收N个Region。这个N是多少，主要受到G1回收的效率和用户设置的软实时目标有关。每一次的回收，G1会选择可能回收最多垃圾的Region进行回收。与此同时，G1回收器会维护一个空间Region的链表。每次回收之后的Region都会被加入到这个链表中。
每一次都只有一个Region处于被分配的状态中，被称为current region。在多线程的情况下，这会带来并发的问题。G1回收器采用和CMS一样的TLABs的手段。即为每一个线程分配一个Buffer，线程分配内存就在这个Buffer内分配。但是当线程耗尽了自己的Buffer之后，需要申请新的Buffer。这个时候依然会带来并发的问题。G1回收器采用的是CAS（Compate And Swap）操作。

显然的，采用TLABs的技术，就会带来碎片。举例来说，当一个线程在自己的Buffer里面分配的时候，虽然Buffer里面还有剩余的空间，但是却因为分配的对象过大以至于这些空闲空间无法容纳，此时线程只能去申请新的Buffer，而原来的Buffer中的空闲空间就被浪费了。Buffer的大小和线程数量都会影响这些碎片的多寡。

Remember Set和Card Table

RS(Remember Set)是一种抽象概念，用于记录从非收集部分指向收集部分的指针的集合。
在传统的分代垃圾回收算法里面，RS(Remember Set)被用来记录分代之间的指针。在G1回收器里面，RS被用来记录从其他Region指向一个Region的指针情况。因此，一个Region就会有一个RS。这种记录可以带来一个极大的好处：在回收一个Region的时候不需要执行全堆扫描，只需要检查它的RS就可以找到外部引用，而这些引用就是initial mark的根之一。

那么，如果一个线程修改了Region内部的引用，就必须要去通知RS，更改其中的记录。为了达到这种目的，G1回收器引入了一种新的结构，CT(Card Table)——卡表。每一个Region，又被分成了固定大小的若干张卡(Card)。每一张卡，都用一个Byte来记录是否修改过。卡表即这些byte的集合。实际上，如果把RS理解成一个概念模型，那么CT就可以说是RS的一种实现方式。

从第一感觉，或者出于直觉的考虑，使用一个bit来记录一张卡是否被修改过，就已经足够了。而使用一个byte会造成更多的空间开销。但是实际上，使用一个byte来记录一张卡是否被修改过，会比使用一个bit来记录效率更高。

在RS的修改上也会遇到并发的问题。因为一个Region可能有多个线程在并发修改，因此它们也会并发修改RS。为了避免这样一种冲突，G1垃圾回收器进一步把RS划分成了多个哈希表。每一个线程都在各自的哈希表里面修改。最终，从逻辑上来说，RS就是这些哈希表的集合。哈希表是实现RS的一种通常的方式之一。它有一个极大的好处就是能够去除重复。这意味着，RS的大小将和修改的指针数量相当。而在不去重的情况下，RS的数量和写操作的数量相当。

Remember Set的写屏障

写屏障是指，在改变特定内存的值（实际上也就是写入内存）的时候额外执行的一些动作。在大多数的垃圾回收算法中，都利用到了写屏障。写屏障通常用于在运行时探测并记录回收相关指针(interesting pointer)，在回收器只回收堆中部分区域的时候，任何来自该区域外的指针都需要被写屏障捕获，这些指针将会在垃圾回收的时候作为标记开始的根。JAVA使用的其余的分代的垃圾回收器，都有写屏障。举例来说，每一次将一个老年代对象的引用修改为指向年轻代对象，都会被写屏障捕获，并且记录下来。因此在年轻代回收的时候，就可以避免扫描整个老年代来查找根。

G1垃圾回收器的写屏障和RS是相辅相成的，也就是记录Region内部的指针。这种记录发生在写操作之后。对于一个写屏障来说，过滤掉不必要的写操作是十分有必要的。这种过滤既能加快赋值器的速度，也能减轻回收器的负担。G1垃圾回收器采用的双重过滤

1. 过滤掉同一个Region内部引用；
2. 过滤掉空引用；

过滤掉这两个部分之后，可以使RS的大小大大减小。

G1的垃圾回收器的写屏障使用一种两级的log buffer结构：

1. global set of filled buffer：所有线程共享的一个全局的，存放填满了的log buffer的集合；
2. thread log buffer：每个线程自己的log buffer。所有的线程都会把写屏障的记录先放进去自己的log buffer中，装满了之后，就会把log buffer放到 global set of filled buffer中，而后再申请一个log buffer；

Collect Set

Collect Set(CSet)是指，在Evacuation阶段，由G1垃圾回收器选择的待回收的Region集合。G1垃圾回收器的软实时的特性就是通过CSet的选择来实现的。对应于算法的两种模式fully-young generational mode和partially-young mode，CSet的选择可以分成两种：

1. 在fully-young generational mode下：顾名思义，该模式下CSet将只包含young的Region。G1将调整young的Region的数量来匹配软实时的目标；
2. 在partially-young mode下：该模式会选择所有的young region，并且选择一部分的old region。old region的选择将依据在Marking cycle phase中对存活对象的计数。G1选择存活对象最少的Region进行回收。

SATB(snapshot-at-the-beginning)

SATB(snapshot-at-the-beginning)，是最开始用于实时垃圾回收器的一种技术。G1垃圾回收器使用该技术在标记阶段记录一个存活对象的快照("logically takes a snapshot of the set of live objects in the heap at the start of marking cycle")。然而在并发标记阶段，应用可能修改了原本的引用，比如删除了一个原本的引用。这就会导致并发标记结束之后的存活对象的快照和SATB不一致。G1是通过在并发标记阶段引入一个写屏障来解决这个问题的：每当存在引用更新的情况，G1会将修改之前的值写入一个log buffer（这个记录会过滤掉原本是空引用的情况），在最终标记(final marking phase)阶段扫描SATB，修正SATB的误差。

SATB的log buffer如RS的写屏障使用的log buffer一样，都是两级结构，作用机制也是一样的。

Marking bitmaps和TAMS

Marking bitmap是一种数据结构，其中的每一个bit代表的是一个可用于分配给对象的起始地址。举例来说：

TAMS(top at mark start)变量，是一对用于区分在标记阶段新分配对象的变量，分别被称为previous TAMS和next TAMS。在previous TAMS和next TAMS之间的对象则是本次标记阶段时候新分配的对象。如图：

白色region代表的是空闲空间，绿色region代表是存活对象，橙色region代表的在此次标记阶段新分配的对象。注意的是，在橙色区域的对象，并不能确保它们都事实上是存活的。

 

算法详解

 

整个算法可以分成两大部分：

1. Marking cycle phase：标记阶段，该阶段是不断循环进行的；
2. Evacuation phase：该阶段是负责把一部分region的活对象拷贝到空Region里面去，然后回收原本的Region空间，该阶段是STW(stop-the-world)的；

而算法也可以分成两种模式：

1. fully-young generational mode：有时候也会被称为young GC，该模式只会回收young region，算法是通过调整young region的数量来达到软实时目标的；
2. partially-young mode：也被称为Mixed GC，该阶段会回收young region和old region，算法通过调整old region的数量来达到软实时目标；

有趣的地方是不论处在何种模式之下，yong region都在被回收的范围内。而old region只能期望于Mixed GC。但是，如同在CMS垃圾回收器中遇到的困境一样，Mixed GC可能来不及回收old region。也就说，在需要分配老年代的对象的时候，并没有足够的空间。这个时候就只能触发一次full GC。

算法会自动在young GC和mixed GC之间切换，并且定期触发Marking cycle phase。HotSpot的G1实现允许指定一个参数InitiatingHeapOccupancyPercent，在达到该参数的情况下，就会执行marking cycle phase。

算法并不使用在对象头增加字段来标记该对象，而是采用bitmap的方式来记录一个对象被标记的情况。这种记录方法的好处就是在使用这些标记信息的时候，仅仅需要扫描bitmap而已。G1统计一个region的存活的对象，就是依赖于bitmap的标记。

Marking Cycle Phase

算法的Marking cycle phase大概可以分成五个阶段：

1. Initial marking phase：G1收集器扫描所有的根。该过程是和young GC的暂停过程一起的；
2. Root region scanning phase：扫描Survivor Regions中指向老年代的被initial mark phase标记的引用及引用的对象，这一个过程是并发进行的。但是该过程要在下一个young GC开始之前结束；
3. Concurrent marking phase：并发标记阶段，标记整个堆的存活对象。该过程可以被young GC所打断。并发阶段产生的新的引用（或者引用的更新）会被SATB的write barrier记录下来；
4. Remark phase：也叫final marking phase。该阶段只需要扫描SATB(Snapshot At The Beginning)的buffer，处理在并发阶段产生的新的存活对象的引用。作为对比，CMS的remark需要扫描整个mod union table的标记为dirty的entry以及全部根；
5. Cleanup phase：清理阶段。该阶段会计算每一个region里面存活的对象，并把完全没有存活对象的Region直接放到空闲列表中。在该阶段还会重置Remember Set。该阶段在计算Region中存活对象的时候，是STW(Stop-the-world)的，而在重置Remember Set的时候，却是可以并行的；

 

Initial marking phase

该阶段扫描所有的根，与CMS类似。所不同的是，该阶段是和young GC一起的。这里的young GC实际上是指的就是fully-young generational mode。

Root region scanning phase

该过程主要是扫描Survivor region中指向老年代的，在initial mark phase标记的引用及其引用的对象。这是一个很奇怪的步骤，因为在前面不论是Parallel Collector还是CMS，都没有这么一个步骤。

要理解这一点，要注意的是，算法的两种模式，不论是young GC还是mixed GC，都需要回收young region。因为实际上RS是不记录从young region出发的指针，例如，这部分指针包括young region - young region，也包括young-region - old region指针。那么就可能出现一种情况，一个老年代的存活对象，只被年轻代的对象引用。在一次young GC中，这些存活的年轻代的对象会被复制到Survivor Region，因此需要扫描这些Survivor region来查找这些指向老年代的对象的引用，作为并发标记阶段扫描老年代的根的一部分。

在理解了这一点的基础上，那么对于阶段必须在下一次young GC启动前完成的要求，也就理解了。因为如果第二次的young GC启动了，那么这个过程中，survivor region就可能发生变化。这个时候执行root region phase就会产生错误的结果。

Concurrent marking phase

在标记阶段，会使用到一个marking stack的东西。G1不断从marking stack中取出引用，递归扫描整个堆里的对象图，并且在bitmap上进行标记。这个递归过程采用的是深度遍历，会不断把对象的域入栈。

在并发标记阶段，因为应用还在运行，所以可能会有引用变更，包括现有引用指向别的对象，或者删除了一个引用，或者创建了一个新的对象等。G1采用的是使用SATB的并发标记算法。

在G1中，该算法的关键在于，如果在并发标记的时候，出现了引用修改（不包含新分配内存给对象），那么写屏障会把这些引用的原始值捕获下来，记录在log buffer中。而后再处理。后续的所有的标记，都是从原来的值出发，而不是从新的值出发的。

SATB是一个逻辑上存在概念，在实际中并没有任何真的实际的数据结构与之对应。叫这个名字，是因为，一旦进入了concurrent marking阶段，那么该在该阶段的运行过程中，即便应用修改了引用，但是因为SATB的写屏障记录下来了原始的值，在遍历整个堆查找存活对象的时候，使用的依然是原来的值。这就是在逻辑上保持了一个snapshot at the beginning of concurrent marking phase。

在处理新创建的对象，G1采用了不同的方式。G1用了两个TAMS变量了判断新创建的对象。一个叫做previous TAMS，一个叫做next TAMS。位于两者之间的对象就是新分配的对象。

• A是第一次marking cycle的initial marking阶段。next bitmap尚未标记任何存活对象，而此时的previous TAMS被初始化为region内存地址起始值，next TAMS被初始化为top。top实际上就是一个region未分配区域和已分配区域的分界点；
• B是经过concurrent marking阶段之后，进入了remark阶段。此时存活对象的扫描已经完成了，因此next bitmap构造好了，刚好代表的是当下状态中region中的内存使用情况。注意的是，此时top已经不再与next TAMS重合了，top和next TAMS之间的就是在前面标记阶段之时，新分配的对象；
• C代表的是clean up阶段。C和B比起来，next bitmap变成了previous bitmap，而在bitmap中标记为垃圾（也就是白色区域的）的对应的region的区域也被染成了浅灰色。这并不是指垃圾对象已经被清扫了，仅仅是标记出来了。同时next TAMS和previous TAMS也交换了角色；
• D代表的是下一个marking cycle的initial marking阶段，该阶段和A类似，next TAMS重新被初始化为top的值；
• EF就是BC的重复

Remark phase

该阶段是一个STW的阶段。引入该阶段的目的，是为了能够达到结束标记的目标。要结束标记的过程，要满足三个条件：

1. concurrent marking已经追踪了所有的存活对象；
2. marking stack是空的；
3. 所有的log都被处理了；

前两个条件是很容易达到的，但是最后一个是很困难的。如果不引入一个STW的remark过程，那么应用会不断的更新引用，也就是说，会不断的产生log，因而永远也无法达成完成标记的条件。

Clean up

该阶段主要完成：

1. 统计存活对象，这是利用RS和bitmap来完成的，统计的结果将会用来排序region，以用于下一次的CSet的选择；
2. 重置RSet；
3. 把空闲region放到空闲region列表中；

该阶段比较容易引起误解地方在于，Clean up并不会清理垃圾对象，也不会执行存活对象的拷贝。也就是说，在极端情况下，该阶段结束之后，空闲Region列表将毫无变化，JVM的内存使用情况也毫无变化。

Evacuation

Evacuation阶段STW的，大概可以分成两个步骤：第一个步骤是从Region中选出若干个Region进行回收，这些被选中的Region称为Collect Set（简称CSet）；而第二个步骤则是把这些Region中存活的对象复制到空闲的Region中去，同时把这些已经被回收的Region放到空闲Region列表中。
这两个步骤又可以被分解成三个任务：

1. 根据RS的日志更新RS：只有在处理完了RS的日志之后，RS才能够保证是准确的，完整的，这也是Evacuation是STW的重要原因；
2. 扫描RS和其余的根来确定存活对象：该阶段实际上最主要依赖于RS；
3. 拷贝存活对象：该阶段只要从2中确定的根触发，沿着引用链一直追溯下去，将存活对象复制到新的region就可以。这个过程中，可能有一部分的年轻代对象会被提升到老年代；

Evacuation的时机

Evacuation的触发时机在不同的模式下会有一些不同。在不同的模式下都相同的是，只要堆的使用率达到了某个阈值，就必然会触发Evacuation。这是为了确保在Evacuation的时候有足够的空闲Region来容纳存活对象。

在young GC的情况下，G1会选择N个region作为CSet，该CSet首先需要满足软实时的要求，而一旦已经有N个region已经被分配了，那么就会执行一次Evacuation。

G1会尽可能的执行mixed GC。唯一的限制就是mix GC也需要满足软实时的要求。

G1触发Evacuation的原则大概是：

1. 如果被分配的young region数量满足young GC的要求，那么就会触发young GC；
2. 如果被分配的young region数量不满足young GC，就会进一步考察加上old region的数量，能否满足old GC的要求

为了理解这一点，可以举例来说，假如回收一个old region的时间是回收一个young region的两倍，也就是young region花费时间T，old region花费2T，在满足软实时目标的情况下，GC只能回收8T的region，那么：

1. 假如应用现在只分配k（k<8）块young region，没有分配任何old region。这个时候又分配了一个old region，那么这个时候会立刻触发一次mixed GC，此次GC会选择k块young region和一块old region；
2. 因此，在这种假设下，只要有可以回收的old region的时候，总是会先回收old region；
3. 在没有任何old region的情况下，才有可能触发young region。