String Buider 在什么条件下、如何使用效率更高？

拼搏现实的明天。 2021-09-01 04:54 273阅读 0赞

点击上方 [Java后端][Java]，选择 设为星标

优质文章，及时送达

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

作者：后青春期的Keats 地址：https://www.cnblogs.com/keatsCoder/

## **引言** ##

都说 StringBuilder 在处理字符串拼接上效率要强于 String，但有时候我们的理解可能会存在一定的偏差。最近我在测试数据导入效率的时候就发现我以前对 StringBuilder 的部分理解是错误的。后来我通过实践测试 + 找原理 的方式搞清楚了这块的逻辑。现在将过程分享给大家

### **测试用例** ###

我们的代码在循环中拼接字符串一般有两种情况

*  第一种就是每次循环将对象中的几个字段拼接成一个新字段，再赋值给对象
 *  第二种操作是在循环外创建一个字符串对象，每次循环向该字符串拼接新的内容。循环结束后得到拼接好的字符串

对于这两种情况，我创建了两个对照组

第一组：

在每次 For 循环中拼接字符串，即拼即用、用完即毁。分别使用 String 和 StringBuilder 拼接

public static void useString(){
            for (int i = 0; i < CYCLE_NUM_BIGGER; i++) {
                String str = str1 + i + str2 + i + str3 + i + str4 ;
            }
        }
    
        
        public static void useStringBuilder(){
            for (int i = 0; i < CYCLE_NUM_BIGGER; i++) {
                StringBuilder sb = new StringBuilder();
                String s = sb.append(str1).append(i).append(str2).append(i).append(str3).append(i).append(str4).toString();
            }
        }

``第二组：

多次 For 循环拼接一个字符串，循环结束后使用字符串，使用后由垃圾回收器回收。也是分别使用 String 和 StringBuilder 拼接

public static void useStringSpliceOneStr (){
            String str = "";
            for (int i = 0; i < CYCLE_NUM_LOWER; i++) {
                str += str1 + str2 + str3 + str4 + i;
            }
        }
    
        
        public static void useStringBuilderSpliceOneStr(){
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < CYCLE_NUM_LOWER; i++) {
                sb.append(str1).append(str2).append(str3).append(str4).append(i);
            }
        }

为了保证测试质量，在每个测试项目进行前。线程休息 2s，之后空跑 5 次热身。最后执行 5 次求平均时间的方式计算时间

public static int executeSometime(int kind, int num) throws InterruptedException {
            Thread.sleep(2000);
            int sum = 0;
            for (int i = 0; i < num + 5; i++) {
                long begin = System.currentTimeMillis();
    
                switch (kind){
                    case 1:
                        useString();
                        break;
                    case 2:
                        useStringBuilder();
                        break;
                    case 3:
                        useStringSpliceOneStr();
                        break;
                    case 4:
                        useStringBuilderSpliceOneStr();
                        break;
                    default:
                        return 0;
                }
    
                long end = System.currentTimeMillis();
    
                if(i > 5){
                    sum += (end - begin);
                }
            }
            return sum / num;
        }

主方法

public class StringTest {
        public static final int CYCLE_NUM_BIGGER = 10_000_000;
        public static final int CYCLE_NUM_LOWER = 10_000;
        public static final String str1 = "张三";
        public static final String str2 = "李四";
        public static final String str3 = "王五";
        public static final String str4 = "赵六";
    
    
        public static void main(String[] args) throws InterruptedException {
            int time = 0;
            int num = 5;
    
            time = executeSometime(1, num);
            System.out.println("String拼接 "+ CYCLE_NUM_BIGGER +" 次，" + num + "次平均时间：" + time + " ms");
    
            time = executeSometime(2, num);
            System.out.println("StringBuilder拼接 "+ CYCLE_NUM_BIGGER +" 次，" + num + "次平均时间：" + time + " ms");
    
            time = executeSometime(3, num);
            System.out.println("String拼接单个字符串 "+ CYCLE_NUM_LOWER +" 次，" + num + "次平均时间：" + time + " ms");
    
            time = executeSometime(4, num);
            System.out.println("StringBuilder拼接单个字符串 "+ CYCLE_NUM_LOWER +" 次，" + num + "次平均时间：" + time + " ms");
    
        }
    }

### 测试结果 ###

测试结果如下

![format_png][]

### 结果分析 ###

#### 第一组 ####

10\_000\_000 次循环拼接，在循环内使用 String 和 StringBuilder 的效率是一样的！为什么呢？

使用 `javap -c StringTest.class` 反编译查看两个方法编译后的文件：

![format_png 1][]

可以发现 String 方法拼接字符串编译器优化后使用的就是 StringBuilder、因此用例1 和用例2 的效率是一样的。

#### 第二组 ####

第二组的结果就是大家喜闻乐见的了，由于 10\_000\_000 次循环String 拼接实在太慢所以我采用了 10\_000 次拼接来分析。

分析用例3：虽然编译器会对 String 拼接做优化，但是它每次在循环内创建 StringBuilder 对象，在循环内销毁。下次循环他有创建。相比较用例4在循环外创建，多了 n 次 new 对象、销毁对象的操作、n - 1 次将 StringBuilder 转换成 String 的操作 。效率低也是理所应当了。

#### 扩展 ####

第一组的测试还有一种写法：

public static void useStringBuilderOut(){
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < CYCLE_NUM_BIGGER; i++) {
    
                sb.delete(0, sb.length());
                String s = sb.append(str1).append(i).append(str2).append(i).append(str3).append(i).append(str4).toString();
            }
        }

循环外创建 StringBuilder 每次循环开始的时候清空 StringBuilder 的内容然后拼接。这种写法无论使用 sb.setLength(0); 还是 sb.delete(0, sb.length()); 效率都比直接在循环内使用 String / StringBuilder 慢。奈何才疏学浅我一直想不明白为什么他慢。我猜测是 new 对象的速度比重置长度慢，于是这样测试了以下：

public static void createStringBuider() {
            for (int i = 0; i < CYCLE_NUM_BIGGER; i++) {
                StringBuilder sb = new StringBuilder();
            }
        }
    
        public static void cleanStringBuider() {
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < CYCLE_NUM_BIGGER; i++) {
                sb.delete(0, sb.length());
            }
        }

但是结果是 cleanStringBuider 更快。让我摸不着头脑

**如果有大神看到希望可以帮忙分析分析**

### **结论** ###

*  编译器会将 String 拼接优化成使用 StringBuilder，但是还是有一些缺陷的。主要体现在循环内使用字符串拼接，编译器不会创建单个 StringBuilder 以复用
 *  对于多次循环内拼接一个字符串的需求：StringBuilder 很快，因为其避免了 n 次 new 对象、销毁对象的操作，n - 1 次将 StringBuilder 转换成 String 的操作
 *  StringBuilder 拼接不适用于循环内每次拼接即用的操作方式。因为编译器优化后的 String 拼接也是使用 StringBuilder 两者的效率一样。后者写起来还方便...

**- END -**

最近整理一份面试资料**《Java技术栈学习手册》**，覆盖了Java技术、面试题精选、Spring全家桶、Nginx、SSM、微服务、数据库、数据结构、架构等等。

获取方式：点“ **在看**，关注公众号 **Java后端** 并回复 **777** 领取，更多内容陆续奉上。

**推****荐****阅****读 **

***1.*** [Docker 部署不香吗？][Docker]

***2. ***[DataGrip 上手体验，真香！][DataGrip]

***3.*** [15000 字的 SQL 语句大全][15000 _ SQL]

***4.*** [为什么不建议把数据库部署在 Docker 容器内？][Docker 1]

***5.*** [创业公司搭建自己的技术架构][Link 1]

![format_png 2][]

**喜****欢****文****章****，****点****个****在看 **![format_png 3][]

[Java]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0da17bf97a286df119047a25b7de51621fe542816673bb4aa3ebd8ab97b09a86ed7db2e2ee&idx=3&mid=2247489272&scene=21&sn=ce74938072fc73a808d83ccb474db46d#wechat_redirect
[format_png]: /images/20210730/dfe978496b104cb9b2f2791d56bafdcc.png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9vVEtIYzZGOHRzZ1BMaWExMXBQeHZKb0dXaWNCM2JpY0xRYjh3aWJhOVhCYUxQV3R1Qm0zWDA0MWZUeTNpYmp0ZUlQTEtndGFlUTJ6Y2ljZ0Z1MnRYNFR5eGljekEvNjQw?x-oss-process=image/format,png
[Docker]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e4b04f979c2127522c757d1d26fb1422aa94233686b2bad753555d41dbe3b552b3396fd13&idx=1&mid=2247498887&scene=21&sn=5d07989c92f61c486ed708722a3719aa#wechat_redirect
[DataGrip]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e4c73f979c565704003100a1f556f4203757373df1e469f865352a6b5e03f2c7865ad8385&idx=2&mid=2247498736&scene=21&sn=38f2f9d05a64882448cc0065723842b1#wechat_redirect
[15000 _ SQL]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e4ca6f979c5b0ccf6f2944a0d63b966e9d65f862cbe38ca91b256760a7cffb491206004fc&idx=1&mid=2247498533&scene=21&sn=3cd9b05080bfff3d3e0481eb2410c92d#wechat_redirect
[Docker 1]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e4ca6f979c5b09210feaae49bff6c08afdc674304cc0d9fb5f998bf3138070a2c514fb535&idx=3&mid=2247498533&scene=21&sn=3dc150ffd672b6c02a077738b0dfe43e#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e4d61f979c477efe4ee056fa654dc3f1a2cfc54b8ab8e36736d19d11219a06bb79b39b2c8&idx=3&mid=2247498466&scene=21&sn=04f1be4ce690d2b6bf4b42f791b34ed6#wechat_redirect
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9vVEtIYzZGOHRzaGlhRVQyZVMwU2NnRXM5ejl6dTdpYU9EWjRiYkxmRUkwNmQ3ZE5RaWNTalR4YjFGWWNaUVVWcm9saWJXRE41WWliMWliUXZ6NnFCaWNEOGJJeXcvNjQw?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9DMXVETURxam4xOXd0dVFwSzNqbUpXM2JGR1dJOFl6NkZSMTd0bDFNRjhWZnFZeFB4OTkwa3YySjc0THZxd2liMjZLYXlIZE9YZDZlYnpycVlpYmJUand3LzY0MA?x-oss-process=image/format,png