那么为什么StringBuilder的性能比StringBuffer的高呢？这 则与线程安全有关。如果你读过《Think in Java》，而且对里面描述HashTable和HashMap区别的那部分章节比较熟悉的话，你一定也明白了原因所在。对，就是支持线程同步保证线程安 全而导致性能下降的问题。HashTable是线程安全的，很多方法都是synchronized方法，而HashMap不是线程安全的，但其在单线程程 序中的性能比HashTable要高。StringBuffer和StringBuilder类的区别也在于此，新引入的StringBuilder类不 是线程安全的，但其在单线程中的性能比StringBuffer高。

String str="You are nice.";
str+="I love you so much.";

如果用StringBuffer类的话，代码如下：

StringBuffer str= new StringBuffer("You are nice.");
str.append("I love you so much.");

从表面看来String类只用一个加号（+）便完成了字符串的拼接，而StringBuffer类却要调用一个append()方法，是否实现起来更简洁，更单纯呢？其实不然，让我们了解一下程序运行内部发生了哪些事情：Struts与Struts2的区别

经编译后程序的bytecode（字节码）展示出了实质： 在用String类对象直接拼接时，JVM会创建一个临时的StringBuffer类对象，并调用其append()方法完成字符串的拼接，这是因为 String类是不可变的，拼接操作不得不使用StringBuffer类（并且－－JVM会将"You are nice."和"I love you so much."创建为两个新的String对象）。之后，再将这个临时StringBuffer对象转型为一个String，代价不菲！可见，在这一个简单 的一次拼接过程中，我们让程序创建了四个对象：两个待拼接的String，一个临时StringBuffer，和最后将StringBuffer转型成为 的String－－它当然不是最初的str了，这个引用的名称没变，但它指向了新的String对象。

而如果直接使用StringBuffer类，程序将只产生两个对象：最初的StringBuffer和拼接时的String（"I love you so much."），也不再需要创建临时的StringBuffer类对象而后还得将其转换回String对象。

可以想象，当我们的字符串要被循环拼接若干段时，用String类直接操作会带来多少额外的系统开销，生成多少无用的临时StringBuffer对象，并处理多少次无谓的强制类型转换哪。