忘记StringBuffer，StringBuilder翻身战

学习Java，肯定或多或少在某系地方看到过String，StringBuilder，StringBuffer三者的比较

下面给出一个”标准答案“：

StringBuilder 不是线程安全的；

StringBuffer 是线程安全的，内部使用 synchronized 进行同步，速度慢于StringBuilder；

String内部实现使用final,且没有更改的内部方法,所以String 不可变；

为什么这里的标准要打引号呢？

首先，上面的说法，是没有错误的。

但是，离开现实谈理论就是扯淡；没有错不代表 正确；

实际的实现中，我们使用String的append。除了要求 能够正确append，顺序也很重要；

虽然研表究明，汉字的序顺并不能影响读阅；但是实际使用中我们必须保证String的append是合理有意义的 ；

StringBuffer的加锁，保证类append过程中不出现错误。但是，并不能保证外部添加的顺序；

这样乍一看是句废话。你外部添加顺序当然不可能由底层实现来保证啊；

但是，仔细想想，如果我外部添加顺序不能保证，你内部同步机制做的再好，那也没有用啊。

所以，如果我们需要正确的append操作，那就需要外部调用时候进行加锁，把锁锁在业务层面；

这样一来，问题出现了。。我外部既然已经加锁了，为什么还需要你内部加锁，这不是脱裤子放屁，多次一举吗。。

 

 

因此，我们为了正确进行append操作，往往需要在外部进行加锁，所以，StringBuffer陷入一个很尴尬的境地，速度吧，没有StringBuilder快。安全性吧，比Builder高，但是有限。想安全的使用还是得靠外部锁。因此下次如果被面试官问StringBuffer和StringBuilder的区别，你可以最后轻轻补上一刀，StringBuffer就是个SB，谁用谁SB。

光说不练假把式，下面我们来通过一个Demo来展示一下；

上图对StringBuilder1 号2号，执行相同操作，通过length来比较，验证线程的不安全

可以看到一个结果是288832.一个是288861.证明其中的某n次append由于并发冲突导致写入值的丢失；

让我们看看StringBuffer的结果

我们的打印结果是并不是我们预期的ABCD后面加上0到9，所以，StringBuffer只能保证append操作成功。

这个时候，你还敢和电脑说汉字的顺序不影响阅读吗。。。那可真的需要祭天了。。

 

此外，在jdk1.5开始，用加号拼接字符串已经没有任何性能损失了。

如果没有循环的情况下，单行用加号拼接字符串是没有性能损失的，java编译器会隐式的替换成stringbuilder。

但在有循环的情况下，编译器没法做到足够智能的替换，仍然会有不必要的性能损耗，因此，用循环拼接字符串时，还是老老实实的用stringbuilder；