String vs StringBuilder vs StringBuffer in Java
String vs StringBuilder vs StringBuffer in Java
--- | String | StringBuffer | StringBuilder |
---|---|---|---|
Syntax | String var = new String(str) | StringBuffer var = new StringBuffer(str); | StringBuilder var = new StringBuilder(str); |
Mutability | immutable | mutable | mutable |
Thread | Safe | Safe | Not Safe |
JDK | 1.0 | 1.0 | 1.5 |
Note | Constant String Pool |
JAVA 中的 StringBuilder 和 StringBuffer 适用的场景是什么?
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开始,用加号拼接字符串已经没有任何性能损失了。
String vs StringBuilder vs StringBuffer in Java
String vs StringBuffer vs StringBuilder
JAVA 中的 StringBuilder 和 StringBuffer 适用的场景是什么?