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

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

posted @ 2020-11-04 16:03  几圈年轮  阅读(165)  评论(0编辑  收藏  举报