本文只涉及垃圾收集器，对垃圾回收算法感兴趣请戳垃圾回收算法
垃圾收集器的实现，跟厂商有很大关系。
这里讨论的HotSpot是较新的Java虚拟机
JVM是一个进程，垃圾收集器就是一个线程（守护线程、优先级低）
新生代收集器还是老年代收集器？新生代收集器：Serial、ParNew、Parallel Scavenge；
老年代收集器：Serial Old、Parallel Old、CMS；
整堆收集器：G1
吞吐量优先：Parallel Scavenge、Parallel Old
停顿时间优先：CMS（Concurrent Mark-Sweep）
停顿时间优先：交互多，对响应速度要求高
吞吐量优先：交互少，计算多，适合在后台运算的场景。
串行：Serial、Serial Old
并行：ParNew、Parallel Scavenge、Parallel Old
并发：CMS、G1
复制算法：Serial、ParNew、Parallel Scavenge、G1
标记-清除：CMS
标记-整理：Serial Old、Parallel Old、G1
串行收集器是最基本、发展最悠久的收集器
JDK1.3.1前是HotSpot新生代收集的唯一选择
特点：
1）针对新生代
2）串行
3）复制算法
4）单线程一方面意味着他只会使用一个CPU或一个线程去完成垃圾收集工作
5）另一方面意味着它进行垃圾收集时，必须暂停其他所有的工作线程，直到他收集结束为止 即STW
6）后者意味着，在用户看不到的情况要把用户正常工作的线程全部停掉，这显然对很多应用是难以接受的
应用场景
对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率
Serial收集器依然是虚拟机运行在Client模式下的默认新生代收集器
注意：
1）STW是在用户不可见的情况下执行的，会造成某些应用响应变慢
2）新生代对象存活率低，复制算法，复制内容不多，性能较好
3）单线程的好处就是减少上下文切换，减少系统资源的开销
（缺点：GC过程中，会暂停程序的执行，若GC不频繁还可以，否则影响执行性能）
对于新生代来说，区域较小，停顿时间短，所以比较适用
参数：
-XX:+UseSerialGC：串联收集器
在JDK Client模式，不指定VM参数，默认是串行垃圾回收器
2、ParNew收集器ParNew收集器是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为和Serial收集器完全一样
特点：
1）针对新生代
2）复制算法
3）并行
4）多线程
5）GC需要暂停所有用户线程，直到GC结束
6）Serial多线程版本，其他特点与Serial相同
应用场景
许多运行在server模式下的虚拟机中首选的新生代收集器
其中一个与性能无关的重要原因是：
除了serial收集器外，目前只有它能和CMS收集器配合工作
参数
1）-XX:+UseConcMarkSweepGC
指定使用CMS后，会默认使用ParNew作为新生代收集器
2）-XX:+UseParNewGC
强制使用ParNew
3）-XX:ParallelGCThreads
指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU数量相同
为什么只有ParNew能与CMS收集器配合？
1）JDK1.5时期，HotSpot推出了一款几乎可以认为具有划时代意义的垃圾收集器—CMS收集器，第一款真正意义的并发收集器，第一次实现了让垃圾收集线程与用户线程同时工作
2）CMS作为老年代收集器，但却无法与JDK1.4已经存在的新生代收集器Parallel Scavenge配合工作
3）因为Parallel Scavenge（以及G1）都没有使用传统的GC收集器代码框架，而另外独立实现；而其余几种收集器则共用了部分的框架代码；
Parallel Scavenge收集器和ParNew类似，与ParNew最大的不同，它关注的是垃圾回收的吞吐量。
特点
1）针对新生代
2）复制算法
3）并行
4）多线程
5）高吞吐量为目标
应用场景
虚拟机运行在server模式下的默认垃圾收集器
高吞吐量为目标，即减少垃圾收集时间，让用户代码获得更长的运行时间，适合那种交互少，运算多的场景
例如：执行批处理、订单处理、工资支付、科学计算的应用程序
参数
1）-XX:+MaxGCPauseMillis 3）-XX:+UseAdptiveSizePolicy 新生代的大小（-Xmn）、Eden与survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold） GC自适应的调节策略（GC Ergonomiscs） Parallel Scavenge收集器无法与CMS收集器配合使用 与CMS相比： 与ParNew相比： Serial 收集器在新生代和老年代都有对应的版本，除了收集算法不同，两个版本并没有其他差异。 特点： 应用场景 Parallel 收集器在新生代和老年代也都有对应的版本，除了收集算法不同，两个版本并没有其他差异。 并行收集器，吞吐量优先 应用场景 1）在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑parallel scavenge和parallel old收集器组合 参数 -XX:+UseParallelOldGC：指定使用Parallel Old收6、CMS(Concurrent Mark Sweep)收集器 概述 特点 应用场景： CMS GC过程：四步 1）单线程执行 1）对于初始标记过程所标记的初始标记对象，进行并发追踪标记 1）在并发标记的过程中，由于可能还会产生新的垃圾，所以此时需要重新标记新产生的垃圾 1）并发清除之前所标记的垃圾 Tips： 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以整体上说，CMS收集器的内存回收过程与用户线程一起并发执行 参数 缺点 1）对CPU资源非常敏感 对CPU资源非常敏感 其实，面向 并发设计的程序都对CPU资源敏感 在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低 CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在四个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降 但当CPU不足4个时，CMS对用户程序的影响可能就变的很大，如果本来CPU负载就比较大，还要分出一半的运算能力区执行收集器线程，就可能导致用户程序的执行速度忽然降低了50% 并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低 当CPU数量多于4个，收集线程占用的CPU资源多于25%，对用户程序影响可能较大；不足4个时，影响更大，可能无法接受。 2）浮动垃圾 由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然会产生新的垃圾，这一部分垃圾出现在标记之后，CMS无法在当次收集处理掉，只好留给下次GC 由于在垃圾收集阶段用户线程还需要运行，那就还需要预留有足够的内存空间，给用户线程使用，因此，CMS收集器不能像其他收集器那样等到老年代几乎被填满在进行收集，也可以认为CMS所需要的空间比其他垃圾收集器大 -XX:CMSInitiatingOccupancyFraction： 3）concurrent mode failure 失败 如果CMS运行期间预留的内存无法满足程序需要，就会出现一次 并发模式故障，这时 虚拟机将启动后备预案：临时启用serial old收集器来重新进行老年代的垃圾收集，这样会导致另一次Full GC的产生，这样停顿的时间就更长了 4）产生大量内存碎片 标记清除算法的问题 解决办法 概述： G1（Garbage-First）是JDK7-u4才推出商用的收集器； G1与前面的垃圾收集器有很大不同，它把新生代、老年代的划分取消了！ 取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器 这些区域的一部分包含 新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。 老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。 这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有CMS内存碎片问题的存在了 在G1中，还有一种特殊的区域，叫Humongous区域 这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。 为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。 如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。 1）横跨整个堆内存 能充分利用多CPU、多核环境下的硬件优势 并行：使用多个CPU来缩短STW 的停顿时间 1）能独立管理整个GC堆，而不需要与其他收集器搭配 1）从整体看，基于标记-整理 1）G2收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集 应用场景 如果你的应用追求低停顿，那G1现在已经可以作为一个可尝试选择，如果你的应用追求吞吐量，那G1并不会为你带来什么特别的好处。 1）面向服务端应用，针对具有大内存、多处理器的机器；最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案 2）用来替换掉JDK1.5的CMS收集器 参数 1）-XX:+UseG1GC 2）-XX:InitiatingHeapOccupancyPercent 当整个Java堆的占用率达到参数值时，开始并发标记阶段，默认45 3）-XX:MaxGCPauseMillis 为G1设置暂停时间目标，默认200毫秒 4）-XX:G1HeapRegionSize 设置每个region大小，范围1MB到32MB 为什么G1收集器可以实现可预测停顿？？ G1可以建立可预测的停顿时间模型，是因为： G1跟踪各个Region获得其收集价值大小，在后台维护一个优先列表 每次根据允许的收集时间，优先回收价值最大的Region 这就保证了在有限的时间内可以获取尽可能高的收集效率 G1收集器运作过程 1）单线程执行 1）进行GC Roots Tracing的过程，从刚才产生的集合中标记出存活对象（也就是从GC Roots 开始对堆进行可达性分析，找出存活对象） 1）最终标记和CMS的重新标记阶段一样，也是为了修正并发标记阶段用户程序继续运作产生导致标记产生变动的那一部分对象的标记记录 1）首先排序各个Region的回收价值和成本
控制最大垃圾收集停顿时间，大于0的毫秒数；
这个参数设置越小。停顿时间可能会缩短，但导致吞吐量下降，导致GC频繁
2）-XX:GCTimeRatio
垃圾收集时间占总时间的比率 0垃圾收集执行时间占应用程序执行时间的比例的计算方法是：
1 /(1 + n)
例如：选项-XX:GCTimeRatio=9，则垃圾收集时间占总时间
10%=1 / (1 + 9)
默认值1% 即n=99
垃圾收集所花费时间是新生代和老年代收集的总时间
开启这个参数后，就不用手工指定一些细节参数
JVM会根据当前系统运行情况收集性能监控信息，动态调整这些参数，以提供最合适的停顿时间或者最大的吞吐量
所以在JDK 1.6推出Parallel Old之前，如果新生代选择Parallel Scavenge收集器，老年代只有Serial Old收集器能与之配合使用。
关注点不同，CMS关注点是尽可能的缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge则是达到一个可控制的吞吐量、被称为吞吐量优先收集器
parallel scavenge具有自适应调节策略
1）serial old是serial的老年代版本
2）除了采用标记-整理算法，其他相同
1）Client模式
serial old的主要意义也是在于给Client模式下的虚拟机使用
2）Server模式
如果在Server模式下，有两大用途：
a.在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用
b.作为CMS收集器的后备预案，在并发收集发生"Concurrent Mode Failure"时使用。
特点：
1）Parallel Scavenge收集器的老年代版本
2）Parallel Old 老年代采用的是标记 - 整理算法，其他特点与parallel scavenge相同
2）JDK1.6及之后用来代替老年代的Serial Old收集器
3）特别是在server模式，多CPU情况下
66、CMS(Concurrent Mark Sweep)收集器
、CMS(Concurrent Mark Sweep)收集器
集器
1）CMS是HotSpot在JDK5推出的第一款真正意义的并发收集器，第一次实现了让垃圾收集线程与用户线程同时工作
2）命名中用concurrent，而不是parallel，说明这个收集器是有与工作执行并发的能力，MS则说明是标记-清除算法
3）关注点是，垃圾回收最短的停顿时间（低停顿），在老年代并不频繁的场景下，是比较适用的
1）针对老年代
2）标记-清除算法（不进行压缩，产生内存碎片）
3）并发
4）多线程
5）收集过程中不需要暂停用户线程
6）以获取最短回收停顿时间为目标
1）与用户交互多的场景
2）目前很大一部分的Java应用集中在互联网或者B/S系统的服务端上，这类应用注重响应速度，希望停顿时间最短，给用户带来极好的体验
3）CMS是一种以获取最短回收停顿时间为目标的收集器
2）需要STW
3）但仅仅把GC Roots的直接关联可达的对象标记一下，由于直接关联对象比较小，所以这里的速度非常快
2）此时其他线程仍可继续工作
3）此处时间较长，但不停顿
4）并不能保证可以标记出所有的存活对象
2）此处执行并行标记，与用户线程并不并发，所以依然STW
3）且停顿时间比初始标记长，但比并发标记短
2）其他线程仍可以工作，不需要停顿
其中，初始标记和重新标记仍STW，初始标记仅仅标记一下GC Roots能关联到的对象，速度很快，并发标记就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间比初始标记阶段长，但远比并发标记的时间短。
1）-XX:+UseConcMarkSweepGC
使用CMS收集器
2）-XX:+ UseCMSCompactAtFullCollection
Full GC后，进行一次碎片整理，整理过程是独占的，会引起停顿时间变长
3）-XX:+CMSFullGCsBeforeCompaction
设置进行几次Full GC进行一次碎片整理
4）-XX:ParallelCMSThreads
设定CMS的线程数量（一般情况约等于可用CPU数量）
总体来看，与parallel old垃圾收集器相比，CMS减少了执行老年代垃圾收集时应用暂停时间，
但却增加了新生代垃圾收集时应用暂停的时间、降低了吞吐量而且需要占用更大的堆空间
由于最耗费时间的并发标记与并发清除都需要暂停工作，所以整体回收时低停顿的
设置CMS预留内存空间
所以 预留内存空间 也不能设置太大
1）-XX:+ UseCMSCompactAtFullCollection
Full GC后，进行一次碎片整理，整理过程是独占的，会引起停顿时间变长
默认开启（但不会进行，结合下面的CMSFullGCsBeforeCompaction）
2）-XX:+CMSFullGCsBeforeCompaction
设置进行几次Full GC进行一次碎片整理
默认为0，也就是说每次都执行Full GC，不会进行压缩整理；
G1（garbage-first）：G1跟踪各个Region里面的垃圾堆的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region
如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。
特点：G1除了降低停顿外，还能建立可预测的停顿时间模型；
2）在G1之前的其他收集器进行收集的范围都是整个新生代或者老生代，而G1不是这样
3）G1在使用时。Java堆的内存布局与其他收集器有很大的区别
4）它将整个Java堆划分为多个大小相等的独立区域（Region）
5）虽然还保留新生代和老年代的概念，但是新生代和老年代不再是物理隔离的了，而都是一部分Region（可以不连续）的集合
G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短STW的停顿时间
并发：也可以让垃圾收集与用户程序同时进行
2）能够采用不同方式处理不同时期的对象
2）从局部（两个Region间）看，复制算法
3）都不会产生内存碎片，有利于长期运行
4）分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC
2）G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表
3）每次根据允许的收集时间，优先回收价值最大的Region，这样就保证了在有限的时间内尽可能提高效率，（这也就是garbage-first的名称由来）
4）这种使用region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率
如：在堆带下约为6GB或者更大时，可预测的暂停时间可以低于0.5秒
a.超过50%的Java堆被活动数据占用
b.对象分配频率或年代提升频率变化很大
c.GC停顿时间过长（长于0.5至1秒）
指定使用G1收集器
目标是在最小Java堆时可以拥有约2048个region
可以有计划地避免在Java堆的进行全区域的垃圾收集
2）需要STW
3）但仅仅把GC Roots的直接关联可达的对象标记一下，由于直接关联对象比较小，所以这里的速度非常快
2）耗时较长，但应用程序也在运行
3）并不能保证可以标记出所有存活对象
2）这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短
3）也需要STW（修正Remebered Set）
2）然后根据用户期望的GC停顿时间来指定回收计划
3）最后按计划回收一些价值高的region中的垃圾对象
4）回收时采用 复制 算法，从一个或多个Region复制存活对象到堆上的另一个空的Region，并且在此过程中压缩和释放内存；
5）可以并发进行，降低停顿时间，并增加吞吐量
