我们必须一直为日志输出构建字符串等等。在JDK版本中，我们已经学习了什么时候使用StringBuffer(许多追加，线程安全)和StringBuilder(许多追加，非线程安全)。
使用String.format()有什么建议?它是有效的，还是我们被迫坚持在性能很重要的一行程序中使用连接?
例如，丑陋的老式风格，
String s = "What do you get if you multiply " + varSix + " by " + varNine + "?";
vs.整洁的新样式(字符串。格式，可能更慢)，
String s = String.format("What do you get if you multiply %d by %d?", varSix, varNine);
注意:我的特定用例是代码中的数百个“一行”日志字符串。它们不涉及循环，所以StringBuilder太重量级了。我对String.format()特别感兴趣。
当前回答
考虑使用“hello”。Concat(“世界!”)对于连接的少量字符串。它甚至比其他方法的性能更好。
如果你有超过3个字符串，考虑使用StringBuilder，或者只使用String，这取决于你使用的编译器。
其他回答
通常应该使用String。格式，因为它相对较快，并且支持全球化(假设您实际上正在尝试编写用户可以阅读的内容)。如果您试图翻译一个字符串，而不是每个语句翻译3个或更多字符串(特别是对于语法结构截然不同的语言)，它还可以使全球化变得更容易。
现在，如果您不打算翻译任何东西，那么要么依赖于Java内置的+运算符到StringBuilder的转换。或者显式地使用Java的StringBuilder。
这里提供的所有基准测试都有一些缺陷，因此结果不可靠。
我很惊讶没有人使用JMH进行基准测试，所以我就这样做了。
结果:
Benchmark Mode Cnt Score Error Units
MyBenchmark.testOld thrpt 20 9645.834 ± 238.165 ops/s // using +
MyBenchmark.testNew thrpt 20 429.898 ± 10.551 ops/s // using String.format
单位是每秒操作次数，越多越好。基准测试源代码。使用OpenJDK IcedTea 2.5.4 Java虚拟机。
所以，旧的样式(使用+)要快得多。
这个问题的答案在很大程度上取决于您特定的Java编译器如何优化它生成的字节码。字符串是不可变的，理论上，每个“+”操作都可以创建一个新的字符串。但是，你的编译器几乎肯定会优化掉构建长字符串的中间步骤。上面的两行代码完全有可能生成完全相同的字节码。
唯一真正了解的方法是在当前环境中迭代地测试代码。编写一个QD应用程序，以迭代的方式连接字符串，并查看它们如何彼此超时。
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.
