判断对象存活方式
引用计数算法
简介
引用计数算法(Reference Counting) ,对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。对于一个对象A,只要有任何一个对象引用了A,则A的引用计数器就加1;当引用失效时,引用计数器就减1。只要对象A的引用计数器的值为0,即表示对象A不可能再被使用,可进行回收。
优点:
实现简单,垃圾对象便于辨识;判定效率高,回收没有延迟性。
缺点:
- 它需要单独的字段存储计数器,这样的做法增加了存储空间的开销。
- 每次赋值都需要更新计数器,伴随着加法和减法操作,这增加了时间开销。
- 引用计数器有一个严重的问题,即无法处理循环引用的情况。
应用场景
具体哪种最优是要看场景的,业界有大规模实践中仅保留引用计数机制,以提高吞吐量的尝试。
Java并没有选择引用计数,是因为其存在一个基本的难题,也就是很难处理循环引用关系。
引用计数算法,是很多语言的资源回收选择,如Python,同时支持引用计数和垃圾收集机制。
Python如何解决循环引用?
手动解除: 就是在合适的时机,解除引用关系。使用弱引用weakref,weakref是Python提供的标准库, 旨在解决循环引用。
可达性分析算法
简介
可达性分析算法是以根对象集合(GC Roots[所谓”GC Roots”根集 合就是一组必须活跃的引用])为起始点,按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。使用可达性分析算法后,内存中的存活对象都会被根对象集合直接或间接连接着,搜索所走过的路径称为**引用链(Reference Chain)**,如果目标对象没有任何引用链相连,则是不可达的,就意味着该对象己经死亡,可以标记为垃圾对象。在可达性分析算法中,只有能够被根对象集合直接或者间接连接的对象才是存活对象。
GC Roots
Java的GC Roots包括以几类元素:
- 虚拟机栈中引用的对象。如:各个线程被调用的方法中使用到的参数、局部变量等。
- 本地方法栈内JNI (通常说的本地方法)引用的对象
- 方法区中类静态属性引用的对象。如: Java类的引用类型静态变量
- 方法区中常量引用的对象。如:字符串常量池(String Table) 里的引用
- 所有被同步锁synchronized持有的对象
- Java虛拟机内部的引用。
- 基本数据类型对应的Class对象,一些常驻的异常对象(如:NullPointerException、OutOfMemoryError),系统类加载器。
- 反映java虛拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
- 在分代收集和局部回收时,GC Roots集临时性的加入其他对象,比如针对新生代回收,老年代的对象也要纳入GC Roots集中。
注意
如果要使用可达性分析算法来判断内存是否可回收,那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。这点也是导致GC进行时必须“StopTheWorld”的一个重要原因。即使是号称(几乎)不会发生停顿的CMS收集器中,枚举根节点时也是必须要停顿的。
对象的finalization机制
Java语言提供了对象终止(finalization) 机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。
当垃圾回收器发现没有引用指向一个对象,即:垃圾回收此对象之前,总会先调用这个对象的finalize()方法。.
finalize ()方法允许在子类中被重写,用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作,比如关闭文件、套接字和数据库连接等。
不重写finalize()方法的原因
- 在finalize()时可能会导致对象复活。
- finalize()方法的执行时间是没有保障的,它完全由GC线程决定。
- 若不发生GC,则finalize ()方法将没有执行机会。
- 一个糟糕的finalize()会严重影响GC的性能。
虚拟机中Java对象的三种状态
- 可触及的:从根节点开始,可以到达这个对象。
- 可复活的:对象的所有引用都被释放,但是对象有可能在finalize()中复活。
- 不可触及的:对象的finalize()被调用,并且没有复活,那么就会进入不可触及状态。不可触及 的对象不可能被复活,因为finalize()只会被调用一次。
判定一个对象是否可回收,至少要经历两次标记过程:
如果对象到GC Roots没有 引用链,则进行第一次标记。
进行筛选,判断此对象是否有必要执行finalize()方法
① 如果对象没有 重写finalize()方法,或者finalize ()方法已经被虚拟机调用过,则虚拟机视为“没有必要执行”,被判定为不可触及的。
② 如果对象重写 了finalize()方法,且还未执行过,那么该对象会被插入到E-Queue队列中,由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize ()方法执行。
③ finalize()方法是对象逃脱死亡的最后机会,稍后GC会对E-Queue队列中的对象进行第二次标记。如果对象在finalize()方法中与引用链上的任何一个对象建立了联系,那么在第二次标记时,对象会被移出“即将回收”集合。之后,对象会再次出现没有引用存在的情况。在这个情况下,finalize方法不会被再次调用,对象会直接变成不可触及的状态,也就是说,一个对象的finalize方法只会被调用一次。
垃圾清除
标记 - 清除算法( Mark-Sweep)
核心
当堆中的有效内存空间(available memory)被耗尽的时候,就会停止整个程序(也被称为stop the world) ,然后进行两项工作,第一项则是标记,第二项则是清除。
标记: Collector从引用 根节点开始遍历,标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
清除:Collector对堆 内存从头到尾进行线性的遍历,如果发现某个对象在其Header中没有标记为可达对象,则将其回收。
缺点
- 效率不算高。
- 在进行GC的时候,需要停止整个应用程序,导致用户体验差。
- 这种方式清理出来的空闲内存是不连续的,产生内存碎片。需要维护一个空闲列表。
复制算法(Copying)
将活着的内存空间分为两块,每次只使用其中一块,在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中,之后清除正在使用的内存块中的所有对象,交换两个内存的角色,最后完成垃圾回收。
优点:
- 没有标记和清除过程,实现简单,运行高效。
- 复制过去以后保证空间的连续性,不会出现“碎片”问题。
缺点:
- 此算法的缺点也是很明显的,就是需要两倍的内存空间。
- 对于G1这种分拆成为大量region的GC,复制而不是移动,意味着GC需要维护region之间对象引用关系,不管是内存占用或者时间开销也不小。
特别的:
- 如果系统中的垃圾对象很多,复制算法需要复制的存活对象数量并不会太大,或者说非常低才行。
- 即特别适合垃圾对象很多,存活对象很少的场景;例如:Young区的Survivor0和Survivor1区
标记 - 压缩算法(Mark-Compact )
第一阶段和标记清除算法- -样,从根节点开始标记所有被引用对象,第二阶段将所有的存活对象压缩到内存的一端,按顺序排放。
之后,清理边界外所有的空间。
优点:
- 消除了标记-清除算法当中,内存区域分散的缺点,我们需要给新对象分配内存时,JVM只 需要持有一个内存的起始地址即可。
- 消除了复制算法当中,内存减半的高额代价。
缺点:
- 从效率上来说,标记-整理算法要低于复制算法。
- 移动对象的同时,如果对象被其他对象引用,则还需要调整引用的地址。
- 移动过程中,需要全程暂停用户应用程序。即: STW。
分代收集算法
不同的对象的生命周期是不一样的。因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率。一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点使用不同的回收算法,以提高垃圾回收的效率。目前几乎所有的GC都是采用分代收集(Generational Collecting) 算法执行垃圾回收的。
年轻代(Young Gen)
算法:复制算法。
特点:区域相对老年代较小,对象生命周期短、存活率低,回收频繁。
速度最快。效率只和当前存活对象大小有关,而复制算法内存利用率不高的问题,通过hotspot中的两个survivor的设计得到缓解。
老年代(Tenured Gen)
算法:一般是由标记-清除或者是标记-清除与标记-整理的混合实现。
特点:区域较大,对象生命周期长、存活率高,回收不及年轻代频繁
各阶段开销
Mark(标记)阶段的开销与存活对象的数量成正比。
Sweep(清除)阶段的开销与所管理区域的大小成正相关。
Compact(压缩/整理)阶段的开销与存活对象的数据成正比。
增量收集算法
垃圾收集线程只收集一小片区域的内存空间,接着切换到应用程序线程。依次反复,直到垃圾收集完成。降低系统停顿时间,但线程切换和上下文转换消耗,导致垃圾回收成本增加。总的来说,增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理,允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。
分区算法
为了更好地控制GC产生的停顿时间,将一块大的内存区 域分割成多个小块,根据目标的停顿时间,每次合理地回收若千个小区间,而不是整个堆空间,从而减少一 次GC所产生的停顿。分代算法将按照对象的生命周期长短划分成两个部分,分区算法将整个堆空间划分成
连续的不同小区间。每一个小区间都独立使用,独立回收。这种算法的好处是可以控制一次回收多少个小区间。