GC基础
by shihang.mai
1. 引用类型
1.1 StrongReference强引用
回收时间:垃圾回收永远不会回收。内存不足就抛出OOM Error
使用场景:我们平时经常写的代码就是强引用
使用举例:
public class Main {
public static void main(String[] args) {
new Main().fun1();
}
public void fun1() {
Object object = new Object();
Object[] objArr = new Object[1000];
}
}
1.2 SoftReference软引用
回收时间:只有在内存不足的时候 JVM 才会回收该对象
使用场景:软引用是用来描述一些有用但并不是必需的对象,这个特性很适合用来实现缓存：比如网页缓存、图片缓存
使用举例:
public class Main {
public static void main(String[] args) {
SoftReference<String> sr = new SoftReference<String>(new String("hello"));
System.out.println(sr.get());
}
}
1.3 WeakReference弱引用
回收时间:垃圾回收就会回收
使用场景:ThreadLocal
使用举例:
public class Main {
public static void main(String[] args) {
WeakReference<String> sr = new WeakReference<String>(new String("hello"));
}
}
1.4 PhantomReference虚引用
回收时间:垃圾回收就会回收
使用场景:当使用DirectByBuffer分配堆外内存时，当设置DirectByBuffer = null,GC回收并不会回收这块内存，那么我们可以监听这个Queue，如果有数据，那么证明DirectByBuffer指向的内存要被回收，我们做相应处理
使用举例:
虚引用必须配合ReferenceQueue使用，即构造方法中必须传入ReferenceQueue
public class Main {
public static void main(String[] args) {
ReferenceQueue<String> queue = new ReferenceQueue<String>();
PhantomReference<String> pr = new PhantomReference<String>(new String("hello"), queue);
System.out.println(pr.get());
}
}
2. 如何找到垃圾
2.1 Reference counter
引用计数。当引用数将为0，就可以认为是垃圾。
但是这个算法不能解决以下问题,按Reference counter，这3个均不是垃圾。当这3个的整体都没被引用，其实这3个都是垃圾。
2.2 Root searching
根可达算法。从根开始查找，那些没关联的对象，就是可回收对象。根包括:
- 虚拟机栈中的引用对象
- 方法区中的类静态属性引用的对象
- 方法区常量引用的对象
- 本地方法栈中JNI的引用的对象
首先，gc主要是针对堆内存的，上面都是jvm stack、native method stack、method area引用的对象。
2.3 垃圾一定回收?
即使在可达性分析算法中不可达的对象,也并不是一定回收
- 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选
- 筛选的条件是此对象是否有必要执行finalize()方法。是否有必要的判断条件
当前对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机曾经调用过
- 没必要执行,直接回收
- 有必要执行,那么将这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它
- finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可,那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了
3. 清除算法
3.1 Mark-sweep
标记清除算法。将存过的标记，然后，将其他清除掉。
这种算法相对简单，存活对象比较多的情况下效率较高。两次扫描，效率低，容易产生碎片。第一次扫描标记那些是不可回收的，然后第二次扫描清除那些可回收的对象。
3.2 Copying
先将所有存活的对象复制到另外一个半区，然后直接清除上一半区
适用于存活对象比较少的情况，只扫面一次，效率高，但是这样就需要调整对象引用，而且空间比较浪费
3.3 Mark-compact
标记压缩。将所有存活的对象移动到头，然后清理后面所有区域。
会扫描两次，第一次扫描标记存活的对象，第二次扫描移动对象，并把可回收的回收掉。这样做，不会产生碎片，方便对象分配，不会产生内存减半，但是要扫描两次，又涉及到对象移动，效率低
3.4 清除算法总结
年轻代GC，叫MinorGc/YGC
年轻代和老年代同时GC，叫MajorGC/FullGC
| 算法 | 名称 | 描述 | 优缺点 |
|---|---|---|---|
| Mark-sweep | 标记清除 | 第一次扫描标记存活对象，第二次扫描清除可回收对象。对象不做移动处理。 | 两次扫描，效率低，容易产生碎片 |
| Copying | 复制清除 | 将内存一分为2，第一次扫描将存活对象复制到另外一个半区，然后清除当前半区。对象需要做移动处理 | 只扫面一次，效率高，但是这样就需要调整对象引用，而且空间比较浪费 |
| Mark-compact | 标记压缩清除 | 第一次扫描，将存活对象标记，第二次扫描移动存活对象到头部，并清除可回收对象 | 不会产生碎片，方便对象分配，不会产生内存减半，但是要扫描两次，又涉及到对象移动，效率低 |
4. 堆内存逻辑分区
除Epsilon、ZGC、Shenandoah、G1外其他垃圾回收器的堆内存逻辑分区。
5. 条件
- 触发ygc条件
- 当eden区没有足够用空间放新创建的对象时，触发，将eden区和survivor from区的存活对象复制到survivor to区，然后清理eden区和survivor from区.再将survivor from区和survivor to区指向互换
- 空间分配担保：老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小
- 对象进入老年代的条件
- YGC时，To Survivor区不足以存放存活的对象，对象会直接进入到老年代
- 经过多次YGC后，如果存活对象的年龄达到了设定阈值，则会晋升到老年代中
- 动态年龄判定规则，To Survivor区中相同年龄的对象，如果其大小之和占到了 To Survivor区一半以上的空间，那么大于此年龄的对象会直接进入老年代，而不需要达到默认的分代年龄
- 大对象：由-XX:PretenureSizeThreshold启动参数控制，若对象大小大于此值，就会绕过新生代, 直接在老年代中分配
- 触发ogc条件：
- 只有cms有单独的ogc回收，其他均是full gc才会触发ogc
- 对于cms来说，已用92%的老年代就触发
- 触发full gc条件：
- 除g1、zgc外，当晋升到老年代的对象大于了老年代的剩余空间时，就会触发FGC
- 空间分配担保：除g1、zgc外，只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC
- Metaspace（元空间）在空间不足时会进行扩容，当扩容到了-XX:MetaspaceSize 参数的指定值时，也会触发FGC
- System.gc() 或者Runtime.gc() 被显式调用时，触发FGC
参考博客:
https://segmentfault.com/a/1190000010463373
https://www.jianshu.com/p/989d3b06a49d
