为什么Java和Python垃圾收集方法有所不同?

Python使用引用计数方法来处理对象的生命周期。 所以没有更多使用的对象将被立即销毁。

但是,在Java中,GC(垃圾回收器)会破坏在特定时间不再使用的对象。

为什么Javaselect这个策略,从中得到什么好处呢?

这比Python方法更好吗?

使用引用计数有一些缺点。 其中提到的最多的是循环引用:假设引用B,B引用C和C引用B.如果A将它的引用放到B,那么B和C将仍然有一个引用计数为1,并且不会被删除与传统的参考计数。 CPython(引用计数不是Python本身的一部分,但是它的C实现的一部分)通过一个单独的垃圾回收例程捕获循环引用,它周期性地运行…

另一个缺点:引用计数会使执行速度变慢。 每次一个对象被引用和取消引用时,解释器/虚拟机必须检查计数是否已经降到0(然后如果是,则释放)。 垃圾收集不需要这样做。

此外,垃圾收集可以在一个单独的线程完成(虽然它可能有点棘手)。 在有很多内存的机器上,以及只能缓慢使用内存的进程中,你可能根本不想做GC! 引用计数在性能方面会有一些缺点…

实际上引用计数和Sun JVM使用的策略都是不同types的垃圾收集algorithm。

追踪死对象有两种广泛的方法:追踪和引用计数。 跟踪GC从“根”开始 – 像堆栈引用之类的东西,并跟踪所有可访问(活动)对象。 任何不能达到的东西都被认为是死的。 在每次引用被修改的引用计数中,所涉及的对象的计数已经被更新。 引用计数设置为零的任何对象都被认为是死的。

基本上所有的GC实现都存在权衡,但是跟踪通常对高通(即快速)操作有好处,但具有较长的暂停时间(UI或程序可能冻结的较大差距)。 引用计数可以在较小的块中运行,但总体上会较慢。 这可能意味着冻结较less,但整体performance较差。

另外,引用计数GC需要周期检测器来清除周期中的任何对象,这些对象不会被引用计数单独捕获。 Perl 5在其GC实现中没有循环检测器,可能会泄漏循环内存。

为了获得两全其美(暂停时间短,吞吐量高)的研究: http : //cs.anu.edu.au/~Steve.Blackburn/pubs/papers/urc-oopsla-2003.pdf

达伦·托马斯给出了很好的答案。 然而,Java和Python方法之间的一个很大的区别在于,在通常情况下(无循环引用)通过引用计数来立即清除对象,而不是在稍后的某个不确定的date。

例如,我可以在CPython中编写简洁,不可移植的代码

def parse_some_attrs(fname): return open(fname).read().split("~~~")[2:4] 

并且我打开的那个文件的文件描述符将被立即清除,因为一旦对打开文件的引用消失,文件就被垃圾收集,文件描述符被释放。 当然,如果我运行Jython或者IronPython或者PyPy,那么垃圾收集器不一定会运行到很久以后; 可能我会用尽文件描述符,我的程序将崩溃。

所以你应该写代码看起来像

 def parse_some_attrs(fname): with open(fname) as f: return f.read().split("~~~")[2:4] 

但有时候人们喜欢依靠引用计数来总是释放资源,因为它有时会使代码变得更短一些。

我会说最好的垃圾收集器是性能最好的垃圾收集器,目前似乎是Java风格的世代垃圾收集器,可以在单独的线程中运行,并具有所有这些疯狂的优化等等。写你的代码应该是微不足道的,理想情况下是不存在的。

我认为IBM的文章“ Java理论与实践:垃圾收集的简史 ”应该有助于解释一些问题。

如果您有足够的内存,垃圾收集比参考计数更快(更省时)。 例如,复制gc遍历“活”对象并将它们复制到一个新的空间,并且可以通过标记整个内存区域来一步回收所有“死”对象。 如果你有足够的内存,这是非常有效的。 世代collections使用“大多数物体年轻化”的知识; 通常只有百分之几的对象必须被复制。

[这也是gc可以比malloc / free更快的原因]

引用计数比垃圾收集更节省空间,因为它在无法访问的时刻回收内存。 这是很好的,当你想附加终结器的对象(例如,一旦File对象无法访问closures文件)。 即使只有百分之几的内存空闲,引用计数系统也可以工作。 但是在每个指针分配上增加和减less计数器的pipe理成本花费了大量时间,并且还需要某种垃圾收集来回收周期。

因此,权衡是明确的:如果您必须在内存受限的环境中工作,或者如果您需要精确的终结器,请使用引用计数。 如果你有足够的内存和需要的速度,使用垃圾收集。

Java跟踪GC的一大缺点是,它会不时地“停止世界”,并冻结相对较长的时间来完成GC。 如果堆大,对象树复杂,则会冻结几秒钟。 另外每个完整的GC都会一遍又一遍地访问整个对象树,可能效率很低。 Java执行GC的另一个缺点是你必须告诉jvm你想要的堆大小(如果默认值不够好); JVM从该值派生出几个阈值,当堆中垃圾堆积太多时,这些阈值将触发GC进程。

我认为这实际上是Android(基于Java),即使是在最昂贵的手机上,与iOS(基于ObjectiveC,使用RC)的stream畅性相比,这种不平顺的感觉的主要原因。

我很希望看到一个jvm选项来启用RC内存pipe理,也许只有在没有剩余内存的情况下,GC才能作为最后的手段运行。

最新的Sun Java VM实际上有多个你可以调整的GCalgorithm。 Java VM规范故意忽略了指定实际的GC行为,以允许针对不同VM的不同(和多个)GCalgorithm。

例如,对于所有不喜欢默认Sun Java VM GC行为的“停止世界”方法的人来说,都有像IBM的WebSphere Real Time这样的VM,它允许实时应用程序在Java上运行。

由于Java VM规范是公开可用的,所以从理论上讲没有任何人阻止任何人使用CPython的GCalgorithm来实现Java VM。

引用计数在multithreading环境中特别难以有效地执行。 我不知道如何进行硬件辅助交易或类似的(目前)不寻常的primefaces指令。

引用计数很容易实现。 JVM有大量资金投入竞争实施,所以他们实施非常好的解决scheme来解决非常棘手的问题并不奇怪。 但是,在JVM上定位自己喜欢的语言变得越来越容易了。

在游戏后期,但我认为在Python中RC的一个重要的基本原理是它的简单性。 例如,请参阅Alex Martelli的电子邮件 。

(我无法find一个链接外的谷歌caching,电子邮件date从2005年10月13日在Python列表)。