java - 即使字符串池中已有可用的对象，字符串追加也会花费更多时间

Question

我尝试过这个例子来发现 StringBuffer、StringBuilder 和 String 的执行时间不同

经过尝试，我发现 StringBuffer 和 StringBuilder 花费的时间更少，因为它没有创建新对象。

作为字符串追加空字符串也不会创建任何对象，因此速度更快。

当我 append 一些字符串时，应该需要更多时间，因为创建对象需要时间。

当我对另一个字符串执行相同的 append 字符串模式时，这也花费了更多时间。在这种情况下，所有对象都已在字符串池中可用。为什么它花费的时间和以前一样？

public class StringComparation {
  public static void main(String[] args) {
    int N = 100000;
    long time;
    // String Buffer
    StringBuffer sb = new StringBuffer();
    time = System.currentTimeMillis();
    for (int i = N; i --> 0 ;) {
         sb.append("a");
    }
    System.out.println("String Buffer - " + (System.currentTimeMillis() - time));
    // String Builder 
    StringBuilder sbr = new StringBuilder();
    time = System.currentTimeMillis();
    for (int i = N; i --> 0 ;) {
        sbr.append("a");
    }
    System.out.println("String Builder - " + (System.currentTimeMillis() - time));
    // String Without String pool value 
    String s2 = new String();
    time = System.currentTimeMillis();
    for (int i = N; i --> 0 ;) {
        s2 = s2 + "";
    }
    System.out.println("String Without String pool value - " 
              + (System.currentTimeMillis() - time));
    // String With new String pool Object
    String s = new String();
    time = System.currentTimeMillis();
    for (int i = N; i --> 0 ;) {
        s = s + "a";
    }
    System.out.println("String With new String pool Object - " 
            + (System.currentTimeMillis() - time));
    // String With already available String pool Object 
    String s1 = new String();
    time = System.currentTimeMillis();
    for (int i = N; i --> 0 ;) {
        s1 = s1 + "a";
    }
    System.out.println("String With already available String pool Object - " 
            + (System.currentTimeMillis() - time));       
  }
}

输出:

String Buffer - 43
String Builder - 16
String Without String pool value - 64
String With new String pool Object - 12659
String With already available String pool Object - 14258

如有错误，请指正。

Answer 1

鉴于您的最后两个测试是相同的，因此您实际上只有四个测试。为了方便起见，我将它们重构为单独的方法并删除了基准测试代码，因为没有必要了解这里发生的情况。

public static void stringBuilderTest(int iterations) {
    final StringBuilder sb = new StringBuilder();
    for (int i = iterations; i-- > 0;) {
        sb.append("a");
    }
}

public static void stringBufferTest(int iterations) {
    final StringBuffer sb = new StringBuffer();
    for (int i = iterations; i-- > 0;) {
        sb.append("a");
    }
}

public static void emptyStringConcatTest(int iterations) {
    String s = new String();
    for (int i = iterations; i-- > 0;) {
        s += "";
    }
}

public static void nonEmptyStringConcatTest(int iterations) {
    String s = new String();
    for (int i = iterations; i-- > 0;) {
        s += "a";
    }
}

我们已经知道 StringBuilder 版本的代码是四个版本中最快的。 StringBuffer 版本速度较慢，因为它的所有操作都是同步的，这带来了 StringBuilder 没有的不可避免的开销，因为它不同步。

所以我们感兴趣的两个方法是 emptyStringConcatTest和nonEmptyStringConcatTest 。如果我们检查 emptyStringConcatTest 编译版本的字节码，我们看到以下内容:

  public static void emptyStringConcatTest(int);
    flags: ACC_PUBLIC, ACC_STATIC
    LineNumberTable:
      line 27: 0
      line 28: 8
      line 29: 17
      line 31: 40
    Code:
      stack=2, locals=3, args_size=1
         0: new           #14                 // class java/lang/String
         3: dup
         4: invokespecial #15                 // Method java/lang/String."<init>":()V
         7: astore_1
         8: iload_0
         9: istore_2
        10: iload_2
        11: iinc          2, -1
        14: ifle          40
        17: new           #7                  // class java/lang/StringBuilder
        20: dup
        21: invokespecial #8                  // Method java/lang/StringBuilder."<init>":()V
        24: aload_1
        25: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        28: ldc           #16                 // String
        30: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        33: invokevirtual #17                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        36: astore_1
        37: goto          10
        40: return
      LineNumberTable:
        line 27: 0
        line 28: 8
        line 29: 17
        line 31: 40
      StackMapTable: number_of_entries = 2
           frame_type = 253 /* append */
             offset_delta = 10
        locals = [ class java/lang/String, int ]
           frame_type = 250 /* chop */
          offset_delta = 29

在底层，这两种方法几乎相同，唯一的区别是这一行:

空字符串:

28: ldc           #9                  // String 

非空字符串(注意微小但重要的区别!):

28: ldc           #9                  // String a

关于字节码，首先要注意的是for的结构。循环体:

10: iload_2
11: iinc          2, -1
14: ifle          40
17: new           #7                  // class java/lang/StringBuilder
20: dup
21: invokespecial #8                  // Method java/lang/StringBuilder."<init>":()V
24: aload_1
25: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
28: ldc           #16                 // String
30: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
33: invokevirtual #17                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
36: astore_1
37: goto          10

我们实际上最终得到的是编译器优化

for (int i = iterations; i-- > 0;) {
    s += "";
}

进入:

for (int i = iterations; i-- > 0;) {
    s = new StringBuilder().append(s).append("").toString();
}

这不太好。我们在每一次迭代中实例化一个新的临时 StringBuilder 对象，其中有 100,000 次。这是很多对象。

您在 emptyStringConcatTest 之间看到的差异和nonEmptyStringConcatTest如果我们检查StringBuilder#append(String)的源代码可以进一步解释:

public StringBuilder append(String str) {
    super.append(str);
    return this;
}

StringBuilder的父类(super class)是AbstractStringBuilder，我们来看看它的append(String)的实现:

public AbstractStringBuilder append(String str) {
    if (str == null) str = "null";
        int len = str.length();
    if (len == 0) return this;
    int newCount = count + len;
    if (newCount > value.length)
        expandCapacity(newCount);
    str.getChars(0, len, value, count);
    count = newCount;
    return this;
}

您会在这里注意到，如果参数的长度 str为零，该方法只是返回而不执行任何进一步的操作，这使得在空字符串的情况下速度相当快。

非空字符串参数触发支持的边界检查 char[] ，可能会导致其大小调整为 expandCapacity(int) ，它将原始数组复制到一个新的、更大的数组中(请注意，StringBuilder 中的后备数组不是 final - 它可以重新分配!)。完成后，我们调用 String#getChars(int, int, char[], int) ，它执行更多数组复制。数组复制的确切实现隐藏在 native 代码中，因此我不会四处寻找它们。

更复杂的是，我们创建然后丢弃的对象的绝对数量可能足以触发 JVM 垃圾收集器的运行，这会带来进一步的开销。

总而言之；相当于 nonEmptyStringConcatTest 的性能大幅下降很大程度上取决于编译器所做的糟糕的“优化”。通过不在循环内进行直接串联来避免这种情况。