关于JVM的垃圾收集(三)

对象可触及时的生命周期

在 JVM 1.2 之前,堆中的对象分为三种状态,分别是:

1.可触及的 -- 从根节点开始可追踪到

2.可复活的 -- 从根节点开始追踪不到,但有可能被终结方法触及并复活。不仅仅是那些声明了 finalize() 方法的对象,而是所有的对象都要经过可复活状态

3.不可触及的 -- 以上两种可能性都不存在,可以真正回收它们所占据的内存了

版本 1.2 中,可触及按强弱进一步细分为:

1.强可触及 -- 即原来的可触及,从根节点开始的任何直接引用,如一个局部变量或任何从强可触及对象的实例引用的对象

2.软可触及 -- 表现为 SoftReference 所引用的对象

3.弱可触及 -- 表现为 WeakReference 所引用的对象

4.影子可触及 -- 表现为 PhantomReference 所引用的对象

SoftReference、WeakReference、PhantomReference 都是 java.lang.ref.Reference 类的子类。强引用与这三种弱引用之间最基本的差别是,强引用禁止引用目标被垃圾收集,而那三种引用不禁止。

要创建某一对象的软引用、弱引用或是影子引用,只需简单的包装一下。例如,创建一个 cow 对象的软用就写成:

SoftReference softCow = new SoftReference(cow);  //对于 WeakReference 和 PhantomReference 都是一样的

这里 softCow 是一个强引用,从 softCow 到 cow 是一个软引用,也就预示着垃圾收集器从根节点开始只能通过一个软引用才能触及到这个 cow 对象。要切断到 cow 的软引用,使之不再软可触及,可调用 softCow.clear(),要获取 cow 对象用 softCow.get()。

可触及性状态的变化

引入三个这样的引用对于虚拟机是有用处的,垃圾收集器对强引用对象是不能肆意妄为,但是它可随意更改百强可触及对象的可触性状态。在软引用、弱引用或者影子引用指向对象的可触及状态被垃圾收集器改变时,你可以获得这变化发生的通知,方法是要把引用对象和引用队列关联起来。

引用队列是 java.lang.ref.ReferenceQueue 类的实例,垃圾收集器在改变可触及性状态时会把所涉及的引用对象编入到队列中。你只要设置并观察引用队列,便可异步得到通知了。

时间: 2024-11-03 07:27:37

关于JVM的垃圾收集(三)的相关文章

关于JVM的垃圾收集(二)

自适应收集器 在第一篇:关于JVM 的垃圾收集(一)中谈到过几种垃圾收集的算法,然而我们的 JVM 启动之后并不要求彻头彻尾的死板的使用一种垃圾收集算法,固定的算法参数.因为某种情况下某些垃圾收集算法工作得更好,而别外一些收集算法在另外的情况下工作得更好,所以自适应的垃圾收集技术应运而生.自适应算法监视堆中的情形,并且对应的调整为合适的垃圾收集技术.或能是换一种垃圾收集算法,或者是调整当前算法参数,或者把堆划分为子堆,同时在不同的子堆中使用不同的算法. 简述火车算法 垃圾收集一般都会停止整个程序

[jjzhu学java]之深入理解JVM之垃圾收集器与内存分配策略

深入理解JVM之垃圾收集器与内存分配策略 如何判断对象已经消亡 引用计数算法 根搜索算法 引用 深入理解JVM之垃圾收集器与内存分配策略 java中对象的创建需要的内存都是在java堆中申请的,所以垃圾收集的区域就是对java堆和方法区的内存区域进行GC. 如何判断对象已经消亡 垃圾收集器的主要任务就是找出已经"消亡"的对象,将其标记并清除其说用内存的过程,如何判断某个对象已经"消亡",不同的虚拟机有不同的判断策略 引用计数算法 引用计数(Reference Cou

关于JVM的垃圾收集(一)

Java 中使用 new.newarray.anewarray 和 multianewarray 指令来创建的对象,当这些对象不再使用时由垃圾收集来释放.那么 反序列化等都是间接使用了前面的某个指令, clone() 是个本地方法? JVM 规范不需要任何特定的垃圾收集技术,甚至也没要求有垃圾收集机制.大概只是说不需要手工释放内存,具体怎么实现各 JVM 自行决定. GC 除了释放不再被引用的对象,还要处理堆碎片,整理出连续的空闲空间才能放得下新的对象.不至于出现总的空闲空间足够,但碎片太多而报

JVM性能优化(三):垃圾收集

原文地址,译文地址,译者:Greenster Java平台的垃圾收集机制显著提高了开发者的效率,但是一个实现糟糕的垃圾收集器可能过多地消耗应用程序的资源.在Java虚拟机性能优化系列的第三部分,Eva Andreasson向Java初学者介绍了Java平台的内存模型和垃圾收集机制.她解释了为什么碎片化(而不是垃圾收集)是Java应用程序性能的主要问题所在,以及为什么分代垃圾收集和压缩是目前处理Java应用程序碎片化的主要办法(但不是最有新意的). 垃圾收集(GC)的目的是释放那些不再被任何活动对

jvm 垃圾回收 分代-JVM垃圾回收关于New Generation为什么分为三个区域的疑问

问题描述 JVM垃圾回收关于New Generation为什么分为三个区域的疑问 最近打算写一个分代垃圾回收,我打算在New Generation中分为两个区域,即只有 from区域 跟 to区域,但是最近查看了好多关于JVM的分代垃圾机制的文章,JVM在New Generation中分为三个区域,即Eden.from.to三个区域,好多文章介绍Eden都是该区域是一整块连续的堆,加速了分配的速度,但是我想问的是,如果只分为两个区域,每次从from拷贝到to后,to区域剩下的空间也是连续的,分配

JVM分代垃圾回收机制关于New Generation为什么分为三个区域的疑问

问题描述 最近打算写一个分代垃圾回收,我打算在NewGeneration中分为两个区域,即只有from区域跟to区域,但是最近查看了好多关于JVM的分代垃圾机制的文章,JVM在NewGeneration中分为三个区域,即Eden.from.to三个区域,好多文章介绍Eden都是该区域是一整块连续的堆,加速了分配的速度,但是我想问的是,如果只分为两个区域,每次从from拷贝到to后,to区域剩下的空间也是连续的,分配速度应该也是很快的,这点让我很迷惑,为什么JVM要分为三个区域.所以,我想问一下我

JVM调优总结(七)-典型配置举例1

以下配置主要针对分代垃圾回收算法而言. 堆大小设置 年轻代的设置很关键 JVM中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制:系统的可用虚拟内存限制:系统的可用物理内存 限制.32位系统下,一般限制在1.5G~2G:64为操作系统对内存无限制.在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最 大可设置为1478m. 典型设置: java -Xmx3550m -Xms3550m -Xmn2g –Xss128k -Xmx35

JVM调优总结

一.堆大小设置 JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制:系统的可用虚拟内存限制:系统的可用物理内存限制.32位系统下,一般限制在1.5G~2G:64为操作系统对内存无限制.我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m.典型设置: java -Xmx3550m-Xms3550m -Xmn2g -Xss128k -Xmx3550m:设置JVM最大可用内存为3550M. -Xms355

JVM 基础知识(GC)

几年前写过一篇关于JVM调优的文章,前段时间拿出来看了看,又添加了一些东西.突然发现,基础真的很重要.学习的过程是一个由表及里,再由里及表的过程,所谓的"温故而知新".而真正能走完这个轮回的人,也就能称为大牛或专家了.这个过程可能来来回回,这就是所谓"螺旋上升",而每一次轮回都有新的发现.   这回添加的东西主要集中在基础的一些问题上,还有一些这两年思考的问题.这些问题可能平时我们不会刻意去想,但是真正看清楚了,却发现还是大有裨益的,希望对大家都有帮助~ 一.基础概