垃圾回收

1.垃圾回收简介

Garbage Collection（GC），Java进程在启动后会创建垃圾回收线程，来对内存中无用的对象进行回收。

2.垃圾回收的时机

2.1 System.gc()

显示的调用System.gc()：此方法的调用是建议JVM进行 FGC（Full GC），虽然只是建议而非一定，但很多情况下它会触发 FGC，从而增加FGC的频率。一般不使用此方法，让虚拟机自己去管理它的内存。

2.2 JVM垃圾回收机制决定

• 创建对象时需要分配内存空间，如果空间不足，触发GC
• 其他回收机制

java.lang.Object中有一个finalize() 方法，当JVM 确定不再有指向该对象的引用时，垃圾收集器在对象上调用该方法。finalize() 方法有点类似对象生命周期的临终方法，JVM 调用该方法，表示该对象即将“死亡”，之后就可以回收该对象了。

注意：回收还是在JVM 中处理的，所以手动调用某个对象的finalize() 方法，不会造成对象的“死亡”。

3.垃圾回收策略：如何判断对象已死？

需要垃圾回收某一个对象时，需要判断这个对象是否可以回收，怎么判断一般有两种算法：引用计数算法和可达性分析算法。

3.1 引用计数算法

引用计数算法（Reference Counting）给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。 引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法。

存在问题：很难解决对象之间相互循环引用的问题。（eg：如果两个对象构成循环引用，虽然两者都已死亡，但是GC无法标记为垃圾。）这种方法成本较大。

Python、ActionScript等语言都是基于引用计数法。

3.2 可达性分析算法（主流JVM使用）

通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为GC Roots引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。

如下图，object5和object6虽然相互引用，但是由于他们到GC Roots都不可达，因此会被判定为可回收的对象。

Java、C#等语言都是使用可达性分析算法进行垃圾回收。

4.需要垃圾回收的内存

4.1 方法区（jdk1.7）/元空间（jdk1.8）

• JDK1.7的方法区在GC中一般称为永久代（Permanent Generation）。
• JDK1.8的元空间存在于本地内存，GC也是即对元空间垃圾回收。
• 永久代或元空间的垃圾收集主要回收两部分内容：废弃常量和无用的类。此区域进行垃圾收集的“性价比”一般比较低。

4.2 堆

• Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”（Garbage CollectedHeap）。
• 从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为：

1. 新生代（Young Generation）：又可以分为Eden空间、From Survivor空间、To Survivor空间。
   ** 新生代的垃圾回收又称为Young GC（YGC）、Minor GC。
   ** 指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
2. 老年代（Old Generation、Tenured Generation）。
   ** 老年代垃圾回收又称为Major GC。
   ** 指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。
   ** Major GC的速度一般会比Minor GC慢10倍以上。
3. Full GC：在不同的语义条件下，对Full GC的定义也不同，有时候指老年代的垃圾回收，有时候指全堆（新生代+老年代）的垃圾回收，还可能指有用户线程暂停（Stop-The-World）的垃圾回收（如GC日志中）。

4.3 垃圾回收的内存划分

5.垃圾回收算法

5.1 标记-清除算法（Mark-Sweep算法）

• 最基础的收集算法，老年代收集算法。
• 如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
• 之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。
• 它的主要不足有两个：
  1.效率问题，标记和清除两个过程的效率都不高。
  2.空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

5.2 复制算法（Copying算法）

• 新生代的收集算法
• 将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
• 不足：将内存缩小为了原来的一半，效率不高。

回收前S1留白，回收后S0留白：

5.3 标记-整理算法（Mark-Compact算法）

• 老年代收集算法
• 标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。

5.4 分代收集算法

• 当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思想，只是根据对象存活周期的不同将内存划分为几块。
• 一般是把Java堆分为新生代和老年代。
• 新生代中98%的对象都是"朝生夕死"的，所以并不需要按照复制算法所要求1 : 1的比例来划分内存空间，而是将内存（新生代内存）分为一块较大的Eden（伊甸园）空间和两块较小的Survivor（幸存者）空间，每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区域）。HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说Eden : Survivor From : Survivor To = 8 : 1 : 1。所以每次新生代可用内存空间为整个新生代容量的90%，只有10%的内存会被”浪费“。
• 在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代中对象存活率高、没有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整理"算法。

6.垃圾回收的过程

• Eden空间不足，触发Minor GC：由7.1 对象优先在Eden分配可知，用户线程创建的对象优先分配在Eden区，当Eden区空间不够时，会触发Minor GC：将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。
• 垃圾回收结束后，用户线程又开始新创建对象并分配在Eden区，当Eden区空间不足时，重复上次的步骤进行Minor GC。
• 年老对象晋升到老年代：详见7.3 长期存活的对象将进入老年代。
• Survivor空间不足，存活对象通过分配担保机制进入老年代：详见7.5 空间分配担保
• 老年代空间不足，触发Major GC：由7.2 大对象直接进入老年代、7.3 长期存活的对象将进入老年代可知，当老年代空间不足时，也需要对老年代进行垃圾回收，也就是触发Major GC。
• 还有一些特殊情况会触发垃圾回收，在垃圾收集器中进一步讨论

7.内存分配与回收策略

7.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发生一次Minor GC。

7.2 大对象直接进入老年代

• 所谓的大对象是指，需要大量连续空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。

• 大对象对虚拟机的内存分配是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发GC以获取足够的连续空间来放置大对象。

7.3 长期存活的对象将进入老年代

• 既然虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代中。

• 为了做到这点，虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且把对象年龄设为1。对象在Survivor空间中每"熬过"一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将晋 升到老年代中。

7.4 动态对象年龄判定

• 为了能更好的适应不同程序的内存状况，JVM并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代。

• 如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

7.5 空间分配担保

（一）发生Minor GC时，是使用复制算法将Eden区和Survivor区存活对象复制到另一个Survivor区：

• Survivor区只占新生代10%空间，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。
• 内存的分配担保就好比我们去银行借款，如果我们信誉很好，在98%的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。
• 内存的分配担保也一样，如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

（二）在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

• 如果大于，则此次Minor GC是安全的；如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。
• 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次MinorGC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。
• 上面提到了Minor GC依然会有风险，是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（最极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。取平均值仍然是一种概率性的事件，如果某次Minor GC后存活对象陡增，远高于平均值的话，必然导致担保失败，如果出现了分配担保失败，就只能在失败后重新发起一次Full GC。虽然存在发生这种情况的概率，但大部分时候都是能够成功分配担保的，这样就避免了过于频繁执行Full GC。
• 以上过程类似银行贷款给用户，需要担保的过程，假如：
  1.贷款行为=Minor GC
  2.贷款金额=Eden区+Survivor区所有对象大小
  3.用户在贷款后进行消费的金额=Minor GC后存活的对象大小
  4.用户的资产=另一块Survivor区大小
  5.担保人=老年代
  6.担保人的银行存款=老年代最大可用连续空间大小
  7.用户的失信消费金额=用户消费金额超出用户资产后，让担保人偿还的情况下，用户的消费金额
  
  用户在贷款时，银行是不知道用户会消费多少的，如果消费超过用户的总资产，将直接从担保人银行存款扣除。而贷款过程就是：
  
  1.贷款前，银行发现担保人的银行存款足够偿还贷款，就允许贷款（Minor GC）。
  2.如果担保人的银行存款不足偿还贷款，且担保人拒绝用存款担保，会让担保人清理资产变现（Major GC）。
  3.如果担保人的银行存款不足偿还贷款，但担保人愿意用存款担保，银行基于风险考虑，还要检查用户历次的失信记录，也就是用户的失信消费金额，统计出平均的失信消费金额。
         1）如果担保人的银行存款比用户平均的失信消费金额小，说明风险太大，不接受贷款，让担保人清理资产变现（Major GC）再贷款（Minor GC）。
         2）如果担保人的银行存款比用户平均的失信消费金额大，说明风险虽然还是有，但可以接受，允许贷款。但如果贷款后，用户消费金额太大，担保人银行存款都不足偿还，需要让担保人清理资产变现后偿还（Major GC）。

8.垃圾收集的影响

8.1 用户线程的暂停：Stop-The-World（STW）

垃圾回收工作是在垃圾回收线程中执行的，在很多情况下，执行垃圾回收工作，或是执行垃圾回收其中某一步骤时，需要暂停用户线程，也就是Stop-The-World（STW）。

• 垃圾回收首先是要经过标记的。对象被标记后就会根据不同的区域采用不同的收集方法。
• 垃圾回收线程标记好对象时，用户线程在并发执行时，可能会将该对象重新加入“引用链”，垃圾回收时就会回收这个不该回收的对象，出现问题。
• 在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。这些特定的位置称为安全点（Safepoint）。
• 程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。
• GC发生时让所有线程暂停，即让所有线程“跑”到最近的安全点上再停顿下来，有两种方案可供选择：
          1）抢先式中断（PreemptiveSuspension）：不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。
          2）主动式中断（Voluntary Suspension）：是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

两个概念：

• 并行(Parallel) : 指多条垃圾收集线程并行工作，用户线程仍处于等待状态。
• 并发(Concurrent) : 指用户线程与垃圾收集线程同时执行(不一定并行，可能会交替执行)，用户程序继续运 行，而垃圾收集程序在另外一个CPU上。

8.2 评价垃圾回收器的指标：吞吐量和停顿时间（用户体验）

• 吞吐量：CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
• GC造成的用户线程单次停顿的时间越短，就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
• GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了（单次停顿时间减少了，但总的停顿时间变长了）。
• 用户体验优先：用户线程单次停顿时间短，即使总的停顿时间长一点也可以接受。
• 吞吐量优先：用户线程总的停顿时间短，即使单次停顿时间长一点也可以接受。
• 吞吐量和用户体验成反比。

9.垃圾收集器

9.0 概览

• HotSpot虚拟机提供了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使 用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。
• 重点：垃圾收集器的特性、基本原理和使用场景。
• CMS和G1这两款收集器相对比较复杂，也是重点讨论的收集器。

9.1 Serial收集器（新生代收集器,串行GC）

特性：

• 单线程
• 复制算法
• Stop The World（STW）

应用场景（了解）：

• Client模式下的默认新生代收集器。

优势（了解）：

• 单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
• 在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本上不会再大了），停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

9.2 ParNew收集器（新生代收集器,并行GC）

Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。

特性：

• 多线程
• 复制算法
• Stop The World（STW）

应用场景：

• 搭配CMS收集器，在用户体验优先的程序中使用：ParNew是运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

优势（了解）：

• 相比单CPU环境，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。

9.3 Parallel Scavenge收集器（新生代收集器,并行GC）

特性：

• 多线程
• 复制算法
• 可控制的吞吐量（Throughput）。Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。
• 自适应的调节策略：Parallel Scavenge收集器有一个参数- XX:+UseAdaptiveSizePolicy 。当这个参数打开之后，就不需要手工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。

应用场景：

• “吞吐量优先”收集器，适用吞吐量需求高的任务型程序。

9.4 Serial Old收集器（老年代收集器，串行GC）

Serial Old是Serial收集器的老年代版本

特性：

• 单线程
• “标记-整理”算法

应用场景：

• 给Client模式下的虚拟机使用。
• 在Server模式下，那么它主要还有两大用途：
  1.与Parallel Scavenge收集器搭配使用；
  2.作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

9.5 Parallel Old收集器（老年代收集器，并行GC）

Parallel Scavenge收集器的老年代版本。

特性：

• 多线程
• “标记-整理”算法

应用场景

• “吞吐量优先”：在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

9.6 CMS收集器（老年代收集器，并发GC）

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

特性：

• 并发收集、低停顿
• “标记-清除”算法
• 整个过程分为4个步骤：

1. 初始标记（CMS initial mark） 初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快， 需要“Stop The World”。
2. 并发标记（CMS concurrent mark） 并发标记阶段就是进行GC Roots Tracing的过程。
3. 重新标记（CMS remark） 重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生 变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标 记的时间短，仍然需要“Stop The World”。
4. 并发清除（CMS concurrent sweep） 并发清除阶段会清除对象。由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

• eg：1）初始标记：o1    2）并发标记：o2，o3   4）并发清除：分析o4，o5是否用户线程加入到GC Roots，清除o4，o5。
         

应用场景：

• 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

缺陷：

（一） CMS会抢占CPU资源。

• 并发阶段虽然不会导致用户线程暂停，但却需要CPU分出精力去执行多条垃圾收集线程，从而使得用户线程的执行速度下降。
• eg：比如3个用户线程，其他系统线程/进程有7个，没有垃圾回收时用户线程调度率为3/(3+7)，如果加入5个垃圾回收线程，调度率变为3/(3+7+5)，会抢占CPU资源。

（二） CMS无法处理浮动垃圾（Floating Garbage），可能会出现“Concurrent Mode Failure”而导致另一次Full GC（使用Serial Old再次回收老年代）：
       

• 第四个阶段(并发清理)的过程中，由于用户线程还在执行，因此就会继续产生对象和垃圾，这些新的垃圾没有被标记，CMS只能在下一次收集中处理它们。这也导致了CMS不能在老年代几乎完全被填满了再去进行收集，必须预留一部分空间提供给并发收集时程序运作使用。
• 在JDK1.5默认设置下，老年代使用了68%(JDK1.6是92%)的空间后CMS的垃圾收集就会被激活，其实这是一个比较保守的设置，只要应用中老年代增长不是很快，可以适当地调高参数-XX:CMSInitialingOccupancyFraction来提高触发百分比，降低回收的频率来获得更好的性能。
• 如果CMS在收集期间，内存无法满足程序的需要，就会出现“Concurrent Mode Failure”，这时JVM将启动Plan B，也就是临时调用单线程的Serial Old收集器来重新进行老年代的垃圾收集，这样的话，CMS原本降低停顿时间的目的不仅没完成，和直接使用Serial Old收集器相比，还增加了前面几个阶段的停顿时间。

（三） CMS的“标记-清除”算法，会导致大量空间碎片的产生：

• 碎片的积累会给分配大对象带来麻烦，往往会出现明明老年代还有很多空间剩余，但是却无法找到连续的空间分配对象的情况，这时候就不得不触发一次Full GC。
• 为了解决这个问题。CMS提供了一个-XX:+UseCMSCompactAtFullCollection的开关参数（默认是开启的），用于在CMS收集器进行Full GC时对内存碎片进行合并整理，整理的过程是需要暂停用户线程的，这样碎片虽然没有了，但停顿时间又变长了。
• CMS的设计初衷可是降低停顿，于是又提供了一个参数-
  XX:CMSFullGCsBeforeCompaction，用于设置执行多少次不压缩碎片的Full GC后，跟着来一次带压缩的Full GC（默认值为0，即每次都会）。

9.7 G1收集器（全区域的垃圾回收器）

• 用在heap memory很大的情况下，把heap划分为很多很多的region块，然后并行的对其进行垃圾回收。
• G1垃圾回收器回收region的时候基本不会STW，而是基于 most garbage优先回收（整体来看是基于"标记-整理"算法，从局部即两个region之间基于"复制"算法）的策略来对region进行垃圾回收的。
• 用户体验优先
• 无论如何，G1收集器采用的算法都意味着一个region有可能属于Eden，Survivor或者Tenured内存区域。（随机指定E区/S区/T区）
• G1垃圾回收器在清除实例所占用的内存空间后，还会做内存压缩。

结果如下图，图中的E表示该region属于Eden内存区域，S表示属于Survivor内存区域，T表示属于Tenured内存区域。图中空白的表示未使用的内存空间。G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。这种内存区域主要用于存储大对象-即大小超过一个region大小的50%的对象：

年轻代垃圾收集

在G1垃圾收集器中，年轻代的垃圾回收过程使用复制算法。把Eden区和Survivor区的对象复制到新的Survivor区域。

过程：

• 将E区/S区存活对象，复制到某个redion（空白region动态指定为S区）；
• 将E区/S区满足进入老年代的对象，复制到某个region（空白region动态指定为T区）。

如下图：

老年代垃收集

对于老年代上的垃圾收集，G1垃圾收集器也分为4个阶段，基本跟CMS垃圾收集器一样，但略有不同：

• 初始标记(Initial Mark)阶段 - 同CMS垃圾收集器的Initial Mark阶段一样，G1也需要暂停应用程序的执行，它会标记从根对象出发，在根对象的第一层孩子节点中标记所有可达的对象。但是G1的垃圾收集器的Initial Mark阶段是跟minor gc同时执行（和CMS不一样）的。也就是说，在G1中，你不用像在CMS那样，单独暂停应用程序的执行来运行Initial Mark阶段，而是在G1触发minor gc的时候一并将年老代上的Initial Mark给做了。
• 并发标记(Concurrent Mark)阶段 - 在这个阶段G1做的事情跟CMS一样。但G1同时还多做了一件事情，就是如果在Concurrent Mark阶段中，发现哪些Tenured region中对象的存活率很小或者基本没有对象存活，那么G1就会在这个阶段将其回收掉，而不用等到后面的clean up阶段。这也是Garbage First名字的由来。同时,在该阶段，G1会计算每个 region的对象存活率，方便后面的clean up阶段使用 。
• 最终标记(CMS中的Remark阶段) - 在这个阶段G1做的事情跟CMS一样, 但是采用的算法不同，G1采用一种叫做SATB(snapshot-at-the-begining)的算法能够在Remark阶段更快的标记可达对象。
• 筛选回收(Clean up/Copy)阶段 - 在G1中，没有CMS中对应的Sweep阶段。相反 它有一个Clean up/Copy阶段，在这个阶段中,G1会挑选出那些对象存活率低的region进行回收，这个阶段也是和minor gc一同发生的,如下图所示：

10.总结：垃圾回收的时机（重点）

10.1 Minor GC触发条件

• 创建对象在Eden区，且Eden区空间不足（参见7.1 对象优先在Eden分配）

10.2 Majar GC触发的条件

在对象需要存放在老年代，而老年代空间不足，都会触发，包括：

• 新生代年老对象晋升，详见7.3 长期存活的对象将进入老年代。
• 大对象直接进入，详见7.2 大对象直接进入老年代。
• Minor GC的分配担保机制，详见7.5 空间分配担保：在发生Minor GC之前，如果老年代最大可用的连续空间小于新生代所有对象的总空间，以下情况将会触发Major GC：

1. 不允许空间分配担保
2. 允许空间分配担保，但老年代最大可用连续空间小于历次晋升到老年代的对象的平均大小
3. 允许空间分配担保，但在执行Minor GC后老年代空间不足

• CMS无法处理浮动垃圾，可能会出现“Concurrent Mode Failure”而导致另一次Full GC，详见9.6 CMS收集器浮动垃圾缺陷

补充：变量

变量有两种关键（attribut）：类型 和 形态。

1.变量有类型：基本类型、引用类型。
2.变量形态：局部变量、形参、属性、静态属性。

变量究竟放在那个区，不是由类型决定的，是由形态决定的。

引用类型和基础数据类型区别？

可以理解为基本数据类型是一个文件，引用数据类型是那个文件的快捷方式。