二 JVM.垃圾回收算法/策略内存分配( 四 ) _回收

吞吐量有限的垃圾回收器，有一个参数 -XX:+y 可以让虚拟机自适应的来分配新生代各个区域的内存大小比例（Eden,）,此时只需要指定虚拟机的最大最小内存就可以了；
5.4Old
5.5Old
Old 是的老年代版本，JDK6 以后才有；
下图是Old +
5.6 CMS
CMSmark Sweep ；
目标：获取最短回收停顿时间，关注服务响应速度，尽可能的降低系统停顿时间；基于标记-清除算法
四个步骤：
1.初始标记 CMSmark STD 标记 GC Roots 的对象速度很快
2.并发标记 CMSmark 开始根据标记的对象开始遍历对象图，但是是和用户线程并发运行的；
3.重新标记 CMSSTD 重写并发标记期间的用户线程变动导致的那一部分对象，时间比1长，但是远比2 短；
4.并发清除 CMSsweep 和用户线程一起运行，清除标记可以回收的垃圾；
时间最长的2.和4 步骤是和用户线程并发执行的，所以总体看来，垃圾回收是和用户线程并发执行的；
优点：并发低停顿回收器；
缺点：1.资源敏感，并发占用CPU 资源，减低用户线程的吞吐量。默认启动的线程数量是 (CPU+3)/4,CPU核心数在4以上是，占用的资源少于25%；
2.无法处理浮动垃圾，重新标记阶段可以处理并发标记阶段修改的引用，但是无法处理新增的垃圾对象，并发清理更是，处理不了新增的垃圾对象；导致在本次垃圾回收阶段直到结束后，都无法处理；只能下一次处理；由于无法处理浮动垃圾，有可能出现Mode失败导致一次Full GC；
3.标记清理，会导致大量内存碎片；会触发Full GC
参数：-XX: 设置内存使用率超过多少后开始GC ，JDK5 默认68% JDK6 默认92% ；生产环境根据情况权衡设置比例；
5.7G1
First 垃圾回收器技术发展史上里程碑式的成果，面向局部回收思路和基于的内存布局形式；
面向服务器端的垃圾回收器；用来替换CMS JDK9发布：G1 取代+ Old CMS 被声明为不推荐使用
新思想：在G1 之前回收的目标，要么是老年代 Major GC，要么是新生代 Minor GC ,要么是整个Java堆 Full GC,而G1是面向整个堆内存的回收集，Set,那块内存最多垃圾数量，回收收益最大才进行回收；这就是G1 的Mixed GC 模式;
G1: 基于的内存布局，也遵循分代收集理论，但是堆内存的布局和其他收集器有很大区别：不在坚持固定大小和固定比例的分代内存区域划分；每一个根据需求,可以是 Eden, ，也可以是老年代空间；与此同时G1对不同角色的采用不同的策略去处理；还有一类特殊区域：,用于存放大对象。每个可以通过 -XX：设定内存大小，范围是1M~32M且是2的幂次；超过一半的对象就是大对象，超过一个会被存放在多个连续的 ,G1 会把这多个连续的作为老年区看待；
G1的老年代和新生代是动态的内存集合了；每次收集就是部分,避免整个Java堆垃圾回收。建立可预测的内存模型：跟踪各个区域的回收垃圾的价值大小，维护优先列表，根据用户允许的停顿时间优先处理回收价值大的,保证了有限的时间内获取最大的效率;
实现细节：
1.跨对象的引用问题：和 Set 的实现方案差不多，但是比它复杂；实现的数据结构是一个哈希表，key 是别的的其实地址，value 是一个Set,存储的是卡表的索引号。因此堆内存的10%~20% 用于维持收集器工作；
2.GC/用户线程并发问题：G1使用SATB,回收期间，会在中划出一部分空间用于分配新的对象，G1每个创建两个TAMS (指针可以动态调节这个区域的大小)，新对象的分配空间都在这两个指针上面，而这个区域也不会进行垃圾回收；但是这个区域的内存回收的速度赶不上分配的速率。就会被迫停止用户线程,进行Full GC