JVM之垃圾回收机制
垃圾回收机制
- 垃圾回收时机
- System.gc()
- JVM垃圾回收机制决定
- 垃圾回收策略---如何判断对象已死？
- 引用计数算法
- 可达性分析算法
- 需要垃圾回收的内存
- 方法区/元空间
- 堆
- 新生代（Young Generation）
- 老年代(Old Generation)
- Full GC
- 垃圾回收算法
- 标记-清除算法（Mark-Sweep）
- 标记-整理算法(Mark-Compact)
- 复制算法(Copying)
- 分代收集算法
- 垃圾回收的过程
- 堆的GC
- 新生代GC（Minor GC）
- 老生代GC
- 内存分配与回收策略
- 对象优先在Eden分配
- 大对象直接进入老年代
- 长期存活的对象将进入老年代
- 动态对象年龄判定
- 空间分配担保
- 垃圾收集器
- 新生代收集器
- Serial收集器
- ParNew收集器
- Parallel Scavenge收集器
- 老生代收集器
- Serial Old收集器
- Parallel Old收集器
- CMS（Concurrent Mark Sweep）收集器
- G1收集器（全堆的垃圾回收器）
- JVM参数
Garbage Collection（GC），Java进程在启动后会创建垃圾回收线程，来对内存中无用的对象进行回收。
垃圾回收时机
System.gc()
显式的调用System.gc()：此方法的调用是建议JVM进行 FGC（Full GC），但很多情况下它会触发 FGC，从而增加FGC的频率。一般不使用此方法，让虚拟机自己去管理它的内存。
JVM垃圾回收机制决定
java.lang.Object中有一个finalize() 方法，当JVM 确定不再有指向该对象的引用时，垃圾收集器在对象上调用该方法。finalize()的作用是在对象进行垃圾回收之前，标记对象的可回收状态。
垃圾回收策略—如何判断对象已死？
引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。 引用计数算法的实现简单，判定效率也很高，但是它很难解决对象之间相互循环引用的问题。Python、ActionScript等语言都是基于引用计数法。
可达性分析算法
通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为GC Roots引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。Java、C#等语言都是使用可达性分析算法进行垃圾回收
需要垃圾回收的内存
方法区/元空间
- jdk1.7的方法区在GC中一般称为永久代（Permanent Generation）。
- jdk1.8的元空间存在于本地内存，GC即对元空间进行垃圾回收。
- 永久代或元空间的垃圾收集主要回收两部分内容：废弃常量和无用的类。
堆
- Java堆是垃圾收集器管理的主要区域，也被称为“GC堆”。
- 由于现代收集器都采用分代收集算法，所以Java堆还可以细分为：
新生代（Young Generation）
新生代(Young Generation)又可以分为Eden空间、From Survivor空间、 To Survivor空间。
- 新生代的垃圾回收又称为Young GC (YGC) 、Minor GC。
- 指发生在新生代的垃圾收集动作，因为ava对象大多都具备朝生夕灭的特性,所以Minor GC非常频繁，一般回收速度也比较快。
老年代(Old Generation)
- 老年代垃圾回收又称为Major GC。
- 指发生在老年代的GC，出现了Major GC,经常会伴随至少- -次的Minor GC (但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。
- Major GC的速度一般会比Minor GC慢10倍以上。
Full GC
在不同的语义条件下，对Full GC的定义也不同，有时候指老年代的垃圾回收，有时候指全堆（新生代+老年代）的垃圾回收，还可能指有用户线程暂停（Stop-The-World）的垃圾回收（如GC日志中）。
垃圾回收算法
标记-清除算法（Mark-Sweep）
类似于本地文件夹内，先将要删除的文件标记一下，之后遍历一个一个删除。回收前后状态如图所示：
（1）分为两个阶段：标记、清除；
（2）老年代的回收算法；
（3）不足：①效率不高②产生大量不完整的内存碎片——会导致再进入大对象，如果没有连续空间存放，会触发Major GC。
标记-整理算法(Mark-Compact)
移动存活对象到一端，清理另一端内存。
（1）老年代的回收算法；
（2）分为两个阶段：标记、整理。
复制算法(Copying)
类似于本地文件夹内，将不用删除的文件全都复制到另一个文件夹内，之后把前一个文件夹全删了。
（1）新生代的回收算法；
（2）内存使用率不高，只有50%；
（3）优点：实现简单，运行高效，不会产生内存碎片问题。
分代收集算法
（1）当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思想，只是根据对象存活周期的不同将内存划分为几块。
（2）一般是把Java堆分为新生代和老年代。
（3）新生代中98%的对象都是"朝生夕死"的，所以并不需要按照复制算法所要求1 : 1的比例来划分内存空间，而是将内存（新生代内存）分为一块较大的Eden（伊甸园）空间和两块较小的Survivor（幸存者）空间，每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区域）。HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说Eden :
Survivor From : Survivor To = 8 : 1 : 1。所以每次新生代可用内存空间为整个新生代容量的90%，只有10%的内存会被”浪费“。
（4）在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代中对象存活率高、没有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整理"算法。
垃圾回收的过程
堆的GC
新生代GC（Minor GC）
Eden区和使用的S区里的存活对象，复制到留空的S区。GC前后，两块S区的角色发生转变。
Eden区进入对象的条件：创建对象时，优先分配的区域——Eden空间不足，触发Minor GC（新生代GC）
Survivor区：一块保存对象，一块留空。
进入对象的条件：触发Minor GC时，留空的S区，会进入GC后存活对象——Survivor区空间不足，导致存活对象通过分配担保机制进入老年代。
步骤
（1）复制存活对象到Survivor区另一块，存活对象年龄加一；
（2）清空Eden区和前一块Survivor区；
（3）给需要创建的对象分配内存
老生代GC
进入对象的条件（1）大对象直接进入；（2）长期存活的对象进入老年代——对象年龄>阈值；（3）Minor GC时，留空S区空间不足存放GC后的存活对象，所有存活对象，进入老年代
老年代空间不足，会触发Major GC
内存分配与回收策略
对象优先在Eden分配
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发生一次Minor GC。
大对象直接进入老年代
- 所谓的大对象是指，需要大量连续空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。
- 大对象对虚拟机的内存分配是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发GC以获取足够的连续空间来放置大对象。
长期存活的对象将进入老年代
- 既然虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代中。
- 为了做到这点，虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且把对象年龄设为1。对象在Survivor空间中每"熬过"一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将晋升到老年代中。
动态对象年龄判定
- 为了能更好的适应不同程序的内存状况，JVM并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代。
- 如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
空间分配担保
- 发生Minor GC时，是使用复制算法将Eden区和Survivor区存活对象复制到另一个Survivor区：
（1）Survivor区只占新生代10%空间，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。
（2）内存的分配担保就好比我们去银行借款，如果我们信誉很好，在98%的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。
（3）内存的分配担保也一样，如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。- 在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
（1）如果大于，则此次Minor GC是安全的；如果小于，则虚拟机会查看 HandlePromotionFailure设置值是否允许担保失败。
（2）如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。
（3）上面提到了Minor GC依然会有风险，是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（最极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。取平均值仍然是一种概率性的事件，如果某次Minor GC后存活对象陡增，远高于平均值的话，必然导致担保失败，如果出现了分配担保失败，就只能在失败后重新发起一次Full GC。虽然存在发生这种情况的概率，但大部分时候都是能够成功分配担保的，这样就避免了过于频繁执行Full GC。- 以上过程类似银行贷款给用户，需要担保的过程，例如：
- 贷款行为=Minor GC
- 贷款金额=Eden区+Survivor区所有对象大小
- 用户在贷款后进行消费的金额=Minor GC后存活的对象大小
- 用户的资产=另一块Survivor区大小
- 担保人=老年代
- 担保人的银行存款=老年代最大可用连续空间大小
- 用户的失信消费金额=用户消费金额超出用户资产后，让担保人偿还的情况下，用户的消费金额
用户在贷款时，银行是不知道用户会消费多少的，如果消费超过用户的总资产，将直接从担保人银行存款扣除。而贷款过程就是：- 贷款前，银行发现担保人的银行存款足够偿还贷款，就允许贷款（Minor GC）。
- 如果担保人的银行存款不足偿还贷款，且担保人拒绝用存款担保，会让担保人清理资产变现（Major GC）。
- 如果担保人的银行存款不足偿还贷款，但担保人愿意用存款担保，银行基于风险考虑，还要检查用户历次的失信记录，也就是用户的失信消费金额，统计出平均的失信消费金额。
- 如果担保人的银行存款比用户平均的失信消费金额小，说明风险太大，不接受贷款，让担保人清理资产变现（Major GC）再贷款（Minor GC）。
- 如果担保人的银行存款比用户平均的失信消费金额大，说明风险虽然还是有，但可以接受，允许贷款。但如果贷款后，用户消费金额太大，担保人银行存款都不足偿还，需要让担保人清理资产变现后偿还（Major GC）。
垃圾收集器
新生代收集器
Serial收集器
（1）单线程
（2）STW（Stop-The-World）用户线程的暂停
（3）复制算法
ParNew收集器
（1）多线程
（2）STW
（3）复制算法——和CMS搭配使用在用户体验优先（用户要调用程序接口，执行程序代码）的程序中
Parallel Scavenge收集器
（1）多线程
（2）吞吐量优先——主要是后台任务性的程序（比如定时任务，不涉及用户使用的程序）
（3）自适应的调节策略：JVM设置这个参数=true之后，JVM可以监控性能，并动态地设置内存相关参数（如年龄阈值、新生代大小、Eden和S区比例）
老生代收集器
Serial Old收集器
（1）单线程
（2）标记整理算法——CMS在发生并发失败（Concurrent Mode Failure）时作为备用垃圾回收方案
Parallel Old收集器
（1）多线程
（2）STW
（3）标记整理算法
（4）吞吐量优先——搭配Parallel Scanvenge一起使用
CMS（Concurrent Mark Sweep）收集器
（1）标记清除算法
（2）用户体验优先
（3）分为四个阶段：
- 初始标记：标记GC Roots能直接关联的对象，速度很快，STW（标记object5）
- 并发标记：GC Roots Tracing（标记object7）
- 重新标记：STW——解决第二阶段用户线程并发执行，导致已经标记的对象（可回收）被重新引用（有GC Roots变量指向该对象）
- 并发清除：并发清除对象
四个阶段中：
（1）1和3执行速度快，消耗时间少——暂停用户线程时间少
（2）2和4执行时间相对较慢，但是可以和用户线程并发执行
总体来看，CMS垃圾回收的工作是和用户线程同时执行。
（4）缺陷
1.CMS垃圾回收线程会抢占CPU资源，导致用户线程总的执行时间更少；
2.浮动垃圾问题：
①产生原因：CMS第四个阶段，用户线程并发执行有可能导致有对象进入老年代，而老年代也可能剩余空间不足，触发Major GC；
②解决方案：使用Serial Old来进行垃圾回收；
③标记清除算法会导致老年代空间碎片，如果进入的对象没有连续的可用空间，触发Full GC。
CMS回收线程的第四个阶段：
G1收集器（全堆的垃圾回收器）
1.整体看是基于标记整理算法，局部看是基于复制算法；
2.用户体验优先；
3.内存划分：对内存划分为很多region，每个region都是动态指定为Eden区、S区、T区（老年代内存）；
4.原理/实现：分为4个阶段：
（1）初始标记：可以和Minor GC（新生代GC）同时执行，STW
（2）并发标记：Garbage First，清理老年代总（T区、Tenured Generation），存活率很小或没有对象存活的T区
（3）最终标记：STW，和CMS第三个阶段算法不同
（4）筛选回收：采用clean up/copy和新生代类似的整理工作，可以和Minor GC同时执行
JVM参数
-Xmssize
设置堆的初始化大小。如设置堆空间初始化大小为6m：-Xms6291456 或 -Xms6144k 或 -Xms6m
-Xmxsize
设置堆的最大值。如设置堆空间的最大值为80m：-Xmx83886080 或 -Xmx81920k 或 -Xmx80m
-Xmnsize
设置年轻代的大小（初始化及最大值）。如设置256m大小的年轻代：-Xmn256m 或 -Xmn262144k 或-Xmn268435456
-XX:NewSize
设置年轻代的初始化大小。
-XX:MaxNewSize
设置年轻代的最大值。
-XX:PermSize=size
设置永久代的大小（jdk1.7方法区）
-XX:MaxPermSize=size
设置永久代的最大值（jdk1.7方法区）
-XX:MetaspaceSize=size
设置永久代的大小（jdk1.8元空间）
-XX:MaxMetaspaceSize=size
设置永久代的最大值（jdk1.8元空间）
-XX:SurvivorRatio=ratio
设置Eden区与Survivor区的空间比例，默认为8，即Eden=8，Survivor From=1，Survivor To=1。
-XX:MaxTenuringThreshold=threshold
对象晋升到老年代的年龄阈值
-XX:PretenureSizeThreshold=size
在老年代分配大对象的阈值，单位只能使用byte，如3m，只能写为3145728
-XX:+PrintGCDetails
打印gc详细信息