仅从日志的角度看另一个角度。

我在这个帖子上看到了很多关于登录的讨论，所以我想在回答中加入我的经验。也许有人会觉得有用。

我猜使用格式化程序进行日志记录的动机来自于避免字符串连接。基本上，如果你不打算记录它，你不希望有字符串连接的开销。

实际上不需要concat/format，除非您想记录日志。假设我这样定义一个方法

public void logDebug(String... args, Throwable t) {
    if(debugOn) {
       // call concat methods for all args
       //log the final debug message
    }
}

在这种方法中，如果它是一个调试消息并且debugOn = false，则根本不会真正调用canat /formatter

尽管在这里使用StringBuilder而不是formatter会更好。我们的主要动机就是避免这些。

同时，我不喜欢为每个日志语句添加“if”块

它会影响可读性 减少单元测试的覆盖率——当你想要确保每一行都经过测试时，这会让人感到困惑。

因此，我更喜欢用上面的方法创建一个日志实用程序类，并在任何地方使用它，而不用担心性能损失和其他与之相关的问题。

我只是修改了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)。

Java的字符串。格式如下:

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

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

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

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

你的旧样式会被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()。