java垃圾回收期如何工作(编程思想)

时间:2023-12-16 09:13:32

垃圾回收器如何工作:
在以前的程序语言中,在堆上分配对象的代价十分昂贵,因此读者会自然觉得对Java中所有对象(基本类型除外)都在堆上分配的方式也非常高昂。然而,垃圾回收期对提高对象的创建速度,却具有明显的效果。
打个比方,你可以吧C++里面的堆想象成一个院子,里面的每个对象都负责管理自己的地盘。一段时间之后,对象可能被销毁,但地盘必须加以重用。在某些Java虚拟机中,堆的实现截然不同:它更像一个传送带,每分配一个对象,它就往前移动一格。这意味着对象存储空间的分配速度非常快。Java的“堆指针”只是简单地移动到尚未分配的区域,其效率比得上C++在堆栈上分配空间的效率。
java中的堆并非完全像传送带那样工作。要是真的那样的恶化,势必会导致频繁的内存页面调度————将其移进移出硬盘,因此会显得需要拥有比实际需要更多的内存。页面调度会显著地影响性能,最终,在创建了足够多的翠香之后,内存资源将耗尽。其中的秘密在于垃圾回收器的介入。当它工作时,将一面回收空间,一面使堆中的对象紧凑排列,这样“堆”指针就可以很容易移动到更靠近传送带的开始处,也就避免了页面错误。通过垃圾回收器对对象重新排序,实现了一种高速的、有无限空间可供分配的堆模型。
想要更好地理解Java中的垃圾回收,可以了解一下其他系统中的垃圾回收机制。引用计数器是一种简单但速度很慢的垃圾回收技术。每个对象都含有一个引用计数器,让有引用连接至对象时,引用技术加1.当对象离开作用域或被置为null时,引用计数器减少。虽然管理引用技术的开销不大,但这项开销在整个程序生命周期中持续发生。垃圾回收期会在含有全部对象的列表上遍历,当发现某个对象的引用计数为0时,就释放其占用的空间(但是,引用计数模式经常会在计数值变成0时立即释放对象)。这种方法有个缺陷,如果对象之间存在循环引用,可能出现“对象应该被回收,但引用计数却不为零”的情况。对于垃圾回收器而言,定位这样的交互自引用的对象组所需的工作量极大。引用计数常用来说明垃圾收集的工作方式,但似乎从未被应用于任何一种Java虚拟机实现中。
在一些更快的模式中,垃圾回收期并非基于引用计数技术。它们依据的思想是:对任何“活”的对象,一定能最终追溯到其存货在堆栈或静态存储区之中的引用。这个引用链条可能会穿过数个对象层次。由此,如果从堆栈和静态存储区开始,遍历所有的引用,就能找到所有“活"的对象。对于发现的每个引用,必须追踪它锁引用的对象,然后是此对象包含的而所有引用,如此反复进行,知道“根源于堆栈和静态存储区的引用”形成的网络全部被访问为止。你所访问过的对象必须都是“活”的。注意,这就解决了“交互自引用的对象组”的问题————这种现象根本不会被发现,因此也就被自动回收了。
在这种方式下,Java虚拟机将采用一种自适应的垃圾回收技术。置于如何找到的存活对象,取决于不同的java虚拟机实现。有一种做法名为停止——赋值(stop and copy)。显然意味着,先暂停程序的运行(所以它不属于后台回收模式),然后将所有存活的对象从当前堆赋值到另一个堆,没有被赋值的全部都是垃圾,当对象被赋值到新堆时,它们是一个挨着一个的,所以新堆保持紧凑排列,然后就可以按前述方法简单、直接地分配新空间了。
当把对象从一处搬到另一处时,所有指向它的那些引用都必须修正。位于堆或者静态存储区的引用可以直接被修正,但可能还有其他指向这些对象的引用,它们在遍历的过程中才能被找到(可以想象成有个表格,讲话旧地址映射至新地址)
对于这种所谓的复制式回收器而言,效率会降低,这有两个原因。首先,得有两个堆,然后得在这两个分离的堆之间来回捣腾,从而得维护比实际需要多1倍的空间。某些Java虚拟机对此问题的处理方式是,按需从堆中分配几块较大的内存,复制动作发生在这些大块内存之间。
第二个问题在于复制。程序进入稳定状态之后,可能只会产生少量垃圾,甚至没有垃圾,尽管如此,复制式回收器仍然会将所有内存自一处复制到另一处,这很浪费。为了避免这种情形,一些java虚拟机会进行检查:要是没有新垃圾产生,就会转换到另一种工作模式(即“自适应”)。对一般用途而言,“标记——清扫”方式速度相当慢,但是当你知道只会产生少量垃圾甚至不会产生垃圾时,它的速度就很快了。
“标记——清扫”锁依据的思路同样是从堆栈和静态存储区出发,遍历所有的引用,从而找出所有存活的对象。每当它找到一个存活对象,就会给对象设一个标记,这个过程中不会回收任何对象。只有全部标记工作完成时,清理工作才会开始。在清理过程中,没有标记的对象将被释放,不会发生任何复制操作。所以剩下的堆空间是不连续的,垃圾回收器要是希望得到连续空间的话,就得重新整理剩下的对象。
“停止——复制”的意思是这种垃圾回收动作不是在后台进行的;相反,垃圾回收器动作发生的同事,程序将会被暂停。在Sun公司的文档中会发现,许多参考文档将垃圾回收视为低优先级的后台进程,但实际上垃圾回收器在Sun公司早期版本的java虚拟机中并非以这种方式实现的。当可用内存数量较低的时,Sun版本的垃圾回收器会暂停运行程序,同样,“标记-清扫”工作也必须在程序暂停的情况下才能进行。
如上文所述,在这里所讨论的Java虚拟机中,内存分配以较大的“块”为单位。如果对象较大,它会占用单独的块。严格来说,“停止-复制”要求在释放旧有对象之前,必须先把所有的存货兑现从旧堆复制到新堆,这将导致大量内存复制行为。有了快之后,垃圾回收期在回收的时候就可以往飞起的块里拷贝对象了。每个块都用相应的代数(generation count)来记录它是否存活。通常,如果快被某处引用,其代数会增加,垃圾回收期会定期进行完整的清理动作————大型对象仍然不会被复制(只是其代数会增加),内含小型对象的那些块则被复制并整理。java虚拟机会进行监视,如果所有对象都很稳定,垃圾回收器的效率降低的话,就切换到“标记-清扫”方式;同样,java虚拟机会跟踪“标记-清扫”的效果,要是堆空间出现很多碎片,就会切换回“停止-复制”的方式。这就是“自适应”技术,你可以给它个啰嗦的称呼:“自适应的、分代的、停止-复制、标记-清扫”式垃圾回收器。