java - StringBuilder.append 链是否比字符串连接更有效？

Question

根据名为 使用 .append 方法链而不是字符串连接的 Netbeans 提示

Looks for string concatenation in the parameter of an invocation of the append method of StringBuilder or StringBuffer.

StringBuilder.append() 真的比字符串连接更高效吗？

代码示例

StringBuilder sb = new StringBuilder();
sb.append(filename + "/");

对比

StringBuilder sb = new StringBuilder();
sb.append(filename).append("/");

Answer 1

您必须平衡可读性和功能性。

假设您有以下内容:

String str = "foo";
str += "bar";
if(baz) str += "baz";

这将创建 2 个字符串构建器(实际上您只需要 1 个)加上一个额外的字符串对象用于临时。如果你去，你会更有效率:

StringBuilder strBuilder = new StringBuilder("foo");
strBuilder.append("bar");
if(baz) strBuilder.append("baz");
String str = strBuilder.toString();

但就风格而言，我认为第一个看起来还不错。对我来说，单个对象创建的性能优势似乎很小。现在，如果不是 3 根琴弦，而是 10、20 或 100 根琴弦，我会说性能胜过风格。如果它在一个循环中，我肯定会使用字符串生成器，但我认为只需几个字符串就可以使用“草率”的方式使代码看起来更干净。但是……这里面潜伏着一个非常危险的陷阱!请继续阅读下面的内容(暂停以制造悬念...... dun dun dunnnn)

有些人说要始终使用显式字符串生成器。一个理由是您的代码将继续增长，并且通常会以与它已经相同的方式这样做(即他们不会花时间重构。)因此您最终会得到每条创建的 10 或 20 条语句当你不需要他们自己的 build 者。因此，为了从一开始就防止这种情况，他们说始终使用显式构建器。

因此，虽然在您的示例中，它不会特别快，但当将来有人决定他们想要一个文件扩展名或类似的东西时，如果他们继续使用字符串连接而不是 StringBuilder，他们'最终会遇到性能问题。

我们还需要考虑 future 。假设您在 JDK 1.1 中编写 Java 代码，并且您有以下方法:

public String concat(String s1, String s2, String s3) {
    return s1 + s2 + s3;
}

那时会很慢，因为没有StringBuilder。

然后在 JDK 1.3 中，您决定使用 StringBuffer 来提高速度(StringBuilder 仍然不存在)。你这样做:

public String concat(String s1, String s2, String s3) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);
    return sb.toString();
}

它变得更快。太棒了!

现在JDK 1.5出来了，随之而来的是StringBuilder(比StringBuffer更快)和自动转换

return s1 + s2 + s3;

到

return new StringBuilder().append(s1).append(s2).append(s3).toString();

但您并没有获得这种性能优势，因为您明确地使用了 StringBuffer。因此，通过变得聪明，当 Java 变得比你更聪明时，你已经对性能造成了影响。所以你必须记住，有些事情是你不会想到的。