Java：清除StringBuffer内容

发布于 2024-09-30 03:12:44 字数 586 浏览 3 评论 0原文

所有，

我想知道使用 setLength(0) 清除 StringBuffer 内容是否有意义。即这样做更好：

while (<some condition>)
{
    stringBufferVariable = new StringBuffer(128);
    stringBufferVariable.append(<something>)
                        .append(<more>)
                        ... ;
    Append stringBufferVariable.toString() to a file;
    stringBufferVariable.setLength(0);
}

我的问题：
1>这仍然比使用 String 对象附加内容具有更好的性能吗？

我不太确定重新初始化 StringBuffer 变量会如何影响性能，从而影响问题。

请发表您的评论

[编辑]：删除了关于与 StringBuilder 进行比较的第二个问题，因为我知道根据回复没有更多需要研究的了。

原文

All,

I was wondering if clearing a StringBuffer contents using the setLength(0) would make sense. i.e. Is it better to do :

while (<some condition>)
{
    stringBufferVariable = new StringBuffer(128);
    stringBufferVariable.append(<something>)
                        .append(<more>)
                        ... ;
    Append stringBufferVariable.toString() to a file;
    stringBufferVariable.setLength(0);
}

My questions:
1 > Will this still have better performance than having a String object to append the contents?

I am not really sure how reinitializing the StringBuffer variable would affect the performance and hence the question.

Please pour in your comments

[edit]: Removed the 2nd question about comparing to StringBuilder since I have understood there nothing more to look into based on responses.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

守望孤独 2024-10-07 03:12:44

比连接字符串更好？

如果您问是否

stringBufferVariable.append("something")
                    .append("more");
...

会比使用 + 连接表现更好，那么通常是的。这就是这些类存在的全部原因。与更新 char 数组中的值相比，对象创建的成本较高。

现在，大多数（如果不是全部）编译器都会在简单情况下将字符串连接转换为使用 StringBuilder，例如 str = "something" + "more" + "...";。我可以看到的唯一性能差异是编译器不会具有设置初始大小的优势。基准会告诉您差异是否足够重要。使用 + 将使代码更具可读性。

根据我的阅读，编译器显然无法优化循环中完成的串联，因此

String str = "";
for (int i = 0; i < 10000; i++) {
    str = str + i + ",";
}

在这些情况下您仍然希望显式使用 StringBuilder。

StringBuilder 与 StringBuffer

StringBuilder 不是线程安全的，而 StringBuffer 是线程安全的，但它们在其他方面是相同的。在 StringBuffer 中执行的同步使其变慢，因此 StringBuilder 速度更快，除非需要同步，否则应使用它。

你应该使用`setLength`吗？

按照您当前示例的编写方式，我认为对 setLength 的调用不会给您带来任何好处，因为您在每次循环时都会创建一个新的 StringBuffer 。您真正应该做的是

StringBuilder sb = new StringBuilder(128);
while (<some condition>) {
    sb.append(<something>)
      .append(<more>)
      ... ;
    // Append stringBufferVariable.toString() to a file;
    sb.setLength(0);
}

这可以避免不必要的对象创建，并且在这种情况下 setLength 将仅更新内部 int 变量。

Better than concatenating strings?

If you're asking whether

stringBufferVariable.append("something")
                    .append("more");
...

will perform better than concatenating with +, then yes, usually. That's the whole reason these classes exist. Object creation is expensive compared to updating the values in a char array.

It appears most if not all compilers now convert string concatenation into using StringBuilder in simple cases such as str = "something" + "more" + "...";. The only performance difference I can then see is that the compiler won't have the advantage of setting the initial size. Benchmarks would tell you whether the difference is enough to matter. Using + would make for more readable code though.

From what I've read, the compiler apparently can't optimize concatenation done in a loop when it's something like

String str = "";
for (int i = 0; i < 10000; i++) {
    str = str + i + ",";
}

so in those cases you would still want to explicitly use StringBuilder.

StringBuilder vs StringBuffer

StringBuilder is not thread-safe while StringBuffer is, but they are otherwise the same. The synchronization performed in StringBuffer makes it slower, so StringBuilder is faster and should be used unless you need the synchronization.

Should you use `setLength`?

The way your example is currently written I don't think the call to setLength gets you anything, since you're creating a new StringBuffer on each pass through the loop. What you should really do is

StringBuilder sb = new StringBuilder(128);
while (<some condition>) {
    sb.append(<something>)
      .append(<more>)
      ... ;
    // Append stringBufferVariable.toString() to a file;
    sb.setLength(0);
}

This avoids unnecessary object creation and setLength will only be updating an internal int variable in this case.

回复收藏 0 原文

流星番茄 2024-10-07 03:12:44

我只是关注问题的这一部分。（其他部分之前已被问过并回答过很多次。）

我想知道使用 setLength(0) 清除 StringBuffer 内容是否有意义。

这取决于您使用的 Java 类库。在某些较旧的 Sun 版本的 Java 中，实现 StringBuffer.toString() 的前提是假设对 sb.toString() 的调用是对缓冲区执行的最后一件事。 StringBuffer 的原始后备数组成为 toString() 返回的 String 的一部分。随后尝试使用 StringBuffer 导致通过复制 String 内容创建并初始化一个新的后备数组。因此，在代码中尝试重用 StringBuffer 实际上会使应用程序变慢。

对于 Java 1.5 及更高版本，更好的编码方法如下：

    bufferedWriter.append(stringBufferVariable);
    stringBufferVariable.setLength(0);

这应该将字符直接从 StringBuilder 复制到文件缓冲区中，而不需要创建临时 String。如果 StringBuffer 声明位于循环之外，则 setLength(0) 允许您重用该缓冲区。

最后，只有当您有证据表明这部分代码是（或可能是）瓶颈时，您才应该担心所有这些。 “过早的优化是万恶之源”等等，等等。

I'm just focusing on this part of the question. (The other parts have been asked and answered many times before on SO.)

I was wondering if clearing a StringBuffer contents using the setLength(0) would make sense.

It depends on the Java class libraries you are using. In some older Sun releases of Java, the StringBuffer.toString() was implemented on the assumption that a call to sb.toString() is the last thing that is done with the buffer. The StringBuffer's original backing array becomes part of the String returned by toString(). A subsequent attempt to use the StringBuffer resulted a new backing array being created and initialized by copying the String contents. Thus, reusing a StringBuffer as your code tries to do would actually make the application slower.

With Java 1.5 and later, a better way to code this is as follows:

    bufferedWriter.append(stringBufferVariable);
    stringBufferVariable.setLength(0);

This should copy the characters directly from the StringBuilder into the file buffer without any need to create a temporary String. Providing that the StringBuffer declaration is outside the loop, the setLength(0) then allows you to reuse the buffer.

Finally, you should only be worrying about all of this if you have evidence that this part of the code is (or is likely to be) a bottleneck. "Premature optimization is the root of all evil" blah, blah.

回复收藏 0 原文