Rob*_*ker 6 garbage-collection memory-leaks
如果我有一个垃圾收集器跟踪分配的每个对象并在它们不再具有可用的引用时立即解除分配它们你是否还会有内存泄漏？
考虑到内存泄漏是没有任何参考的分配是不是不可能或我错过了什么？
编辑:所以我在计算内存泄漏的是分配,你在代码中不再有任何引用.您仍然参考的大量累积分配不是我在这里考虑的泄漏.
我也只是谈论普通的GC技术,它已经有一段时间了,但是我知道像周期性参考这样的情况不会让它们绊倒.我不需要任何语言的具体答案,这只是来自我与朋友的对话.我们谈论的是Actionscript和Java,但我并不关心那些特定的答案.
编辑2:从它的声音,似乎没有任何理由代码完全失去引用分配的能力,并没有GC能够拿起它,但我还在等待更多的权衡.
如果您的问题确实如此:
考虑到内存泄漏是没有任何参考的分配是不是不可能或我错过了什么？
然后答案是"是的,那是不可能的",因为正确实现的垃圾收集器将回收所有没有活动引用的分配.
但是,在(例如)Java中肯定会出现"内存泄漏".我对"内存泄漏"的定义是一个仍然具有活动引用的分配(因此它不会被垃圾收集器回收),但程序员不知道该对象不可回收(即:用于程序员,这个对象已经死了,应该被收回).一个简单的例子是这样的:
ObjectA - > ObjectB
在此示例中,ObjectA是代码中活动使用的对象.但是,ObjectA包含对ObjectB的引用,它实际上已经死了(即:已经分配并使用了ObjectB,现在,从程序员的角度看,已经死了),但是程序员忘了将ObjectA中的引用设置为null.在这种情况下,ObjectB已经"泄露".
听起来不是一个大问题,但有些情况下这些泄漏是累积的.让我们假设ObjectA和ObjectB实际上是同一个类的实例.并且每次使用这样的实例时,程序员忘记将引用设置为null的这个问题就会发生.最终你得到这样的东西:
ObjectA - > ObjectB - > ObjectC - > ObjectD - > ObjectE - > ObjectF - > ObjectG - > ObjectH - > etc ...
现在,ObjectB到ObjectH都被泄露了.这样的问题(最终)会导致程序崩溃.即使有正确实施的垃圾收集器.