JVM 垃圾回收算法以及垃圾收集器以及内存分配规则

首先明确垃圾回收主要回收的是堆空间中已经死亡的对象。

一。如何判断对象已死？

判断对象是否已经成为垃圾有两种方案：

引用计数法（已经被弃用）：

具体的实现：给对象中添加一个引用计数器，当有一个地方引用它时，引用计数器就+1 ，当引用失效时，计数器值就-1；任何时刻，计数器的值为0 的对象就是不可能再被使用的。引用值为0 时对象就会成为垃圾

但是存在以下两个问题：

• 每次给对象赋值时均要维护引用计数器，并且引用计数器本身也有一定的内存消耗。
• 循环依赖的问题。比如 A对象引用B对象 ，B对象又引用A对象。

可达性分析法（GC_Root 根）（重点，目前大多数的商用JVM 大都采用该方法）

基本思路：

通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

在Java语言里，可作为GC Roots的对象包括下面几种:

• 虚拟机栈中的引用的对象：栈帧中的本地变量表
• 方法区中的类静态属性引用的对象。
• 方法区中的常量引用的对象。
• 一般说的Native方法 的引用的对象。

---

JVM垃圾收集算法有四种：标记-清除算法、复制算法、标记-整理算法、分代收集算法

标记清除-算法： 该算法如同它的名字一样，分为两个阶段：标记、清除。首先标记出所有需要回收的对象，然后，统一清除这些被标记的对象。

优点就是：垃圾回收的效率较快。

缺点是： 1、效率不高； 2、产生大量不连续的内存碎片，导致有大量内存剩余的情况下。由于，没有连续的空间来存放较大的对象，从而触发了另一次垃圾收集动作。

复制-算法： 复制算法将可用的内存分成两样大小的两块，每次只使用其中一块内存。当这块内存用完之后，就把还存活的对象复制到另外一块上面，然后，把这块清空。

复制算法克服了标记-清除算法的两个缺点，但是太浪费内存，相当于内存空间减小了一半。复制之后有交换，谁空谁为TWO

标记整理-算法： 该算法是对“标记-清除”算法的改进升级版。同样的该算法分为两个阶段：标记、整理。标记阶段同“标记-清除”算法。整理阶段，不是直接对标记对象进行清理，而是让所有存活的对象都移动到一端，然后，直接把边界以外的内存清空。

这就解决了“标记-清除”算法会造成大量不连续内存碎片的问题。 优化了碎片化问题

分代收集算法: 一般把Java堆分成新生代（年轻代）和老年代（年老代）。这样就可以根据各年代中对象的存活周期来选择最合适的收集算法了。比如典型的垃圾收集器：G1垃圾收集器。

新生代，由于只有少量的对象能存活下来，所以选用“复制算法”，只需要付出少量存活对象的复制成本。

老年代，由于对象的存活率高，没有额外的空间分担，就必须使用“标记-清除”或“标记-整理”算法。

---

了解并行和并发

JVM 常用的垃圾处理器：如何选择垃圾处理器的使用？

1.新⽣代的收集器包括：

1. Serial

2. PraNew

3. Parallel Scavenge

2.⽼年代的收集器包括：

1. Serial Old

2. Parallel Old

3. CMS  （详细掌握）

3.回收整个Java堆(新⽣代和⽼年代)

1. G1收集器 （详细掌握）

新生代垃圾收集器：

Serial GC 串行垃圾收集器：(适用于新生代): 它是一个单线程垃圾收集器，

单线程意味着：它只会使用一个CPU 或者一条收集线程去完成垃圾回收的工作，更重要的是在serial GC 进行垃圾回收的时候，必须暂停其他所有的工作线程(stop the world 由JVM 自发完成)。直到它收集结束。 运行在Client 模式下的首选的垃圾回收器。

缺点：在进行垃圾回收的时候，需要停止其他的用户线程，直到垃圾收集完成之后，才会恢复其他用户线程的执行。

优点：单线程垃圾收集实现简单且高效，在单CPU 环境下，由于不需要进行线程切换，可以高效的进行垃圾的回收。

parNew 收集器(并行垃圾收集器)：是对serial GC 的一种优化。相当于是多线程版本的serial GC 。 只能够和CMS垃圾收集器协同工作。

可以通过设置 -XX:+UseParNewGC 选项来强制使用并行垃圾回收器。 它是运行在Server模式下的虚拟机中首选的新生代收集器。

Parallel(并行) scavenge(读音：派弱了哦 诗刊文集) GC ： 大体上和parNewGC 一致，作为新生代垃圾收集器，使用的垃圾回收算法为复制算法，同样也是并行的多线程收集器。 由于更关注吞吐量，因此也被称为：吞吐量优先垃圾回收器

垃圾收集器的衡量好坏的标准：

响应时间：尽可能的缩短垃圾收集时用户线程的停顿时间。

吞吐量：   尽可能大的提高JVM的吞吐量

                吞吐量就是CPU用于运行用户代码的时间 与 CPU中总消耗时间的比值。

                吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

关注点：parallel Scavenge收集器的目标识达到一个可控制的吞吐量，并且提供了两个参数用于精准控制吞吐量。

-XX:MAXGCPauseMillis GC 最大可以暂停时间

-XX：GCTimeRatio 进行GC垃圾收集的GC比率。

===================================================================

老年代垃圾收集器：

SeraiL old GC 串行化老年代垃圾收集器：单线程的垃圾收集器。采用的垃圾收集算法为：标记-整理算法。 同时也会暂停用户所有线程，STW

同样会触发 Stop the world 。该垃圾收集器可搭配 Serial GC,ParNew GC, Parallel Sacvange GC 等新生代垃圾收集器。

Parallel(并行) old 收集器：老年代并行垃圾收集器 ，使用多线程和“标记-整理算法" 完成垃圾收集。

主要是用于和新生代垃圾收集parallel scavenge 垃圾收集搭配使用。同样被称为吞吐量优先垃圾收集器。

Parallel Old  是 Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的 Parallel Scavenge收集器一直处于比较尴尬的状态。

原因是：如果新生代选择了Parallel Scavenge收集器，老年代除了Serial 0ld (PS MarkSweep）收集器外别无选择（还记得上面说过ParallelScavenge收集器无法与CMS收集器配合工作吗?)。

由于单线程的老年代Serial Old收集器在服务端应用性能上的“拖累”，即便使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，

又因为老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew 加 CMS的组合“给力”。

直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作过程如图3-9所示。

CMS（Concurrent mark sweep）并发低停顿垃圾收集器( 重点)：是一种以获取最短回收停顿时间为目标的垃圾回收器。从名字上可以的得知 这一个基于标记-清除 实现的垃圾收集器。

它的实现过程分为4个阶段:   

1.初始标记：标记一下GC roots能够直接关联到的对象。会造成STW

2.并发标记：进行GC Roots Tracting(追踪) 的过程。

3.重新标记：  为了修正并发标记期间，因用户线程程序继续运行而导致的标记发生变动的那一部分对象的标记记录。

4.并发清除：

G1垃圾收集器：基于 标记整理 算法实现的垃圾收集器。

垃圾收集器涉及到使用的参数：

参数	描述
UseSerialGC	虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial+Serial Old的收集器 组合进行内存回收。
UseParNewGC	打开此开关后，使用parNew +serial Old 的垃圾收集器组合进行内存回收。
UseConcMarkSweeGC	打开此开关后，使用CMS+ParNew+Serial Old 的收集器组合进行内存回收。serial old收集器将作为CMS垃圾手机出现Concrrent Mode Failure 失败后的后备收集器使用
userParallelGC	虚拟机运行在Server模式的默认值，打开此开关后，使用Parallel Scavenge+Serial Old (ps markSweep)的收集器组合进行内存回收
useParallelOldGc	打开此开关后，使用parallel scavenge +parallel old 的收集器组合机械能给内存回收
survivor(生还者)Ratio（比例）	新生代中eden 区域与surivor 区域的容量占比，默认为8。代表Eden:survivor=8:1 。其实新生代的区域划分为: Eden survivor1 survivor2
pretenureSizeThreshold(临界值)	直接进入到老年代的对象大小，设置这个参数后，大于这个参数的对象将会直接分配到老年代
MaxTenurinng(特宁)Threshold	晋升到老年代的对象年龄，每当对象在坚持过一次Minnor GC 之后，年龄就加1 ，当超过这个参数值时就进入老年代。
MaxGcPauseMills	设置GC 最大的停顿时间，仅使用Parallel scavenge 收集器时生效。
GcTimeRatio	GC 时间占总时间的比率，默认为99，即：允许1%的GC 时间，仅在使用Parallel Sacvenge 收集器时生效

---

内存分配与回收的策略：

java体系所提倡的自动化内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存 以及 回收分配给对象的内存。那么是如何进行 “给对象分配内存”这个事情的呢？

大多数情况下，对象在新生代Eden区中分配。当Eden 区没有足够的空间进行内存分配时，虚拟机将发生一次Minor GC 。

-XX:+PrintGCDetials :打印垃圾收集日志参数，告诉虚拟机在发生垃圾收集行为时，打印内存回收日志，并且在进程退出的时候输出当前内存各区域的分配情况。

-xms:设置初始化的内存分配大小 如 -smx 20M

-xmx：设置最大的内存分配大小 如 -smx 20M 建议将 初始化内存和最大内存设置同样的值，避免不断的扩容，影响JVM 的性能。

-xmn: 设置新生代所能够使用的内存大小。如 -xmn 10M 即是：分配10m 的内存给新生代，剩余10m内存分配给老年代。

-XX: survivorRatio=8 表示新生代中的Eden 区和survivor 区的空间比例为8:1。

大对象会直接进入到老年代

 

分代收集：通过对象年龄计数器完成（动态对象年龄判断）

虚拟机既然采用了分代收集的思想来管理内存，那内存回收时就必须能识别哪些对象应当放在新生代，哪些对象应放在老年代中。

为了做到这点，虚拟机给每个对象定义了一个对象年龄（Age)计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活,并且能被Survivor容纳的话，将被移动到 Survivor空间中，并将对象年龄设为1,

对象在Survivor区中每熬过一次 Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁)时，就会被晋升到老年代中。对象晋升老年代的年龄阂值，可以通过参数-XX:MaxTenuring（任期） Threshold来设置。

空间分配担保策略：

在发生 Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小,如果大于，则改为直接进行一次Full GC。

如果小于，则查看HandlePromotionFailure设置是否允许担保失败;如果允许，那只会进行Minor GC:如果不允许，则也要改为进行一次Full GC。

前面提到过，新生代使用复制-收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况时（最极端就是内存回收后新生代中所有对象都存活)，就需要老年代进行分配担保，

让Survivor 无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来，在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。
取平均值进行比较其实仍然是一种动态概率的手段，也就是说如果某次MinorGC存活后的对象突增，远远高于平均值的话，依然会导致担保失败(HandlePromotion Failure)。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁。

完结