java.lang包—StringBuffer类和StringBuilder类

目录

一、数据结构

二、线程安全性分析

三、源码

四、适用场景

---

一、数据结构

在 Java 中字符串属于对象，Java 提供了 String 类来创建和操作字符串。String 类是不可变类，即一旦一个 String 对象被创建以后，包含在这个对象中的字符序列是不可改变的，直至这个对象被销毁。Java 提供了两个可变字符串类 StringBuffer 和 StringBuilder，中文翻译为“字符串缓冲区”。StringBuilder 类是 JDK 1.5 新增的类，它也代表可变字符串对象。实际上，StringBuilder 和 StringBuffer 功能基本相似，方法也差不多。不同的是，StringBuffer 是线程安全的，而 StringBuilder 则没有实现线程安全功能，所以性能略高。因此在通常情况下，如果需要创建一个内容可变的字符串对象，则应该优先考虑使用 StringBuilder 类。StringBuffer、StringBuilder、String 中都实现了 CharSequence 接口。CharSequence 是一个定义字符串操作的接口，它只包括 length()、charAt(int index)、subSequence(int start, int end) 这几个 API。StringBuffer、StringBuilder、String 对 CharSequence 接口的实现过程不一样，如下图 1 所示：

图 1  对CharSequence接口的实现

 

二、线程安全性分析

对待线程安全问题，我们可以把一个字符串的改变看成两部来实现，

1. 首先就是字符串的索引位置存放元素 *
2. 然后继续增大Size的值。

在单线程的情况下如果size等于0，那么添加一个元素的步骤就是将元素放在位置0，然后size=1，在单线程中这样做是没有任何问题的。但是多线程的话，线程a将元素放在位置0，此时的线程B也在抢夺CPU，假设抢夺成功， 那么这个时候a线程的size还没有运行到增加的那一步 ，同时b线程在位置0又放入一个元素，这就回将a线程放入的元素覆盖掉， 所以我们来看看实际的情况就是两个元素都是放在位置0但是实际元素只有一个，size却等于2，这就造成了线程不安全的问题。

三、源码

1、StringBuffer

StringBuffer buffer= new StringBuffer();
buffer.append("d");

进入append

@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

函数被synchronized修饰，说明是有线程安全的

2、StringBuilder

StringBuilder builder= new StringBuilder();
builder.append("1");

@Override
public StringBuilder append(String str) {
    super.append(str);
    return this;
}

没有synchronized,不是线程安全

3、扩展因子

public AbstractStringBuilder append(String str) {
    if (str == null)
        return appendNull();
        int len = str.length();
        ensureCapacityInternal(count + len);
        str.getChars(0, len, value, count);
        count += len;
        return this;
}

其实如果没有synchronize的话，在count+=len不安全，所以如果并发比较大，尽量少用stringBuilder

四、适用场景

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

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

读后有收获可以支付宝请作者喝奶茶