java stringbuffer长度限制_参加了这么多面试，还是不懂StringBuffer和StringBuilder的区别？...

最新推荐文章于 2024-08-20 21:42:11 发布

weixin_39837041

最新推荐文章于 2024-08-20 21:42:11 发布

阅读量1.4k

点赞数

文章标签： java stringbuffer长度限制指针和固定大小缓冲区只能在不安全的上下文使用

StringBuffer

在实际开发中使用 String 类会存在一个问题，String 对象一旦创建，其值是不能修改的，如果要修改，会重新开辟内存空间来存储修改之后的对象，即修改了 String 的引用。因为 String 的底层是用数组来存值的，数组长度不可改变这一特性导致了上述问题，所以如果开发中需要对某个字符串进行频繁的修改，使用 String 就不合适了，会造成内存空间的浪费，如何解决这个问题呢？

可以使用 StringBuffer 类来解决，当对字符串对象进行频繁修改时，使用 StringBuffer 可以极大提升程序的效率，我们通过下面这个例子一测便知。

分别定义 String 和 StringBuffer 类型的字符串对象，对它们进行值的累加操作，循环执行 50000 次，然后统计各自的耗时，代码如下所示。

//String

运行结果分别如下图所示。

可以看到 String 类型耗时 1345 毫秒，StringBuffer 类型耗时只有 7 毫秒，速度提升了近 200 倍。

接下来我们就来详细学习 StringBuffer 类。

StringBuffer 和 String 类似，底层也是用一个数组来存储字符串的值，并且数组的默认长度为 16，即一个空的 StringBuffer 对象，数组长度为 16，如下图所示。

实例化一个 StringBuffer 对象即创建了一个大小为 16 个字符的字符串缓冲区。

当我们调用有参构造创建一个 StringBuffer 对象时，数组长度就不是 16 了，而是根据当前对象的值来决定数组的长度，“值的长度+16”作为数组的长度，如下图所示。

创建了一个字符串缓冲区，该缓冲区初始值为指定的字符串。字符串缓冲区的初始容量为字符串参数的长度+16。

我们可以看到带参构造中依次执行了两步操作：super(str.length()+16)、append(str)，这也就很清楚的说明了 StringBuffer 的创建过程，先创建一个长度为"str长度+16"的字符串缓冲区，然后把 str 的值追加到此字符串序列中。

所以一个 StringBuffer 创建完成之后，有 16 个字符的空间可以对其值进行修改。如果修改的值范围超出了 16 个字符，则调用 ensureCapacityInternal() 方法检查 StringBuffer 对象的原 char 数组的容量能不能装下新的字符串，如果装不下则对 char 数组进行扩容。

扩容的逻辑就是创建一个新的 char 数组，newCapacity() 方法用于确定新容量大小，将现有容量大小扩大一倍再加上2，如果还是不够大则直接等于需要的容量大小。

扩容完成之后，再调用 Arrays.copyOf() 方法完成数据拷贝，底层调用 System.arryCopy() 方法将原数组的内容复制到新数组，最后将指针指向新的 char 数组。

StringBuffer 常用方法

具体代码如下所示。

StringBuffer

运行结果如下图所示。

StringBuilder

StringBuilder 和 StringBuffer 是一对兄弟，因为它们拥有同一个父类 AbstractStringBuilder，同时实现的接口也是完全一样，都实现了 java.io.Serializable, CharSequence 两个接口，如下图所示。

那它们有什么区别呢？最大的区别在于 StringBuffer 对几乎所有的方法都实现了同步，StringBuilder 没有实现同步，如同样是对 AbstractStringBuilder 方法 append 的重写，StringBuffer 添加了 synchronized 关键字修饰，而 StringBuilder 没有，如下图所示。

所以 StringBuffer 是线程安全的，在多线程系统中可以保证数据同步，而 StringBuilder 无法保证线程安全，所以多线程系统中不能使用 StringBuilder。

但是方法同步需要消耗一定的系统资源，所以 StringBuffer 虽然安全，但是效率不如 StringBuilder，也就是说使用 StringBuilder 更快，我们还是用上面的例子做一个测试。

分别定义 StringBuffer 和 StringBuilder 类型的字符串对象，对它们进行值的累加操作，循环执行 500000 次，然后统计各自的耗时，代码如下所示。

//StringBuffer

运行结果分别如下图所示。

通过结果可以看到，同样是执行 50 万次操作，StringBuffer 耗时 45 毫秒，而 StringBuilder 耗时 34 毫秒，相差虽然不是很大，但是 StringBuilder 效率确实要高于 StringBuffer，但是安全性不如 StringBuffer。

所以，在需要考虑线程安全的场景下我们可以使用 StringBuffer，不需要考虑线程安全，追求效率的场景下可以使用 StringBuilder。

StringBuilder 的具体使用如下所示。

StringBuilder

运行结果如下图所示。

StringBuilder 为什么线程不安全？

我们通过一个例子来测试，代码如下所示。

StringBuilder

开启 10 个线程，每个现象对 stringBuilder 添加 1000 个 'a'，操作完成之后，stringBuilder 的长度应该是 10*1000 = 10000，但是我们看到多次运行的结果如下。

长度比 10000 小（也有可能等于 10000，概率较小），同时也可能会抛出数组下标越界的异常，证明 StringBuilder 确实是线程不安全的，为什么是这样呢？我们查看源码来分析。

StringBuilder 的 append() 方法底层调用 AbstractStringBuilder 的 append() 方法，如下所示。

count 为字符串长度，len 为追加的字符串长度，count += len 这行代码如果是多线程同时访问，很可能会出现数据错误，比如 count = 0，len = 1，两个线程同时执行到这一行，获取的 count 都是 0，执行的结果都是 1，所以最终 count 的值为 1，而不是 2，这就解释了为什么最终的长度有可能比预期结果小的原因。

再来说说为什么会抛出数组下标越界异常？

字符的添加是通过调用 putStringAt(count,str) 方法完成的，count 为当前字符串的长度，通过 ensureCapacityinternal(count+len) 方法对数组进行扩容之后，它一定是小于等于数组最大容量的，putStringAt(count,str) 方法中每添加一个字符，都会给 count 加 1，当到达数组长度上限之后再进行扩容。

但是如果是两个线程同时执行 putStringAt(count,str)，假设此时的 count = 3，数组容量为 4，两个线程拿到的 count 都为 3，数组容量大于 count，所以并不会进行扩容，这就意味着只剩一个空间，要插入两个字符，线程 A 执行完毕，count 变为 4，已经占满了整个数组，所以线程 B 执行的时候，超出了数组的长度，抛出异常。