这种形式的内存管理在 Java 中有意义吗？

Question

在我的应用程序的生命周期中，我必须重新创建一个包含其他对象 ArrayList 的 ArrayList（从存储中读取它们）。 ArrayList 始终分配给类中的相同数据成员，本质上使旧的 ArrayList-of-ArrayList 悬空（不可引用或不可访问）。

我的理解是，与 C++ 不同，这不会导致内存泄漏，因为系统知道对象何时变得不可引用，并在它认为合适时释放内存。

尽管如此，旧习惯很难克服，我几乎本能地想通过在重新创建 ArrayList-of-ArrayLists 之前自己做一些清理来“帮助”系统：

for (InnerArray aList : outerArray)
  aList.clear();
outerArray.clear();

我的问题：

1. 这是多余的吗？
2. 我是不是弊大于利？
3. 这有什么好处吗？
4. 为什么？

Answer 1

这是多余的。您不会帮助释放这些对象，因为垃圾收集已经确定它们无法访问。你不能让他们变得比现在更遥不可及。因此，您在毫无效果的事情上浪费了一点处理时间。

不过，主要问题是您让其他开发人员感到困惑，他们会想知道为什么要清除该数组。如果有一些他们一开始没有看到的隐藏原因，他们可能会浪费时间试图弄清楚你为什么这样做。

C++ 开发人员在使用 Java 代码时往往会遇到的一个类似问题是制作 终结器；在 Java 中，您几乎不想这样做，因为终结器会增加垃圾收集的额外成本，并且它们不是释放资源的可靠方法，因为它们可能很长一段时间或永​​远不会被调用。

Answer 2

1. 是的 - 老实说我就是不明白。如果您不再需要某个对象，只需确保您无法再访问它即可！
2. 是的 - 调用可能会使用处理能力，垃圾收集可能会使用更少的处理能力来摆脱对象。正如内特所建议的那样，这也可能会令人困惑。
3. 不 - 抱歉，我没有看到任何好东西。
4. 请参阅上文，欢迎使用 Java！您现在可以专注于有趣的事情了:)

PS 我不确定我现在要说什么，但是 clear() 函数可能会从 ArrayList 中删除元素code> 只需确保您无法再通过 ArrayList 变量访问它们即可。也许它不会“摧毁”它们，但只会使它们有资格进行垃圾收集。如果知道该函数是如何实现的那就太好了...

PPS 您可能会想自己调用 GC，但不要这样做！请参阅相关问题。

编辑：

这是来自ArrayList的clear()：

public void clear()
{
    if (size > 0)
    {
        modCount++;
        // Allow for garbage collection.
        Arrays.fill(data, 0, size, null);
        size = 0;
    }
}

Answer 3

1）这是多余的吗？

是的。

2）我是否弊大于利？

是的。

3）这有什么好处吗？

不。

4）为什么？

在 ArrayList 上调用 clear() 会更改列表的 size 字段，然后小心地将 null 分配给其元素刚刚变得无效的支持数组。 clear() 的代码需要执行此操作，因为这些元素中的引用可能会导致其他对象保持可访问性；即泄漏内存。

但是，当ArrayList变得无法访问时，垃圾收集器将不再查看后备数组的任何元素。 GC的标记过程只遍历可达对象，回收过程不查看垃圾对象/数组的内容。

因此，基本上，对即将变得无法访问的对象调用 clear() 完全是对 CPU 周期和内存/VM 带宽的浪费。 （当然，这是多余的代码，下一个人会摸不着头脑......）

---

事实上，调用 clear 然后重用列表是否是一个好主意甚至是有争议的all:

• clear 不会释放/调整后备数组的大小，因此对于通常尺寸较小的列表，您可能会留下一个巨大的后备数组。

• 垃圾收集器可以比 clear() 完成其工作更快地释放足够大的数组并分配一个相同大小的新数组，这并非不可想象。 （首先，GC 可以使用多个处理器，其中对 clear() 的调用将在一个线程上运行。）

有没有一种场景确实可以证明调用clear()是合理的？

绝对有必要清除/重用列表的唯一情况是当其他东西引用该特定列表并且您无法更新列表引用时。

在内存受限和/或 GC 缓慢的平台上清除/重用列表也可能有好处。但是，除非我有强有力的证据表明这是一个问题，否则我不会尝试这种“优化”。 （这种优化会使您的代码变得更加复杂，并且如果做得不正确，可能会导致其本身的性能问题。）