目录
1.2.3.可达性分析（又叫根搜索法，HotSpot就是用的这个）
3.2.3.Parallel Scavenge（并行清除） 收集器
1.GC原理及对象存活判断方法
1.1.GC原理
1.1.1.为什么要垃圾回收
JAVA语言中一个显著的特点就是引入了垃圾回收机制，使C++程序员最头疼的内存管理的问题迎刃而解，由于有个垃圾回收机制，JAVA中的对象不再有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄漏，有效的使用空闲的内存。
1.2.对象是否存活判断
1.2.1.原理
堆中每个对象实例都有一个引用计数，当一个对象被创建时，且将该对象实例分配给一个变量，该变量计数设置为1。当任何其他变量被赋值为这个对象的引用时，计数加1（a=b，则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当做垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。
1.2.2.引用计数法
优缺点：
1）引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。
2）无法检测出循环引用，如父对象有一个对子对象的引用，子对象反过来引用夫妇向，这样，他们的引用计数永远不可能为0。
1.2.3.可达性分析（又叫根搜索法，HotSpot就是用的这个）
原理：根搜索算法是从离散数学中的图论引入的，程序把所有的引用关系看着一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点。
JAVA中可作为GC ROOT的对象：
1）虚拟机栈中引用的对象（本地变量表）
2）本地方法栈中引用的对象
3）方法区中静态属性引用的对象
4）方法区中常量引用的对象
2.回收算法
2.1.标记清除
概述：算法分为“标记”和“清除”两个阶段；首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
缺点：
1）效率问题，标记和清除两个过程的效率不高；
2）空间问题，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多可能导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾回收。
如下图：
2.2.复制算法
2.2.1.为什么出现复制算法
1）为了解决效率问题，一种称为“复制”（copying）的手机算法出现了，它将可用内存按量划分为大小相等的两块，每次只使用其中的一块。
2）当这一块的内存用完了，就将还存活的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况。只要一动堆指针，按顺序分配内存即可，实现简单，运行高效。
2.2.2.特点
现在的商业虚拟机都采用这种收集算法来回收新生代。研究表明，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的Survivor空间，每次使用Eden和其中一块Suvivor。
注：Suvivor还包括：Survivor from 和Survivor to ，内存比例 8：1：1
2.2.3.工作原理
当回收时，将Eden和Survivor中还存活这的对象一次性的复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，没有办法保证每次回收都只有不多余10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。如下图：
2.2.4.缺点
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法，而是选择标记清除算法。
2.3.标记整理
2.3.1.原理
根据老年代的特点，有人提出了另外一种“标记-整理”算法，标记过程仍然与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。如下图：
2.4.分代收集算法（新生代和老年代选择不同的回收算法）
1）一般把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的手机算法。
2）在新生代中，每次垃圾收集时都发现大批对象死去，只有少量存活，那就选择复制算法，只需要服务少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率较高、没有额外空间对它进行分配担保，就必须使用“标记-清除”或者“标记-整理”算法来进行回收。
3.垃圾收集器
3.1.并发与并行
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个 CPU 上。
3.2.并行垃圾收集器
3.2.1.Serial（串行，连续的） 收集器
是什么？
1）收集算法是内存回收的方法论，垃圾回收器是内存回收的具体实现。
2）Serial是一个单线程的垃圾收集器。
特点：
1）“Stop The World”，它进行垃圾收集时，必须暂停其他所有的工作现场，知道它收集结束，在用户不可见的情况下把用户正常工作的线程全部停掉。
2）使用场景：多用于桌面引用，Client端的垃圾回收。
3）桌面应用内存小，进行垃圾回收的时间比较短，只要不频繁发生停顿就可以接受。
3.2.2.Serial Old 收集器
是什么？
是一个单线程老年代垃圾收集器，使用“标记-整理”算法，ParNew 收集器其实就是Serial收集器的多线程版本。
3.2.3.Par New（幵行） 收集器
特点：
1）ParNew 收集器除了多线程收集之外，其他与Serial 收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial 收集器外，目前只有它能与CMS 收集器配合工作。
2）使用-XX:ParallerGCTThreads 参数来限制垃圾收集的线程数。
3）多线程操作存在上线文切换的问题，所以建议将-XX:ParallerGCTThreads 设置成和CPU核数相同，如果谁知太多的话就会产生上下文切换消耗。
3.2.3.Parallel Scavenge（并行清除） 收集器
是什么？
1）Parallel Scavenge 收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
2）由于与吞吐量关系密切，Parallel Scavenge 收集器也经常称为“吞吐量优先”收集器。
3）吞吐量是什么？CPU用于运行用户代码的时间与CPU总时间的比值，99%时间执行用户线程，1%时间回收垃圾 ，这时候吞吐量就是99%。
特点：
1）Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标则是达到可控制的吞吐（Throughput）。所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99% 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
2）虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为 GC自适应调节策略。
3）-XX:MaxGCPauseMillis参数GC停顿时间，500MB ——>300MB,这个参数配置太小的话会发生频繁GC；-XX:GCTimeRatio参数，99%。
3.2.4.Parallel old（并行清除）收集器
Parallel Scavenge收集器的老年代版本，使用多线程+标记整理算法
3.2.并发收集器
3.2.1.CMS 收集器
是什么？
1）CMS（Concurrent Mark Sweep,并发标记扫描）,收集器是一种以获取最短回收停顿时间为目标的收集器。
2）目前很大一部分的Java应用集中在互联网或B/S系统的服务器端上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。
3）CMS收集器是基于“标记-清除”算法实现的。
步骤流程：
1）初始标记（CMS initial mark）：标记一下 GC Roots 能直接关联到的对象，速度很快。
2）并发标记（CMS concurrent mark）：并发标记阶段就是进行 GC RootsTracing 的过程。
3）重新标记（CMS remark) ：为了修正并发标记期间因用户程序导致标记产生变动的标记记录。
4）并发清除（CMS concurrent sweep）：效率很低，因为要扫描整个内存区域
缺点：
1）对CPU资源非常敏感。
2）无法处理浮动垃圾，程序在进行并发清除阶段用户线程会产生的新垃圾。
3）标记-清除内存不连续，无法存储连续大内存。
3.2.2.G1 收集器（重点）
G1收集器是一款面向服务器端应用的垃圾收集器。
特点：
G1中每个Region（范围）都有一个与之对应的Remembered Set（遥控设置），当进行回收内存时，在GC根节点的枚举范围中加入Remembered Set 即可保证不对全堆扫描也不会有遗漏，还会检查Reference（引用）引用的对象是否处于不同的Region。
运行步骤：
1）初始标记（Initial Marking）：标记一下GC Roots能直接关联到的对象。
2）并发标记（Concurrent Marking）：从GC ROOT开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时比较长，但可与用户程序并发执行。
3）最终标记（Final Marking）：为了修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分标记记录，虚拟机会将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set 中。
4）筛选回收（Live Data Counting and Evacuation）
优点：
1）空间整理：基于“标记-整理”算法实现为主和Region之间采用复制算法实现的垃圾收集。
2）可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但是G1除了要求最低停顿，还能建立可预测的停顿时间模型。
3）在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将这个Java划分为多个大小相等的独立区域（Region），虽然保留有新生代和老年代的概念，但是新生代和老年代不再是物理隔离了，它们都是一部分Region（不需要连续）的集合。
4）G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Regions 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region（这也就是 Garbage- Firsti 名称的来由）。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能高。
125
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
