释放stringBuilder内存的最快方法

Question

释放stringbuilder内存的最快方法是什么。

 StringBUilder sb = new StringBuilder();
 sb.apppend(maximum value possible);

下面是我试图尽快释放内存并使对象符合垃圾收集条件的代码片段

备选案文1：

sb = null;

根据我的理解，stringBuilder中的所有数据都将被删除，对象一旦被踢入，就有资格获得垃圾回收机制，但stringBuilder占用的文本内存将被释放。它的字符串值也会从堆中删除，还是会存储在字符串池中？

选项2：

 sb.setLength(0);

这将重置字符串生成器的长度，但不会被垃圾收集

选项3：

 sb.delete(0,sb.length());

这将通过删除字符串生成器中的所有数据来重置字符串生成器，但不会被垃圾收集

选项4：

 sb.delete(0,sb.length());
 sb = null;

这将重置字符串生成器，并使其符合垃圾回收机制？！

Answer 1

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

除此之外，你无法控制何时释放内存。你能做的最多的事情就是请求垃圾收集，这很少是个好主意（更不用说你只是在请求，而不是命令JVM进行垃圾收集）。

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

Answer 2

简单：跟着

sb = null;

忘了其他的吧。

为什么？一旦GC能够确定一个对象符合垃圾收集的条件，它还知道从该对象引用的所有东西都符合条件。鉴于您无法控制GC的启动、清理对象和释放内存，上述任务已经足够好了。

因为它清楚地传达了你的意图，然后帮助气相色谱完成它的工作。实际上写得好的代码可能甚至不需要那个语句。

现在，也许这还不够好。但接下来我们要讨论的是一个真正的性能问题，在一个非常明确和狭窄的背景下。在这种情况下，你不依赖道听途说，你开始测量。

换句话说：如果你的设置中没有表现出真正的性能问题，并且需要采取行动，那么你就使用简单、清晰的代码，避免各种“源代码级别”的优化。但是，如果你有一个真正的性能问题，那么你就应该相应地处理它：通过确定根本原因，并可能通过测量不同选项在现实中的效果。

其他任何东西都有过早优化的味道！

Answer 3

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

为此，对GC选项的详细分析超出了这里的合理范围，但具体来说，新的Shenandoah GC可以调整为比G1或并发标记/扫描更积极地释放内存，所以这可能是您想要使用的。您可以使用-XX:UseShenandoahGC指定这一点。（这是OpenJDK特有的，在这一点上是实验性的，但是如果你想要你想要的行为，它就是你想要的。）

对于快速发布时间，您需要为ShenandoahUncommitDelay和shenandoahguarantedcinterval使用一个较小的值。这里的较小值（广义上）将更频繁、更积极地运行GC，因此使用更多的CPU周期——但它会产生你想要的效果，与以前的GC版本相比，内存的释放速度将非常快。

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