JVM 垃圾回收
文章目录
- 1 堆空间的基本结构
- 2 内存分配和回收
-
- 2.1 对象首先在Eden区分配
- .2.2 空间分配担保
- 3 死亡对象判断方法
-
- 3.1 引用计数法：
- 3.2 可达性分析算法
- 3.3 引用类型总结
- 3.4 如何判断一个类是无用的类
- 4 垃圾收集算法
-
- 4.1 标记-清除算法
- 4.2 标记-复制算法
- 4.3 标记-整理算法
- 4.4 分代收集算法
- 5 垃圾收集器
-
- 5.1 Serial收集器
- 5.2 ParNew收集器
- 5.3 Parallel Scavenge收集器
- 5.4 Serial Old 收集器
- 5.5 Parallel Old 收集器
- 5.6 CMS 收集器
- 5.7 G1收集器
- 问题总结
1 堆空间的基本结构
Java 堆是垃圾收集器管理的主要区域，因此也被称作 GC 堆（Garbage Collected Heap）。
从垃圾回收的角度来说，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆被划分为了几个不同的区域，这样我们就可以根据各个区域的特点选择合适的垃圾收集算法。
JDK8堆内存被分为新生代内存和老生代内存
JDK 8 版本之后 PermGen(永久) 已被 Metaspace(元空间) 取代，元空间使用的是直接内存 。
2 内存分配和回收
2.1 对象首先在Eden区分配
对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC
当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC，GC期间尝试将对象放入Surviver空间，若空间仍然不够，就会通过分配担保机制把新生代的对象提前转移到老生代。若老生代的空间足够存放该对象，就不会出现Full GC
进入老生代的对象：
- 大对象直接进入老生代
- 长期存活的对象将进入老生代：既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。 对象在Eden区初始化时Age计数器分配为0，每经过一次Minor GC，Age+1。当对象达到晋升到老年代的年龄阈值，就会晋升到老年代。
Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的 50% 时（默认值是 50%，可以通过 -XX:TargetSurvivorRatio=percent 来设置，参见 issue1199open in new window ），取这个年龄和 MaxTenuringThreshold（默认15）中更小的一个值，作为新的晋升年龄阈值”。
针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种：
- 部分收集 (Partial GC)：
- 新生代收集（Minor GC / Young GC）：只对新生代进行垃圾收集；
- 老年代收集（Major GC / Old GC）：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代全部收集；
- 混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。
- 全部收集（Full GC): 收集整个java堆和方法区
.2.2 空间分配担保
空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间
JDK 6 Update 24 之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。
3 死亡对象判断方法
堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。
3.1 引用计数法：
给对象中添加一个引用计数器：
- 每当有一个地方引用它，计数器就加 1；
- 当引用失效，计数器就减 1；
- 任何时候计数器为 0 的对象就是不可能再被使用的。
- 这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。
所谓对象之间的相互引用问题，如下面代码所示：除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。
public class ReferenceCountingGc {
Object instance = null;
public static void main(String[] args) {
ReferenceCountingGc objA = new ReferenceCountingGc();
ReferenceCountingGc objB = new ReferenceCountingGc();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
}
}
3.2 可达性分析算法
这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。
下图中的 Object 6 ~ Object 10 之间虽有引用关系，但它们到 GC Roots 不可达，因此为需要被回收的对象。
哪些对象可以作为 GC Roots 呢？
- 虚拟机栈(栈帧中的本地变量表)中引用的对象
- 本地方法栈(Native 方法)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 所有被同步锁持有的对象
对象可以被回收，就代表一定会被回收吗？
要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize 方法。当对象没有覆盖 finalize 方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。
被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。
Object 类中的 finalize 方法一直被认为是一个糟糕的设计，成为了 Java 语言的负担，影响了 Java 语言的安全和 GC 的性能。JDK9 版本及后续版本中各个类中的 finalize 方法会被逐渐弃用移除。忘掉它的存在吧！
3.3 引用类型总结
JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）
- 强引用（Strong Reference）：强引用是指程序中普遍存在的引用方式，如果一个对象具有强引用，垃圾回收器就不会回收该对象。只有当该对象不再具有任何强引用时，垃圾回收器才会回收该对象。
- 软引用（Soft Reference）： 软引用是一种相对强引用弱化的引用方式。如果一个对象只有软引用，当系统内存不足时，垃圾回收器可能会回收该对象。 软引用通常用于实现内存敏感的高速缓存系统。
- 弱引用（Weak Reference）：弱引用是比软引用更弱化的引用方式。如果一个对象只有弱引用，当垃圾回收器扫描到该对象时，无论系统内存是否充足，都会回收该对象。 不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
- 虚引用（Phantom Reference）：虚引用是一种最弱化的引用方式，它并不能通过虚引用访问对象。如果一个对象只有虚引用，当垃圾回收器扫描到该对象时，会将该对象加入到ReferenceQueue中，并将该虚引用加入到ReferenceQueue中，以便程序通过ReferenceQueue获取到该对象被回收的信息。虚引用主要用来跟踪对象被垃圾回收的活动。
特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速 JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory） 等问题的产生。
3.4 如何判断一个类是无用的类
判定一个常量是否是“废弃常量”比较简单：如果当前没有任何 对象引用该常量的话就是“废弃常量”。
类需要同时满足下面 3 个条件才能算是 “无用的类” ：
- 类的所有实例已经被回收
- 加载该类的
ClassLoader已经被回收 - 该类对应的
java.lang.class对象没有在任何地方被引用，无法在任何地方通过反射获得该类的方法
4 垃圾收集算法
4.1 标记-清除算法
该算法分为“标记”和“清除”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：
- 效率问题
- 空间问题（标记清除后会产生大量不连续的碎片）
4.2 标记-复制算法
为了解决效率问题，标记-复制算法将内存一分为二，当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
优点：
- 无需考虑内存碎片：由于复制阶段会进行内存压缩，可以消除内存碎片，提高堆内存利用率。
- 可以快速回收垃圾对象：由于只需要复制存活对象，可以快速回收垃圾对象，缩短垃圾回收时间。
- 适用于小内存：标记-复制算法适用于小内存的情况，因为内存较小时，复制时间相对较短，回收效率相对较高。
缺点：
4. 内存利用率较低
5. 无法处理长生命周期的对象：由于存活对象需要复制到新的内存区域中，标记-复制算法无法处理长生命周期的对象，因为长生命周期的对象可能需要经过多次复制才能得到保留，从而影响程序的性能。
4.3 标记-整理算法
根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
它将堆内存分为From Space和To Space两个区域，分为标记、清除和整理三个阶段。
- 标记阶段： 垃圾回收器从根对象开始遍历堆内存中的所有对象，标记可达对象，并将其标记为存活对象。在标记完成后，所有未被标记的对象将被认为是不可达的垃圾对象。
- 清除阶段： 垃圾回收器将所有被标记为垃圾对象的内存空间进行回收。清除完成后，堆内存中会产生大量的内存碎片，可能会导致内存分配效率降低。
- 整理阶段： 垃圾回收器将所有存活的对象移动到堆内存的一端，以便在之后的内存分配中使用。这个过程中，对象的地址可能会发生变化，因此需要更新所有引用对象的地址。整理完成后，To Space区域变为空闲状态，From Space区域变为可用状态。
优点：
- 可以消除内存碎片
- 可以处理长生命周期的对象：标记-整理算法可以处理长生命周期的对象，因为不需要将存活对象复制到新的内存区域中。
缺点：
- 效率较低：标记-整理算法需要扫描整个堆内存，标记可达对象、清除垃圾对象并整理存活对象，效率相对较低。
4.4 分代收集算法
一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
5 垃圾收集器
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
没有最好的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。
5.1 Serial收集器
Serial收集器是一种串行垃圾收集器，它主要用于新生代的垃圾回收。Serial收集器采用标记-复制算法（Mark-Copy Algorithm），将新生代分为一块较大的Eden空间和两块较小的Survivor空间，其中一块Survivor空间为From Space，另一块Survivor空间为To Space。
当Eden空间满时，Serial收集器会进行一次Minor GC，它会将Eden空间和From Space中的存活对象复制到To Space中，并清空Eden空间和From Space。在复制过程中，Serial收集器采用单线程的方式进行垃圾回收，暂停应用程序的所有线程，直到垃圾回收完成为止。
Serial收集器的主要优点是简单、高效，对于单核CPU或小型应用程序来说，表现较好。但是，由于它采用单线程的方式进行垃圾回收，会导致应用程序暂停时间较长，因此不适合用于大型应用程序或需要快速响应的系统。
5.2 ParNew收集器
ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。
它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后面会介绍到）配合工作。
ParNew收集器同样会暂定用户线程
5.3 Parallel Scavenge收集器
这是 JDK1.8 默认收集器
Parallel Scavenge 收集器也是使用标记-复制算法的多线程收集器，它看上去几乎和 ParNew 都一样。 那么它有什么特别之处呢？
Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。
5.4 Serial Old 收集器
Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。
5.5 Parallel Old 收集器
Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
5.6 CMS 收集器
CMS（Concurrent Mark Sweep）是一种并发垃圾收集器，主要用于老年代的垃圾回收。CMS收集器是一种以获取最短回收停顿时间为目的的收集器，注重用户体验。与传统的垃圾收集器不同，CMS采用标记-清除算法（Mark-Sweep Algorithm）对老年代进行垃圾回收，并且在垃圾回收过程中尽可能地减少应用程序的暂停时间，以提高应用程序的响应速度和性能。
流程如下：
- 初始标记（Initial Mark）：该阶段是一次短暂的“Stop-The-World”暂停，用于标记老年代中的所有根节点对象，以确定这些对象和其直接引用的对象是否存活。
- 并发标记（Concurrent Mark）：该阶段是CMS的核心部分，也是并发执行的。在这个阶段中，CMS会遍历老年代中所有的对象，标记出所有存活的对象，并记录这些对象所占用的空间，同时应用程序可以继续运行，不会被暂停。
- 重新标记（Remark）：该阶段是一次短暂的“Stop-The-World”暂停，用于处理在并发标记阶段中有可能发生的并发更新和并发引用等问题，以确保老年代中所有存活的对象都被标记。
- 并发清除（Concurrent Sweep）：该阶段是并发执行的，CMS会扫描老年代中所有的对象，清除所有未被标记的对象，并回收被清除对象所占用的空间。
主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：
- 对 CPU 资源敏感；
- 无法处理浮动垃圾；
- 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。
5.7 G1收集器
G1收集器（Garbage First）是一种面向服务端应用程序的垃圾收集器，于JDK7u4版本中首次发布。G1收集器是一种基于Region的垃圾收集器，其主要特点包括：
- 分代垃圾收集：G1收集器将堆内存分为不同的Region，其中大部分Region被分配给年轻代和老年代。在垃圾回收过程中，G1收集器会优先回收垃圾最多的Region，这也是其名字“Garbage First”的来源。
- 并发垃圾回收：G1收集器支持并发垃圾回收，即在垃圾回收过程中允许应用程序继续运行，以减少垃圾回收对应用程序的影响。
- 按照垃圾回收目标设置回收时间：G1收集器会根据预先设定的垃圾回收目标，在整个堆内存中选择最需要回收的Region，以减少垃圾回收时间和垃圾回收的频率。（可预测的停顿）
- 空间整合：与 CMS 的“标记-清除”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器；从局部上来看是基于“标记-复制”算法实现的。
- 适用于大内存：由于G1收集器采用Region的内存分配方式，因此可以有效地处理大内存的情况。
步骤如下
- 初始标记：与CMS垃圾收集器类似，G1收集器也需要进行一次短暂的“Stop-The-World”暂停，用于标记年轻代和老年代中的所有根节点对象，以确定这些对象和其直接引用的对象是否存活。
- 并发标记：与CMS垃圾收集器类似，G1收集器也采用并发标记算法，用于标记所有存活的对象。
- 最终标记：在并发标记完成后，G1收集器需要进行一次短暂的“Stop-The-World”暂停，用于处理在并发标记阶段中有可能发生的并发更新和并发引用等问题，以确保老年代中所有存活的对象都被标记。
- 空间整理：在标记阶段完成后，G1收集器会根据预设的垃圾回收目标，选择最需要回收的Region，并对这些Region进行垃圾回收和空间整理，以释放空间和减少内存碎片问题。
问题总结
- java8之后为什么使用G1收集器？
- 更好的内存管理：G1收集器是基于Region划分堆内存的，相比CMS等其他收集器，它能够更好地管理内存，有效避免了碎片化问题。
- 更高效的垃圾回收：G1采用了一种全新的垃圾回收算法
- 更低的暂停时间
- 更高的并发性：G1收集器具有更高的并发性，可以在不影响应用性能的情况下完成垃圾回收操作。
- 更好的可预测性：G1收集器能够更好地控制垃圾回收的时间和进度，使得应用程序的性能更加可预测。