你的旧样式会被JAVAC 1.6自动编译为:

StringBuilder sb = new StringBuilder("What do you get if you multiply ");
sb.append(varSix);
sb.append(" by ");
sb.append(varNine);
sb.append("?");
String s =  sb.toString();

所以这和使用StringBuilder是没有区别的。

字符串。format要重量级得多，因为它创建了一个新的Formatter，解析输入格式字符串，创建一个StringBuilder，将所有内容附加到它并调用toString()。

我使用了hhafez的代码并添加了一个内存测试:

private static void test() {
    Runtime runtime = Runtime.getRuntime();
    long memory;
    ...
    memory = runtime.freeMemory();
    // for loop code
    memory = memory-runtime.freeMemory();

我为每一种方法分别运行这个程序，'+'操作符，String。format和StringBuilder(调用toString())，因此所使用的内存不会受到其他方法的影响。 我添加了更多的连接，使字符串为“Blah”+ I +“Blah”+ I +“Blah”+ I +“Blah”。

结果如下(平均每次5次):

我们可以看到String +和StringBuilder在时间上实际上是相同的，但是StringBuilder在内存使用上要高效得多。 当我们在足够短的时间间隔内有许多日志调用(或任何其他涉及字符串的语句)时，这是非常重要的，因此垃圾收集器将无法清理+操作符导致的许多字符串实例。

顺便说一句，在构造消息之前，不要忘记检查日志级别。

结论:

我将继续使用StringBuilder。 我有的是时间，有的是生活。

通常应该使用String。格式，因为它相对较快，并且支持全球化(假设您实际上正在尝试编写用户可以阅读的内容)。如果您试图翻译一个字符串，而不是每个语句翻译3个或更多字符串(特别是对于语法结构截然不同的语言)，它还可以使全球化变得更容易。

现在，如果您不打算翻译任何东西，那么要么依赖于Java内置的+运算符到StringBuilder的转换。或者显式地使用Java的StringBuilder。

在您的示例中，性能可能没有太大不同，但还有其他问题需要考虑:即内存碎片。连接操作也在创建一个新字符串，即使它是临时的(GC需要时间，而且工作量更大)。String.format()可读性更强，涉及的碎片更少。

此外，如果你经常使用特定的格式，不要忘记你可以直接使用Formatter()类(所有String.format()所做的是实例化一个使用Formatter实例)。

此外，还应该注意其他一些事情:小心使用substring()。例如:

String getSmallString() {
  String largeString = // load from file; say 2M in size
  return largeString.substring(100, 300);
}

这个大字符串仍然在内存中，因为这就是Java子字符串的工作方式。一个更好的版本是:

  return new String(largeString.substring(100, 300));

or

  return String.format("%s", largeString.substring(100, 300));

如果你同时做其他事情，第二种形式可能更有用。

Java的字符串。格式如下:

它解析格式字符串，分解成一个格式块列表 它迭代格式块，呈现为一个StringBuilder，这基本上是一个数组，根据需要调整自己的大小，通过复制到一个新的数组。这是必要的，因为我们还不知道分配最终字符串的大小 StringBuilder.toString()将他的内部缓冲区复制到一个新的String中

如果这个数据的最终目的地是一个流(例如，渲染一个网页或写入一个文件)，你可以将格式块直接组装到你的流中:

new PrintStream(outputStream, autoFlush, encoding).format("hello {0}", "world");

我推测优化器将优化掉格式字符串处理。如果是这样，就剩下了与手动展开String相同的平摊性能。格式转换为StringBuilder。

To expand/correct on the first answer above, it's not translation that String.format would help with, actually. What String.format will help with is when you're printing a date/time (or a numeric format, etc), where there are localization(l10n) differences (ie, some countries will print 04Feb2009 and others will print Feb042009). With translation, you're just talking about moving any externalizable strings (like error messages and what-not) into a property bundle so that you can use the right bundle for the right language, using ResourceBundle and MessageFormat. Looking at all the above, I'd say that performance-wise, String.format vs. plain concatenation comes down to what you prefer. If you prefer looking at calls to .format over concatenation, then by all means, go with that. After all, code is read a lot more than it's written.