Java虚拟机（5）对象存活及引用&垃圾回收方法

对象的存活与死亡

堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”。

如何确定对象是否存活？

从如何判定对象消亡的角度出发，垃圾收集算法可分为“引用计数式垃圾收集”（Reference Counting GC）和“追踪式垃圾收集”（Tracing GC），也常被称作“直接垃圾收集”和“间接垃圾收集”。

1、引用计数法

定义：在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

缺陷：单纯的引用计数就很难解决对象之间相互循环引用的问题

2、可达性分析算法

定义：通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，即从GC Roots到这个对象不可达，则证明此对象是不可能再被使用的。

可达性分析算法.png

在Java技术体系里面，固定可作为GC Roots的对象包括以下几种：

• 在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。

• 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。

• 在方法区中常量引用的对象，譬如字符串常量池（StringTable）里的引用。

• 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。

• Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。

• 所有被同步锁（synchronized关键字）持有的对象。

• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

对象引用

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象是否引用链可达，判定对象是否存活都和”引用”离不开关系。

引用关系可分为以下几个大类：

• 强引用

  普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。只要强引用关系存在，垃圾收集器就永远不会回收掉被引用的对象。

• 软引用

  一些还有用，但非必须的对象。发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，回收后还没有足够的内存，才会抛出内存溢出异常。 SoftReference类实现。

• 弱引用

  非必须对象，强度比软引用更弱一些，只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会被回收掉。 WeakReference类实现。

• 虚引用

  最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。唯一目的是在这个对象被收集器回收时收到一个系统通知。PhantomReference类实现。

对象死亡过程

要真正宣告一个对象死亡，至少要经历两次标记过程：

1、第一次标记、筛选

对象可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记；

筛选：判断对象是否有必要执行finalize()方法。

• 有必要执行：对象将会被放置F-Queue的队列，由虚拟机自动建立的、低调度优先级的Finalizer线程去执行finalize()方法；
• 没必要执行：对象死亡，等待回收。

对象没有finalize()方法，或finalize()方法已被调用过，视为“没有必要执行”。

2、第二次标记、筛选

收集器将对F-Queue中的对象进行第二次标记；

• 对象要在finalize()中——重新与引用链上的任何一个对象建立关联，如把自己（this关键字）赋值给某个类变量或者对象的成员变量，在第二次标记时它将被移出“即将回收”的集合；
• 没有建立关联，对象死亡，等待回收。

finalize()能做的所有工作，使用try-finally或者其他方式都可以做得更好、更及时，不建议使用这个方法。

回收方法区

方法区的垃圾收集主要包括：废弃的常量和不再使用的类型。

废弃常量：没有任何字符串对象引用常量池中的常量，且虚拟机中也没有地方引用这个字面量。

不再被使用的类，需要同时满足三个条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例；

• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的；

• 类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

垃圾回收算法

从如何判定对象消亡的角度出发，垃圾收集算法可以划分为“引用计数式垃圾收集”（Reference Counting GC）和“追踪式垃圾收集”（Tracing GC）两大类，这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。引用计数式垃圾收集算法主流Java虚拟机中未涉及，以下介绍的所有算法均属于追踪式垃圾收集的范畴。

分代手机理论

两个分代假说：

1、弱分代假说：绝大多数对象都是朝生夕灭的。

2、强分代假说：熬过越多次垃圾手机过程的对象越难以消亡。

垃圾收集器设计原则：

将Java堆划分出不同的区域，将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。

具体到商用Java虚拟机里，设计者一般至少会把Java堆划分为新生代（Young Generation）和老年代（Old Generation）两个区域。在新生代中，每次垃圾收集时都有大批对象死去，每次回收后存活的少量对象，将会逐步晋升到老年代中存放

3、跨代引用假说：跨代引用相对于同代引用来说仅占少数。

根据前两条假说逻辑推理得出的隐含推论：存在互相引用关系的两个对象，应该倾向于同时生存或者同时消亡。

垃圾回收算法

1、标记清除算法

最基础的收集算法

标记出所有需要回收的对象，标记完成后，统一回收掉所有被标记的对象；也可反过来，标记存活的对象，统一回收所有未被标记的对象。

标记-清除算法.png

缺陷

• 执行效率不稳定：如果Java堆中包含大量对象，且其中大部分是要被回收的，就必须进行大量标记和清除的动作，执行效率都随对象数量增长而降低；
• 内存空间的碎片化问题：标记、清除之后会产生大量不连续的内存碎片，空间碎片太多会导致当需要分配较大对象时，无法找到足够的连续内存，不得不提前触发另一次垃圾收集。

2、标记-复制算法

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优势

多数对象都是可回收的情况，复制的就是占少数的存活对象，每次都是针对整个半区进行内存回收，分配内存时不用考虑有空间碎片的复杂情况，只需移动堆顶指针，按顺序分配。

缺点

• 内存中多数对象都是存活时，将会产生大量的内存间复制的开销；
• 而且将可用内存缩小为了原来的一半，空间浪费。

标记-复制算法.png

使用场景

适用于对象存活率较低，需要频繁进行垃圾回收的区域。

HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局。

3、标记-整理算法

标记过程仍然与“标记-清除”算法一样，但后续不是直接对可回收对象进行清理，而是所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

标记-整理算法.png

使用场景

适用于对象存活率较低，垃圾回收行为频率低的场景。

HotSpot虚拟机里面关注吞吐量的Parallel Scavenge收集器是基于标记-整理算法的，而关注延迟的CMS收集器则是基于标记-清除算法。

4、分代收集算法

针对不同的年代进行不同算法的垃圾回收，针对新生代选择复制算法，对老年代选择标记整理算法。

以上就是java虚拟机对象存活、引用及垃圾回收方法垃圾回收的全部内容了，总结如下：

对象的存活、引用及垃圾回收.png

欢迎点赞/评论，你们的赞同和鼓励是我写作的最大动力！