最近学习到StringBuffer，心中有好些疑问，搜索了一些关于String，StringBuffer，StringBuilder的东西，现在整理一下。
关于这三个类在字符串处理中的位置不言而喻，那么他们到底有什么优缺点，到底什么时候该用谁呢？下面我们从以下几点说明一下
1.三者在执行速度方面的比较：StringBuilder > StringBuffer > String
2.String <（StringBuffer，StringBuilder）的原因
String：字符串常量
StringBuffer：字符串变量
StringBuilder：字符串变量
从上面的名字可以看到，String是“字符创常量”，也就是不可改变的对象。对于这句话的理解你可能会产生这样一个疑问 ，比如这段代码：
1 String s = "abcd"; 2 s = s+1; 3 System.out.print(s);// result : abcd1
我们明明就是改变了String型的变量s的，为什么说是没有改变呢? 其实这是一种欺骗，JVM是这样解析这段代码的：首先创建对象s，赋予一个abcd，然后再创建一个新的对象s用来 执行第二行代码，也就是说我们之前对象s并没有变化，所以我们说String类型是不可改变的对象了，由于这种机制，每当用String操作字符串时，实际上是在不断的创建新的对象，而原来的对象就会变为垃圾被ＧＣ回收掉，可想而知这样执行效率会有多底。
而StringBuffer与StringBuilder就不一样了，他们是字符串变量，是可改变的对象，每当我们用它们对字符串做操作时，实际上是在一个对象上操作的，这样就不会像String一样创建一些而外的对象进行操作了，当然速度就快了。
3.一个特殊的例子：
1 String str = “This is only a” + “ simple” + “ test”; 3 StringBuffer builder = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”);
你会很惊讶的发现，生成str对象的速度简直太快了，而这个时候StringBuffer居然速度上根本一点都不占优势。其实这是JVM的一个把戏，实际上：
String str = “This is only a” + “ simple” + “test”;
其实就是：
String str = “This is only a simple test”;
所以不需要太多的时间了。但大家这里要注意的是，如果你的字符串是来自另外的String对象的话，速度就没那么快了，譬如：
String str2 = “This is only a”;
String str3 = “ simple”;
String str4 = “ test”;
String str1 = str2 +str3 + str4;
这时候JVM会规规矩矩的按照原来的方式去做。
4.StringBuilder与 StringBuffer
StringBuilder：线程非安全的
StringBuffer：线程安全的
当我们在字符串缓冲去被多个线程使用是，JVM不能保证StringBuilder的操作是安全的，虽然他的速度最快，但是可以保证StringBuffer是可以正确操作的。当然大多数情况下就是我们是在单线程下进行的操作，所以大多数情况下是建议用StringBuilder而不用StringBuffer的，就是速度的原因。
对于三者使用的总结： 1.如果要操作少量的数据用 = String
2.单线程操作字符串缓冲区 下操作大量数据 = StringBuilder
3.多线程操作字符串缓冲区 下操作大量数据 = StringBuffer
关于安全性的问题（引自知乎）
链接：https://www.zhihu.com/question/20101840/answer/164866159
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
我不知道为什么这个这么老的问题会出现在我的时间线上，看了一下回答，大多是2012，2013年的回答，照说那个年代，有些历史故事还很新鲜，却不知道为什么没有一个答案说到点子上。
stringbuffer固然是线程安全的，stringbuffer固然是比stringbuilder更慢，固然，在多线程的情况下，理论上是应该使用线程安全的stringbuffer的。
然而，然而，然而，有谁给我一个实际的案例来显示你需要一个线程安全的string拼接器？对不起，至少在我浅薄的十几年编程生涯中还没有遇到过，也许，仅仅是也许，这个地球上的确是存在这样的编程需求的，然而，它至少跟99.99...99%的程序员是无关的。
所以，对于题主的问题，他们的适用场景是什么?最简单的回答是，stringbuffer基本没有适用场景，你应该在所有的情况下选择使用stringbuiler，除非你真的遇到了一个需要线程安全的场景，如果遇到了，请务必在这里留言通知我。
然后，补充一点，关于线程安全，即使你真的遇到了这样的场景，很不幸的是，恐怕你仍然有99.99....99%的情况下没有必要选择stringbuffer，因为stringbuffer的线程安全，仅仅是保证jvm不抛出异常顺利的往下执行而已，它可不保证逻辑正确和调用顺序正确。大多数时候，我们需要的不仅仅是线程安全，而是锁。
最后，为什么会有stringbuffer的存在，如果真的没有价值，为什么jdk会提供这个类？答案太简单了，因为最早是没有stringbuilder的，sun的人不知处于何种愚蠢的考虑，决定让stringbuffer是线程安全的，然后大约10年之后，人们终于意识到这是一个多么愚蠢的决定，意识到在这10年之中这个愚蠢的决定为java运行速度慢这样的流言贡献了多大的力量，于是，在jdk1.5的时候，终于决定提供一个非线程安全的stringbuffer实现，并命名为stringbuilder。顺便，javac好像大概也是从这个版本开始，把所有用加号连接的string运算都隐式的改写成stringbuilder，也就是说，从jdk1.5开始，用加号拼接字符串已经没有任何性能损失了。