问释放字符串构建器内存的最快方法

EN

如果您真的希望尽快释放内存，那么您需要查看GC选项，而不是代码。

用于此目的的GC选项的详细分析超出了这里的适用范围-但具体而言，新的Shenandoah GC可以调优为在释放内存方面比G1或并发标记/清除更积极，所以这可能是您想要使用的。您可以使用-XX:+UseShenandoahGC指定这一点。(在这一点上，它是特定于OpenJDK的，并且是实验性的，但如果你想要你想要的行为，它就是你想要的。)

为了加快发布时间，您可能希望为ShenandoahUncommitDelay和ShenandoahGuaranteedGCInterval使用较小的值。这里较小的值(广义上讲)将更频繁、更积极地运行GC，因此使用更多的CPU周期-但它将产生您想要的效果，与以前的GC版本相比，内存将以令人难以置信的速度释放。

如果您只想确保内存被释放，以便可以快速地进行垃圾回收，那么您只需要确保在最快的时候将对该StringBuilder的所有引用设置为null。即使在这种情况下，我也鼓励您分析和检查是否需要显式地执行此操作-在许多情况下，JVM足够智能地将对象标记为符合GC的条件，即使它们在技术上仍在作用域中(只要它可以看到它们不再在该作用域的其余部分中被引用)。

简单:使用

sb = null;

把剩下的都忘了。

为什么？一旦GC可以确定一个对象有资格进行垃圾回收，它也就知道从该对象引用的所有东西都是有资格的。考虑到你有关于GC踢入、清理对象和释放内存的no控制的事实，上面的赋值确实足够好了。

因为它清楚地传达了你的意图，然后帮助GC完成它的工作。实际上，编写良好的代码甚至可能不需要该语句。

现在，也许这实际上还不够好。但是，我们将在非常明确和狭义的上下文中讨论真正的性能问题。在这种情况下，你不依赖于道听途说，你开始测量。

换句话说:如果你没有在你的设置中表现出来的真正的性能问题，并且需要采取行动，那么你可以使用简单，清晰的代码，避免所有类型的“源代码级”优化。但如果你有一个真正的性能问题，那么你就应该这样处理:找出根本原因，并可能通过测量在现实中不同的选项是如何工作的。

还有没有过早优化的味道！

确保StringBuilder符合垃圾回收条件的唯一安全方法是与所有对象相同:杀死对它的所有引用。这意味着显式地将它设置为null，或者让它退出作用域。

除此之外，您无法控制何时释放内存。您最多只能请求垃圾收集，而这并不是一个好主意(更不用说您只是请求，而不是命令JVM进行垃圾收集)。

您提出的其他选择不能保证释放所有内存，除非您深入研究了代码并确信完全刷新了对象的状态。这就是为什么如果您想要确保一切都是“干净的”，通常最好是将整个对象引用设为空，然后重新开始。