JAVA 中的 StringBuilder 和 StringBuffer 适用的场景是什么？

 

JAVA 中的 StringBuilder 和 StringBuffer 适用的场景是什么？

最简单的回答是，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 开始，用加号拼接字符串已经没有任何性能损失了。

如诸多评论所指出的，我上面说，"用加号拼接字符串已经没有任何性能损失了"并不严谨，严格的说，若是没有循环的状况下，单行用加号拼接字符串是没有性能损失的，java 编译器会隐式的替换成 stringbuilder，但在有循环的状况下，编译器无法作到足够智能的替换，仍然会有没必要要的性能损耗，所以，用循环拼接字符串的时候，仍是老老实实的用 stringbuilder 吧。

 

http://www.runoob.com/java/java-stringbuffer.html