java - 这种技术会阻止 Java 进行垃圾收集吗？

Question

Colt McAnlis 做了 a wonderfully entertaining video on preventing the JavaScript garbage collector from slowing down applications

主要内容如下:

1. 当应用加载时，实例化一个未使用的对象/类池，您的应用可能在未来的某个时候需要这些对象/类。
2. 当您想要实例化一个新对象时，而是在您的池中找到一个未使用的适当类型的对象，捕获它并设置它的属性。
3. 改为使用此对象。
4. 完成后，将其标记为“未使用”，以便将来的方法可以利用它。

我的问题是这种方法是否也适用于 Java 垃圾收集器，或者它是否更难以规避并且最终只会扫描整个堆或其他东西。

这主要是理论上的/好奇的事情。我在开发中没有任何依赖于绕过垃圾收集的应用程序。

Answer 1

它会在某种意义上“起作用”。但不推荐，因为存在一些重大问题。

1. 如果您实现不当，就是内存泄漏。问题是“池”需要保留对其所有对象的引用。这可以防止 then 被垃圾收集。但是，如果应用程序在处理完对象后未能始终将对象标记为“未使用”(例如错误)，则这些对象将永远“使用中”。

   (如果您尝试使用 Reference 对象之类的东西来缓解这种情况，您最终会使用更多空间，并给 GC 带来更多负载。)

2. 当 GC 确实运行时，它必须遍历池中的所有对象，以及它们的所有依赖对象。这比允许对象死亡要多做一些工作。 (年轻的不可达对象根本不需要扫描。)

3. 经过几个 GC 周期后，池中的对象将被保留下来，因为它们的生命周期很长。这意味着它们将倾向于导致短期依赖对象保留，否则这些对象可能是可收集的，直到旧堆被收集为止。此外，对永久对象字段的引用分配可能更昂贵，并且可能使年轻空间收集花费更长的时间(因为旧的 -> 年轻的引用)。

请注意，您所讨论的对象池类型通常是为了减轻应用程序中过多的 GC 暂停而提出/完成的。在典型的现代 JVM 中，有专门设计用于最小化暂停的 GC。在大多数 Java 应用程序中，低暂停收集器是解决此问题的更好选择。 (一个异常(exception)是高度互动的游戏，其中任何类型的“滞后”都是 Not Acceptable 。)

使用对象池还有其他原因:

• 处理初始化成本非常高的对象。
• 处理需要限制数量的对象。
• 处理与需要妥善管理的外部资源关联的对象。

示例包括线程池、数据库连接池和 HTTP 连接池(在典型的 HTTP 客户端库中)。在适当的情况下，这些绝对是有益的。