我只是修改了hhafez的测试，以包括StringBuilder。StringBuilder比String快33倍。格式使用jdk 1.6.0_10客户端XP。使用-server开关将该因子降低到20。

public class StringTest {

   public static void main( String[] args ) {
      test();
      test();
   }

   private static void test() {
      int i = 0;
      long prev_time = System.currentTimeMillis();
      long time;

      for ( i = 0; i < 1000000; i++ ) {
         String s = "Blah" + i + "Blah";
      }
      time = System.currentTimeMillis() - prev_time;

      System.out.println("Time after for loop " + time);

      prev_time = System.currentTimeMillis();
      for ( i = 0; i < 1000000; i++ ) {
         String s = String.format("Blah %d Blah", i);
      }
      time = System.currentTimeMillis() - prev_time;
      System.out.println("Time after for loop " + time);

      prev_time = System.currentTimeMillis();
      for ( i = 0; i < 1000000; i++ ) {
         new StringBuilder("Blah").append(i).append("Blah");
      }
      time = System.currentTimeMillis() - prev_time;
      System.out.println("Time after for loop " + time);
   }
}

虽然这听起来可能很激烈，但我认为它只在极少数情况下相关，因为绝对数字非常低:100万个简单字符串对应4个s。格式调用是可以的-只要我使用他们的日志或类似的。

更新:正如sjbotha在评论中指出的，StringBuilder测试是无效的，因为它缺少最后的. tostring()。

在我的机器上，从String.format(.)到StringBuilder的正确加速因子是23(使用-server开关时为16)。

我使用了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。 我有的是时间，有的是生活。

我写了一个小类来测试两者中哪个具有更好的性能，并且+优先于格式。以5到6的倍数。 你自己试试吧

import java.io.*;
import java.util.Date;

public class StringTest{

    public static void main( String[] args ){
    int i = 0;
    long prev_time = System.currentTimeMillis();
    long time;

    for( i = 0; i< 100000; i++){
        String s = "Blah" + i + "Blah";
    }
    time = System.currentTimeMillis() - prev_time;

    System.out.println("Time after for loop " + time);

    prev_time = System.currentTimeMillis();
    for( i = 0; i<100000; i++){
        String s = String.format("Blah %d Blah", i);
    }
    time = System.currentTimeMillis() - prev_time;
    System.out.println("Time after for loop " + time);

    }
}

对不同的N运行上面的代码，可以看出两者都是线性的，但是String。格式要慢5-30倍。

原因是在当前的String实现中。Format首先用正则表达式解析输入，然后填充参数。另一方面，使用plus的连接由javac(而不是JIT)优化，并使用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虚拟机。

所以，旧的样式(使用+)要快得多。

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

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