本文主要内容：
-》堆的回顾
-》各种垃圾收集器的介绍
1. 串行收集器
2. 并行收集器
3. CMS收集器
4. G1收集器
堆的回顾：
新生代中的98%对象都是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块比较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是说，每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的空间会被浪费。
当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖于老年代进行分配担保，所以大对象直接进入老年代。
堆的结构如下图所示：
垃圾收集器：
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
虽然我们在对各种收集器进行比较，但并非为了挑出一个最好的收集器。因为直到现在位置还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。
上图为各种垃圾收集器，我们一一介绍
名词概念解释：
垃圾收集器里，
并行：多个GC线程同时运行
并发：GC线程和用户线程同时运行
一、串行收集器：Serial收集器 + SerialOld收集器
新生代、老年代都会使用串行回收
新生代复制算法
老年代标记-整理
这个收集器是一个单线程的收集器，但它的单线程的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。收集器的运行过程如下图所
二、并行收集器：
1、ParNew收集器（新生代）：
新生代并行
老年代串行
2、Parallel Scanvenge收集器（新生代）：
3、Parallel Old收集器（老年代）：
各种参数设置：
最大停顿时间，单位毫秒
GC尽力保证回收时间不超过设定值
0-100的取值范围
垃圾收集时间占总时间的比
默认99，即最大允许1%时间做GC
注：这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优。我们一方买希望停顿时间少，另外一方面希望吞吐量高，其实这是矛盾的。因为：在GC的时候，垃圾回收的工作总量是不变的，如果将停顿时间减少，那频率就会提高；既然频率提高了，说明就会频繁的进行GC，那吞吐量就会减少，性能就会降低。
吞吐量：CPU用于用户代码的时间/CPU总消耗时间的比值，即=运行用户代码的时间/(运行用户代码时间+垃圾收集时间)。比如，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
三、CMS收集器：
CMS收集器（Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。更关注用户体验的，推荐用这种收集器。
注：这里的并发指的是与用户线程一起执行。
2、CMS收集器运行过程：（着重实现了标记的过程）
（1）初始标记
根可以直接关联到的对象
速度快
（2）并发标记（和用户线程一起）
主要标记过程，标记全部对象
（3）重新标记
由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正
（4）并发清除（和用户线程一起）
基于标记结果，直接清理对象
整个过程如下图所示：
其中，初始标记和重新标记时，需要stop the world。
整个过程中耗时最长的是并发标记和并发清除，这两个过程都可以和用户线程一起工作。
3、CMS收集器特点：
（1）尽可能降低停顿
（2）会影响系统整体吞吐量和性能
比如，在用户线程运行过程中，分一半CPU去做GC，系统性能在GC阶段，反应速度就下降一半
（3）清理不彻底
因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理
（4）因为和用户线程一起运行，不能在空间快满时再清理
-XX:CMSInitiatingOccupancyFraction设置触发GC的阈值
如果不幸内存预留空间不够，就会引起concurrent mode failure
我们来看一下concurrent mode failure的日志：
碰到上图中的情况，我们需要使用串行收集器作为后备。
4、既然标记清除算法会造成内存空间的碎片化，CMS收集器为什么使用标记清除算法而不是使用标记整理算法：
答案：
CMS收集器更加关注停顿，它在做GC的时候是和用户线程一起工作的（并发执行），如果使用标记整理算法的话，那么在清理的时候就会去移动可用对象的内存空间，那么应用程序的线程就很有可能找不到应用对象在哪里。
为了解决碎片的问题，CMS收集器会有一些整理上的参数，接下来就来讲这个。
5、整理时的各种参数：
Full GC后，进行一次整理。整理过程是独占的，会引起停顿时间变长
设置进行几次Full GC后，进行一次碎片整理
设定CMS的线程数量
四 G1收集器
用来替代CMS
这种GC 不再很明显的把堆内存划分为 新生代和老年代两大块内存了，而是把内存分成很多小块
此处的1块内存，是可以放很多对象的内存，
GC后，剩余内存是比较干净的，（多于出来的O,是新生代晋升过来的）
并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
内存布局：在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
新生代GC
回收Eden区和survivor区，回收后，所有eden区被清空，存在一个survivor区保存了部分数据。老年代区域会增多，因为部分新生代的对象会晋升到老年代。
初始标记：短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，产生一个全局停顿，都伴随有一次新生代的GC。
根区域扫描：扫描survivor区可以直接到达的老年代区域。
并发标记阶段：扫描和查找整个堆的存活对象，并标记。
重新标记：会产生全局停顿，对并发标记阶段的结果进行修正。
独占清理：会产生全局停顿，对GC回收比例进行排序，供混合收集阶段使用
并发清理：识别并清理完全空闲的区域，并发进行
混合收集
对含有垃圾比例较高的Region进行回收。
G1当出现内存不足的的情况，也可能进行的FullGC回收(暂停所有工作线程，全局回收 包括新生代，老年代，永久代)
G1中重要的参数：
-XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。
-XX:ParallerGCThreads：设置GC的工作线程数量
五 GC参数的整理：
-XX:+UseSerialGC：在新生代和老年代使用串行收集器
-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例
-XX:NewRatio:新生代和老年代的比
-XX:+UseParNewGC：在新生代使用并行收集器
-XX:+UseParallelGC ：新生代使用并行回收收集器
-XX:+UseParallelOldGC：老年代使用并行回收收集器
-XX:ParallelGCThreads：设置用于垃圾回收的线程数
-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器
-XX:ParallelCMSThreads：设定CMS的线程数量
-XX:CMSInitiatingOccupancyFraction：设置CMS收集器在老年代空间被使用多少后触发
-XX:+UseCMSCompactAtFullCollection：设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
-XX:CMSFullGCsBeforeCompaction：设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled：允许对类元数据进行回收
-XX:CMSInitiatingPermOccupancyFraction：当永久区占用率达到这一百分比时，启动CMS回收
-XX:UseCMSInitiatingOccupancyOnly：表示只在到达阀值的时候，才进行CMS回收
六 内存分配与回收策略
1 对象优先在Eden分配，如果说Eden内存空间不足，就会发生Minor GC
2 大对象直接进入老年代，大对象：需要大量连续内存空间的Java对象，比如很长的字符串和大型数组，
1、导致内存有空间，还是需要提前进行垃圾回收获取连续空间来放他们，
2、会进行大量的内存复制。
-XX:PretenureSizeThreshold 参数 ，大于这个数量直接在老年代分配，缺省为0 ，表示绝不会直接分配在老年代。
3 长期存活的对象将进入老年代，默认15岁，-XX:MaxTenuringThreshold调整
虚拟机给每个对象定义了年龄，在对象头里，每活过1次GC，年龄+1
4 动态对象年龄判定，为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄
5 空间分配担保：新生代中有大量的对象存活，survivor空间不够，当出现大量对象在MinorGC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代.只要老年代的连续空间大于新生代对象的总大小或者历次晋升的平均大小，就进行Minor GC，否则FullGC。
欢迎转载，但请保留文章原始出处→_→
生命壹号：http://www.cnblogs.com/smyhvae/
文章来源：http://www.cnblogs.com/smyhvae/p/4748313.html
原文：https://www.cnblogs.com/hup666/p/13096421.html