----------------------------------------------------------------------------------
                  String                    StringBuffer         StringBuilder
----------------------------------------------------------------------------------                 
Storage Area | Constant String Pool         Heap                   Heap 
Modifiable   |  No (immutable)              Yes( mutable )         Yes( mutable )
Thread Safe  |      Yes                     Yes                     No
 Performance |     Fast                 Very slow                  Fast
----------------------------------------------------------------------------------

基础知识:

String是一个不可变的类，它不能被改变。 StringBuilder是一个可变类，可以追加，字符替换或删除，并最终转换为String StringBuffer是StringBuilder的原始同步版本

在只有一个线程访问对象的所有情况下，您都应该使用StringBuilder。

细节:

还要注意，StringBuilder/Buffers并不是魔法，它们只是使用一个数组作为支持对象，当数组满时必须重新分配。确保在初始时创建足够大的StringBuilder/Buffer对象，这样就不必在每次调用.append()时不断地调整它们的大小。

调整大小会变得非常糟糕。基本上，每次需要扩展时，它都会将支持数组的大小调整为当前大小的2倍。这可能导致在StringBuilder/Buffer类开始变大时分配大量RAM而不使用。

In Java String x = "A" + "B"; uses a StringBuilder behind the scenes. So for simple cases there is no benefit of declaring your own. But if you are building String objects that are large, say less than 4k, then declaring StringBuilder sb = StringBuilder(4096); is much more efficient than concatenation or using the default constructor which is only 16 characters. If your String is going to be less than 10k then initialize it with the constructor to 10k to be safe. But if it is initialize to 10k then you write 1 character more than 10k, it will get re-allocated and copied to a 20k array. So initializing high is better than to low.

在自动调整大小的情况下，在第17个字符时，后面的数组被重新分配并复制为32个字符，在第33个字符时，同样发生这种情况，你需要重新分配并将数组复制为64个字符。你可以看到这是如何退化为大量的重新分配和复制，这是你真正试图避免使用StringBuilder/Buffer在第一个地方。

这是来自JDK 6的AbstractStringBuilder源代码

   void expandCapacity(int minimumCapacity) {
    int newCapacity = (value.length + 1) * 2;
        if (newCapacity < 0) {
            newCapacity = Integer.MAX_VALUE;
        } else if (minimumCapacity > newCapacity) {
        newCapacity = minimumCapacity;
    }
        value = Arrays.copyOf(value, newCapacity);
    }

一个最好的做法是初始化StringBuilder/Buffer，如果你不知道String会有多大，但你可以猜测，比你认为你需要的要大一点。分配比您需要的稍微多一点的内存比大量的重新分配和复制要好。

另外，要注意用String初始化StringBuilder/Buffer，因为这样只会分配String + 16个字符的大小，在大多数情况下，这只会开始退化的重新分配和复制周期，而这是您试图避免的。下面是直接来自Java 6的源代码。

public StringBuilder(String str) {
    super(str.length() + 16);
    append(str);
    }

如果碰巧得到了一个不是自己创建的StringBuilder/Buffer实例，并且不能控制所调用的构造函数，有一种方法可以避免恶化的重新分配和复制行为。调用. ensurecapacity()，并设置你想要确保生成的字符串适合的大小。

的选择:

需要注意的是，如果您正在进行非常繁重的字符串构建和操作，有一种更面向性能的替代方法，称为rope。

另一种替代方法是通过子类化ArrayList<String>来创建一个StringList实现，并添加计数器来跟踪每个.append()和列表的其他突变操作上的字符数，然后重写. tostring()来创建一个你需要的精确大小的StringBuilder，并循环遍历列表并构建输出，你甚至可以使该StringBuilder成为一个实例变量并“缓存”. tostring()的结果，只有在发生变化时才需要重新生成它。

在构建固定格式化输出时也不要忘记String.format()，编译器可以优化它，因为它们使它更好。

注意，如果您使用的是Java 5或更新版本，您应该使用StringBuilder而不是StringBuffer。来自API文档:

从JDK 5发行版开始，这个类已经被一个为单个线程使用而设计的等效类StringBuilder所补充。通常应该优先使用StringBuilder类，因为它支持所有相同的操作，但速度更快，因为它不执行同步。

在实践中，您几乎永远不会同时从多个线程中使用它，因此StringBuffer所做的同步几乎总是不必要的开销。

就我个人而言，我认为StringBuffer在现实世界中没有任何用处。什么时候我想通过操纵字符序列在多个线程之间进行通信?这听起来一点用都没有，但也许我还没有看到光明:)

你是说为了串联吗?

真实世界的例子:您希望从许多其他字符串中创建一个新字符串。

例如，发送消息:

字符串

String s = "Dear " + user.name + "<br>" + 
" I saw your profile and got interested in you.<br>" +
" I'm  " + user.age + "yrs. old too"

StringBuilder

String s = new StringBuilder().append.("Dear ").append( user.name ).append( "<br>" ) 
          .append(" I saw your profile and got interested in you.<br>") 
          .append(" I'm  " ).append( user.age ).append( "yrs. old too")
          .toString()

Or

String s = new StringBuilder(100).appe..... etc. ...
// The difference is a size of 100 will be allocated upfront as  fuzzy lollipop points out.

StringBuffer(语法与StringBuilder完全相同，只是效果不同)

关于

StringBuffer vs. StringBuilder

前者是同步的，后者不是。

因此，如果在一个线程中多次调用它(90%的情况下)，StringBuilder将运行得更快，因为它不会停下来查看它是否拥有线程锁。

因此，建议使用StringBuilder(当然，除非您有多个线程同时访问它，这是很少见的)

字符串连接(使用+操作符)可能会被编译器优化以在下面使用StringBuilder，因此，它不再是需要担心的事情，在Java的早期，这是每个人都说应该不惜一切代价避免的事情，因为每个连接都会创建一个新的String对象。现代编译器不再这样做了，但使用StringBuilder代替它仍然是一个很好的实践，以防您使用“旧”编译器。

edit

对于那些好奇的人来说，这是编译器为这个类做的事情:

class StringConcatenation {
    int x;
    String literal = "Value is" + x;
    String builder = new StringBuilder().append("Value is").append(x).toString();
}

javap -c StringConcatenation

Compiled from "StringConcatenation.java"
class StringConcatenation extends java.lang.Object{
int x;

java.lang.String literal;

java.lang.String builder;

StringConcatenation();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   new #2; //class java/lang/StringBuilder
   8:   dup
   9:   invokespecial   #3; //Method java/lang/StringBuilder."<init>":()V
   12:  ldc #4; //String Value is
   14:  invokevirtual   #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   17:  aload_0
   18:  getfield    #6; //Field x:I
   21:  invokevirtual   #7; //Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
   24:  invokevirtual   #8; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   27:  putfield    #9; //Field literal:Ljava/lang/String;
   30:  aload_0
   31:  new #2; //class java/lang/StringBuilder
   34:  dup
   35:  invokespecial   #3; //Method java/lang/StringBuilder."<init>":()V
   38:  ldc #4; //String Value is
   40:  invokevirtual   #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   43:  aload_0
   44:  getfield    #6; //Field x:I
   47:  invokevirtual   #7; //Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
   50:  invokevirtual   #8; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   53:  putfield    #10; //Field builder:Ljava/lang/String;
   56:  return

}

编号为5 - 27行的字符串名为“literal”

编号为31-53的行用于名为“builder”的字符串

没有区别，对两个字符串执行的代码完全相同。

另外，StringBuffer是线程安全的，而StringBuilder不是。

因此，在实时情况下，当不同的线程正在访问它时，StringBuilder可能会有一个不确定的结果。