为什么String和StringBuilder相比,String这么慢?

喜欢ヅ旅行 2022-02-01 03:45 314阅读 0赞

### 存储的时的区别. ###

先来看看各自都是如何存储的

#### String ####

![在这里插入图片描述][20190513113438319.png]

#### StringBuilder ####

StringBuffer继承自AbstractStringBuilder,自身没有定义存储的容器,而是继承了其父类的容器![在这里插入图片描述][20190513113453716.png]

这个就是StringBuilder存储字符的地方

> 从上面看出,**String的字符是存储在一个被final修饰的char数组(类似于c中的指针常量)中的,而StringBuilder的字符是存储在一个普通的char数组**中的

--------------------

### 运算时的区别 ###

#### String的运算 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW5rZWRpbmc5MzUw_size_16_color_FFFFFF_t_70]

这两个相加的操作可以看作这样

final char c1[] = { '第','一','个','字','符','串'};
    
    final char c2[] = { '第','二','个','字','符','串'};
    
    final char c3[] = new char[12];
    
    c3[] =  { '第','一','个','字','符','串','第','二','个','字','符','串'};
    
    c1 = c3
    
    //这段只做理解

String在运算的时候都会**创建一个大小合适的char数组\[\]**,所以当下次再拼接的时候都要进行重新分配.

#### StringBuilder的运算 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW5rZWRpbmc5MzUw_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW5rZWRpbmc5MzUw_size_16_color_FFFFFF_t_70 2]  
**StringBuilder特征**

*  StringBuilder初始化容量是16(无参构造)
 *  追加之前会计算一次容量,大于所需容量则会重新创建一个char\[\]数组,计算规则是 **newCapacity = (value.length << 1) + 2;** 也就是 原来长度\*2+2
 *  StringBuilder在运算的时候每次会计算容量是否足够,如果所需容量不小于自身容量,那么就会重新分配一个自身容量两倍+2的char\[\].所以省去了很多创建char\[\]的次数.

### 大白话结论 ###

*  String之所以慢是因为,大部分cpu资源都被浪费在分配资源,拷贝资源的部分了,相比StringBuilder有更多的内存消耗.
 *  StringBuilder快就快在,相比String,他在运算的时候分配内存次数小,所以拷贝次数和内存占用也随之减少.
 *  由于GC的机制,即便原来的char\[\]没有引用了,那么也得等到GC触发的时候才能回收,String运算过多的时候就会产生大量垃圾,消耗内存.

### 建议 ###

*  如果目标字符串需要大量拼接的操作,那么这个时候应当使用StringBuilder.
 *  反之,如果目标字符串操作次数极少,或者是常量,那么就直接使用String.

[20190513113438319.png]: /images/20220201/2a1c7a16de6d44508732b8ab62a2b4ae.png
[20190513113453716.png]: /images/20220201/fcc298a2e6d04c9b9ab2860014e06ff2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW5rZWRpbmc5MzUw_size_16_color_FFFFFF_t_70]: /images/20220201/ab6a83df9f274fcb8b66ea7427ef0711.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW5rZWRpbmc5MzUw_size_16_color_FFFFFF_t_70 1]: /images/20220201/3c6ba5b7cb2a46b08c7d1bc9a90b1176.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW5rZWRpbmc5MzUw_size_16_color_FFFFFF_t_70 2]: /images/20220201/991cfcb7bc0e46c8a0ad1dbc6d38c64f.png