目录
堆内存结构
jvm将我们的堆区间分为新生代和老年代，针对不同年龄代的特性，采用不同的回收算法，不用的垃圾收集器，不同的回收策略。年轻代对象大多都是朝生暮死的，老年代对象大多是常用的热点对象，不会怎么回收的。
新生代
在新生代，每次垃圾收集器都发现有大批对象死去，只有少量存活，采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；
老年代
而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须“标记－清除-压缩”算法进行回收。如果Old区满了，将会触发Full GC回收整个堆内存。
各个区间默认比例是：
eden:s0:s1:8:1:1
young:old: 1:2
在各个不同的区间采用不同的垃圾回收算法，那么什么是垃圾回收机制？
不定时去堆内存中清理不可达对象。垃圾收集器在一个Java程序中的执行是自动的，不能强制执行。System.gc 方法来"建议"执行垃圾收集器，但其是否可以执行。这也是垃圾收集器的最主要的缺点。
垃圾回收算法
引用计数法
引用计数法就是如果一个对象没有被任何引用指向，则可视之为垃圾。这种方法的缺点就是不能检测到环的存在。
根搜索算法
通过一系列称为“GC Roots”的对象作为起始点，从这些节点向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链（即GC Roots到对象不可达）时，则证明此对象是不可用的。GC Roots对对象的引用如下图：
标记清除算法
该算法有两个阶段。
1. 标记阶段：找到所有可访问的对象，做个标记
2. 清除阶段：遍历堆，把未被标记的对象回收
标记复制算法
如果jvm使用了coping算法，一开始就会将可用内存分为两块，from域和to域， 每次只是使用from域，to域则空闲着。当from域内存不够了，开始执行GC操作，这个时候，会把from域存活的对象拷贝到to域,然后直接把from域进行内存清理。
标记整理算法
标记清除算法和标记压缩算法非常相同，但是标记压缩算法在标记清除算法之上解决内存碎片化
分代回收算法
根据对象的存活周期的不同将内存划分成几块，新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。
新生代对象朝生夕死,对象数量多，只要重点扫描这个区域，那么就可以大大提高垃圾收集的效率。
另外老年代对象存储久，无需经常扫描老年代，避免扫描导致的开销。
垃圾收集器
Serial收集器
则是发展最悠久的垃圾收集器。在jdk1.3的时候只能用我们serial垃圾回收器。
他是一个单线程的垃圾回收器。用在我们的新生代复制算法，适合于堆内存空间比较小个人小项目。
在桌面应用比较多（单线程服务器上，堆内存比较小的应用使用效率比较高）。
当我们gc执行时候会暂停我们的所有的线程这个步骤简称STW （Stop The World）。
Parnew收集器
在清理时候采用我们的parnew 采用我们的 多线收集也是在新生代复制算法
Parallel Scavenge收集器
他也是采用我们的复制算法
多线程收集
达到到可以控制的吞吐量，用户代码时间/（用户代码时间+gc暂停时间）
-XX:MaxGCPauseMillis 垃圾回收器最大停顿时间
-XX：GCTimeRatio 吞吐量大小 (0,100) 默认最大99
CMS收集器（concurrent mark sweep）
工作过程：
初始标记：使用可达性分析法标记 标记gcroot直接关联上的对象。（STW）
并发标记：由前阶段标记过的对象出发，所有可到达的对象都在本阶段中标记。
并发预清理 ：并发预清理阶段仍然是并发的。在这个阶段，虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从新生代晋升到老年代， 或者有一些对象被分配到老年代)。通过重新扫描，减少下一个阶段"重新标记"的工作，因为下一个阶段会Stop The World。
重新标记：标记那些因为用户程序继续运作产生的新生带跨带引用的垃圾对象(STW)
并发清理：清理所有的垃圾对象。
并发重置：将原本的标记对象重置
CMS收集器在发生FullGc时会采用备选方案--串行老年代gc收集器（标记整理算法）
如何确保新生代对象被老年代对象引用的时候不被gc？
老年代存活对象多时，每次minor gc查询老年代所有对象影响gc效率（因为gc stop-the-world），所以在老年代有一个write barrier（写屏障）来管理的card table（卡表,采用三色算法标记不同的引用情况），card table存放了所有老年代对象对新生代对象的引用。
所以每次minor gc通过查询card table来避免查询整个老年代，以此来提高gc性能。
总结
优点：
- 并发收集器 GC线程可以与用户线程同时并发执行
- 降低用户线程等待时间
缺点：
- 会发生内存碎片化（标记清除）
- 用户线程空间不足，无法存放大对象的情况下，有可能会触发FULLGC
- 消耗CPU资源（与用户线程同时执行）
- CMS收集器无法处理浮动垃圾，在并发标记阶段如果产生了新的垃圾对象
G1收集器
g1收集器默认分2048个块；
Region之H区域
Humongous区是JDK8新增的一个针对于大对象的特殊区域，其隶属于老年代，当分配的对象大小大于Region大小的50%时，这个对象会被认为是大对象，将会分配到Humongous区，对于一个Humongous区也无法容纳的对象，G1会寻找一个连续的HRegion来存放该对象，如果找不到会启动fullgc回收来达到目的,并且因为Humongous区是属于老年代的，大对象过多会大大增加fullgc的频率，因此在程序中一定要避免出现大对象；
G1收集器Rset问题（记忆集）
在一个region中可能会引入到其他的region，为了避免不需要的全局扫描，在每个region中都对应一个Remembered Set（记忆集），使用CarTable
记录每个region区相互引用的关系。
G1收集器优缺点
- 并行与并发
并行：G1收集器在回收时，可以实现多个GC线程同时执行 利用CPU多核利用率，但是会让用户线程暂停 触发stw机制。
并发：多个GC与用户线程用时执行，用户线程不会阻塞。
- 分代收集原理
G1收集器，也会分为新生代、老年代, 新生代eden、S0或者S1区域，但是不要求整个eden、S0或者S1区域具有连续性。
与之前的收集器不同，它可以收集新生代也可以收集老年代。
- 空间整合
之前我们所学习的CMS收集器采用标记清除算法，容易产生碎片化的问题且空间不连续性，而G1收集器划分成n多个不同的采用标记
压缩算法，没有产生碎片化的问题。分配大对象的时候，避免FullGC的问题，所以如果堆内存空间比较大，使用G1收集器更加有优势。
- 可预测的停顿时间模型 能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
由于G1收集器采用分区模型，所以G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。G1跟踪各个Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
回收过程原理
young gc（新生代） -> young gc + concurrent mark（新生代+并发标） -> Mixed GC（混合回收）顺序，进行垃圾回收
缺点：
小内存的情况下使用cms收集器，大内存的情况下可以使用G1收集器。G1收集器6GB以上
三色标记算法
在使用再次标记（修正的时候）的时候，G1中采用了比CMS更快的初始快照算法：snapshot-at-the-beginning （SATB）。
白：未被标记的对象
灰：对象被标记了，但是它的field还没有被标记。
黑：对象被标记了，且它的所有field也被标记完了
注意区别：
1.CMS中使用，漏标采用增量更新
2.G1中使用，漏标采用SATB
CMS收集器中处理漏标问题（增量更新）：
满足了第一个条件（灰色对象不在关联白色对象的时候），当黑色对象关联该白色对象的时候会记录该黑色对象，
在重新标记的时候，以该黑色对象变为灰色，从新开始修正标记，但是这种方案能够确保垃圾都被清理，缺点就是效率非常低，
因为会扫描到整个黑色对象所有引用。
G1收集器中处理漏标问题(原始快照SATB)：
满足了第一个条件（灰色对象不在关联白色对象的时候），记录该白色对象变为灰色，在重新标记的时候扫描该白色对象整个引用链，但是如果黑色对象没有引用该白色对象的时候，这时候就会产生浮动垃圾，只能在下一次清理。
相对于来说原始快照方式比增量更新方式容易产生浮动垃圾，但是效率比增量更新要高。
名词解释：
吞吐量: 运行用户代码占总时间的比例
暂停时间: 应用线程花在GC stop-the-world 的时间 暂时时间越小越好
4889
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
