1. 判断对象可回收
1.1 引用计数法
- 每个对象都使用一个计数器,用于记录引用该对象的次数。当引用该对象的个数为0的时候,表示该对象已经没有人可以用了,是垃圾了,就可以回收了。
- 此方法有一个严重的缺陷,当两个对象互相引用,但是又没有外面可以引用它们时,计数器还是为1,不能被垃圾回收。
1.2 可达性分析算法
- 这是JVM采用的算法。
- Java 虚拟机中的垃圾回收器采用可达性分析来探索所有存活的对象
- 扫描堆中的对象,看是否能够沿着 GC Root对象为起点的引用链找到该对象,找不到,表示可以回收
- 而GC Root对象都是不能被垃圾回收的对象,它包括所有的类对象、所有线程的对象、方法内部的局部变量引用的对象、synchronize里面的那个对象等。就相当于顺藤摸瓜找下去,看看能不能找到该对象,如果找不到,说明是可以被垃圾回收的。
- 我们平时使用的引用都是强引用,只要顺着GC Root下去能够找到就不能被垃圾回收。但是,其实还有其他几种引用,在某些特定时候,可以被垃圾回收。
- GC Roots的对象包括以下几种:
- 在虚拟机栈(栈帧中的本地变量表)中引用的对象。譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等
- 在方法区中类静态属性引用的对象。譬如Java类的引用类型静态变量。(static)
- 在方法区中常量引用的对象,譬如字符串常量池里的引用(final)
- 在本地方法栈中JNI(也就是本地方法)引用的对象
- Java虚拟机内部的引用,如基本数据类型对应的Class对象,一些常驻的异常对象(NullPointException)等,还有类加载器
- 所有被同步锁(synchronized关键字)持有的对象
- 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等
1.3 四种引用
- 强引用:就是普通的引用。当无法沿着GC Root找到它的时候,它就可以被垃圾回收了。
- 软引用(Soft Reference):垃圾回收后,如果内存仍然不足,就会再次触发垃圾回收,将软引用的对象进行垃圾回收。可以配合引用队列释放软引用本身。
- 弱引用(Weak Reference):当垃圾回收后,会直接被垃圾回收。可以配合引用队列释放弱引用本身。
- 虚引用(Phantom Reference):此方法和直接内存打交道。当垃圾回收时,引用对象
ByteBuffer会被垃圾回收,但是直接内存是不可以垃圾回收的。这个时候,虚引用会进入引用队列,由 Reference Handler 线程调用虚引用相关方法释放直接内存
1.3.1 软引用案例
- 在List中先加入软引用,在软引用中加入内容。当将最大堆内存调成10m的时候。在list中加入第三个对象时,由于内存不足,就执行垃圾回收了,然后将前两个对象全垃圾回收了,只剩下最后一个对象。
-Xmx12m -XX:+PrintGCDetailspublic class ReferenceDemo { public static final Integer _4MB = 1024 * 1024 * 4; @Test public void testSoftReference() { List<SoftReference<byte[]>> list = new ArrayList<>(); list.add(new SoftReference<>(new byte[_4MB])); list.add(new SoftReference<>(new byte[_4MB])); list.add(new SoftReference<>(new byte[_4MB])); for (SoftReference<byte[]> softReference : list) { System.out.println(softReference.get()); } } }
1.3.2 使用引用队列改造
public class ReferenceDemo {
public static final Integer _4MB = 1024 * 1024 * 4;
@Test
public void testSoftReference() {
ReferenceQueue<byte[]> queue = new ReferenceQueue<>(); // 引用队列,当软引用被垃圾回收之后,该软引用就会进入引用队列
List<SoftReference<byte[]>> list = new ArrayList<>();
list.add(new SoftReference<>(new byte[_4MB], queue));
list.add(new SoftReference<>(new byte[_4MB], queue));
list.add(new SoftReference<>(new byte[_4MB], queue));
// 这个时候就是取出引用队列中所有的引用,因为它们既然已经进入队列,说明被引用的对象已经被垃圾回收了,因此这个引用也可以在列表中删除了
Reference<? extends byte[]> reference = queue.poll();
while (reference != null) {
list.remove(reference);
reference = queue.poll();
}
for (SoftReference<byte[]> softReference : list) {
System.out.println(softReference.get());
}
}
}
- 弱引用与软引用的用法一致,在此就不再赘述。弱引用使用
WeakReference - 软引用可以做一些简易的缓存,当内存空间充足的情况下保留,在内存空间不足的情况下就清理。
- 虚引用必须结合引用队列使用,且不能通过
get方法取出对象。虚引用唯一的作用,就是可以在这个对象被回收的时候等到一个系统通知。
2. 垃圾回收算法
- 一共有几种垃圾回收的算法:复制算法、标记清除算法、标记压缩算法。
2.1 复制算法(Copying)
- 简单来说,就是将一个区域内(From),无需被垃圾回收的对象复制到另一个区域中(To),原来的区域(From)的内容全部清空。
- 该算法适用于幸存率较低,垃圾回收率较高的区域,常用于新生区。
- 缺点:
- 浪费了一半内存。
- 如果对象存活率高,需要把所有对象复制一遍,引用地址全部重置一遍。非常麻烦。
2.2 标记清除算法(Mark-Sweep)
- 简单来说,就是将没有被引用的对象标记为可以被垃圾回收,当垃圾回收的时候,直接把那一份内存清除掉即可。
- 一般,老年区采用这种算法与标记整理算法相结合的办法。
- 优点:快,省事
- 缺点:
- 标记和清除两个过程的执行效率都随对象数量增长而降低
- 内存空间的碎片化
2.3 标记整理算法(Mark-Compact)
- 简单来说,这种方法就是标记所有存活对象,直接将有被引用的对象逐个向同一个方向移动,然后清除边界以外的所有位置。
- 该算法不仅可以弥补标记清除算法中,使得内存碎片化的问题,而且还可以消除复制算法中内存减半的高额代价。
- 缺点:
- 效率不高,不仅要标记所有存活对象,而且还要整理所有存货对象的引用地址。从效率上来说,低于其他两种算法。
- 移动对象需要Stop The World
- 因此,标记清除算法和标记整理算法可以结合起来使用,多次标记清除之后,才使用标记整理。
2.4 分代垃圾回收
- 因此,结合上述的三种垃圾回收算法,就可以得出JVM的垃圾回收算法——分代垃圾回收。
- 老年代采用标记清除算法和标记整理算法结合的方式。平时采用标记清除算法,当碎片化超过一定程度,来一次标记整理。
- 新生代采用以复制算法为核心的垃圾回收算法,具体操作如下:
- 将新生代的内存划分为8:1:1,分别为伊甸园、幸存区From、幸存区To
- 所有的对象都在伊甸园出生。
- 经历第一次垃圾回收之后,伊甸园所有幸存下来的对象以及幸存区所有存活下来的对象,都会复制到幸存区To。复制完之后,伊甸园和幸存区From会清空。完成之后,将幸存区From和幸存区To进行交换。
- 如此反复。此过程就被成为Minor GC
- 当幸存者的年龄达到15岁(默认)时,就会被移动到老年代。
该年龄可以通过参数进行修改
-XX:MaxTenuringThreshold
- 当Minor GC之后,伊甸园、幸存区还是内存不足,就会触发Full GC,也就是老年代的垃圾回收机制。此过程相较于新生代的垃圾回收,会久一点。
- 当Full GC之后,还是内存不足,就会触发OOM,也就是OutOfMemoryError。
3、经典垃圾收集器
- 经典的垃圾收集器分为七种,其中有上面三款垃圾收集器是用于新生代工作的,下面三款是用于老年代工作的。G1这一款比较特别,新生代老年代一起处理。
- 新生代和老年代的垃圾收集器需要配合着使用,连接即表示它们可以组合使用。其中中间标识Java9的表示Java9之后就不支持一起使用了。
- 值得一提的是,虽然这里有七种垃圾收集器,但新生代和老年代之间其实有非常类似的垃圾收集器。
- 比如说,新生代的
Serial和老年代的Serial Old相对应;新生代的Parallel Scavenge和老年代的Parallel Old相对应。 - 新生代的垃圾收集器之间,也有很多相似的地方,比如说
Serial和ParNew实际上机制很类似,只是一个使用单线程,另一个使用多线程。
3.1 Serial 收集器
- 这是新生代的垃圾收集器。它是单线程的。
- 它在工作的时候,需要暂停其他所有工作线程(Stop The World),直到它收集结束。
- 因为是新生代,所以毫无疑问,它是标记复制算法的。
3.2 ParNew 收集器
- 实质上就是Serial收集器的多线程并行版本。
3.3 Parallel Scavenge 收集器
- 与ParNew很相似,是基于标记-复制算法实现的,也是能够并行收集的多线程收集器。
- 特别的是,它是一个吞吐量优先的收集器需要严格控制用户运行代码的时间与处理器总消耗时间的比值。
- 可以通过控制最大垃圾收集停顿时间
-XX:MaxGCPauseMillis参数,垃圾收集器会自动调整新生代的大小以及或者吞吐量大小+XX:GCTimeRatio。反之,也可以通过设置吞吐量大小,自动调整最大垃圾收集停顿时间以及新生代的大小。 - 自适应调整策略也是Parallel Scavenge收集器区别于ParNew收集器的一个重要特性。
3.4 Serial Old 收集器
- Serial Old是Serial收集器的老年代版本。同样是单线程收集器,使用标记整理算法。
- 有两种用途,与Parallel Scavenge收集器搭配使用;在CMS收集器发生失败时,作为后备预案。
- 运行示意图,可看上面Serial的。
3.5 Parallel Old 收集器
- Parallel Old是Parallel Scavenge收集器的老年代版本。支持多线程并行收集,基于标记-整理算法。
- 出现的目的,就是为了与Parallel Scavenge做配合。之前只有
Serial Old与它配合。
3.6 CMS 收集器
- CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。(响应时间优先)
- 它是一个老年代的垃圾收集器。它是标记-清除算法实现的。
- 为了实现功能,这个垃圾收集器将过程分为四个步骤
- 初始标记(CMS initial mark):需要STW,标记所有GC Roots能直接关联到的对象。
- 并发标记(CMS concurrent mark):从GC Roots的直接关联对象开始遍历整个对象图的过程,不需要STW
- 重新标记(CMS remark):重新标记阶段则是为了修正并发标记期间,因用户程序继续运行而导致标记产生变动的那一部分的标记记录。需要STW
- 并发清除(CMS concurrent sweep):清理删除掉标记阶段判断的已经死亡的对象,可以并发。
- 缺点:
- 占用一部分线程,导致应用程序变慢,降低吞吐量
- 在垃圾收集过程中,用户线程还是会运行,有风险会在这期间因内存无法满足程序分配新对象的需要而导致并发失败。因此需要预留一部分空间,提前激活垃圾回收。且在实在没办法的情况下,临时启用Serial Old收集器来重新进行老年代的垃圾收集。
- 这是一个标记-清除算法,因此可能会导致空间碎片化。必要时需要Full GC进行处理。
3.7 G1收集器
- G1,收集垃圾的逻辑不再是它属于哪个分代,而是哪块内存中存放的垃圾数量最多,回收效益最大,这就是G1收集器的Mixed GC模式。
- G1将堆划分为多个大小相等的独立区域(Region),每一个Region都可以根据需要,扮演新生代的Eden空间、Survivor空间,或者老年代的空间。
- Region还有一类特殊的区域:Humongous区域,专门用来存储大对象。只要对象大小超过Region的一半,就可以认为是大对象。超大对象,也可以通过连续的多个Region存放。这些大对象通常会被当作老年代来看待。
- G1回收的思路是,看各个Region里面的垃圾堆积的“价值”大小,即回收所获得的空间大小以及回收所需要的经验值,然后在后台维护一个优先级列表,每次根据用户提供的收集停顿时间,优先处理回收价值大的。
- G1垃圾收集分为以下四个步骤:
- 初始标记(Initial Marking):仅仅标记GC Roots能直接关联到的对象,并且修改TAMS指针的值,让下一阶段用户线程并发运行时,能正确地在可用的Region中分配新的对象。
- 并发标记(Concurrent Marking):对堆中对象进行可达性分析。并且在扫描完之后,根据之前的快照SATB,处理一下在这个过程中的变动。
- 最终标记(Final Marking):对用户线程做另一个短暂的暂停,处理并发阶段结束后那少量的SATB记录。
- 筛选回收(Live Data Counting and Evacuation):更新Region的统计数据,对价值进行排序,选出需要被回收的回收集,并且将它们存活下来的对象移动到另一个空的Region
- G1的设计导向,与之前的收集器不一样,之前的思路是一次性清理干净,而G1的思路是追求能够应付应用的内存分配速率,而不追求一次把整个Java堆全部清理干净。只要收集的速度跟得上对象分配的速度,那就一切很完美了。