美文网首页
性能优化之字符串拼接

性能优化之字符串拼接

作者: StrongManAlone | 来源:发表于2018-02-27 20:42 被阅读0次

前言:此篇文章迎来了我写简书之后的第一条评论,必须高度重视,在第一条评论中提到下文中的测试方法是不准确的,会因为jvm常量池,编译优化,jit热点编译等等问题对测试的结果带来影响,的确如此。为了避免留毒于网络,我会找一个空余时间把下面的测试用例改为用jmh框架测试,来排除上述原因带来的影响。特意在此记录一下,之后我会写一篇关于jmh的文章,欢迎订阅。

字符串拼接在开发中经常遇到,可以说是非常常见,也很简单,但是里面也有一些可优化的点,稍不注意就会有不小的性能损耗,总结了一些可以优化的点,和比较迷惑的demo将这些知识点罗列再此:

1.最常用的也是最不推荐的 + :

上面这段字符串拼接代码非常的简单,如果不考虑代码规范,有一处可以优化,(看到此处有人可能会认为我不是眼瞎就是脑瘸) 下面首先看下运行结果,然后我在分析下原因,还有该如何优化。

从上面的结果可以看出      "我要" +"吃肉" +"还要" +"喝汤"    这种字符串拼接竟然出奇的快,起初有点懵,后来看了一下编译后的字节码,找到了原因,编译后的字节码有点多,截取主要部分。

从上面的这段字节码可以清楚明白的看出原因,因为  "我要" +"吃肉" +"还要" +"喝汤"    这种形式的字符串拼接,每个字符串都是常量,所以在编译的时候被优化成了"我要吃肉还要喝汤",而  e = a + b + c + d  这种都是变量的字符创拼接那就只能中规中矩的去拼接了,不过这样形式在编译期间也得到了优化。从上面的字节码可以看出它被优化成了首先构建一个StringBuilder的对象,然后append字符串,最后在来个toString,齐活。虽然编译期间两种方法都做了相应的优化,但是实际效果却也相差十万八千里,到底该如何优化后者呢(注意此优化只针对本段代码,和此种情景)。其实思路非常简单就是用final关键字把上面几个变量声明成常量。到底思路对不对和效果如何,让我带你们见证奇迹。先看编译后的字节码:

从上面这段字节码中可以清楚明白的看出两种形式的字符串拼接编译后的字节码是相同的,不用运行也可以知道结果,字节码都是一样的,效率肯定是一样的,但是还是贴出来结果:

2.StringBuffer:

上图所示的代码才是我们真正要去优化的字符串拼接的场景,首先运行一下看下效果:

从结果可以看出性能差距非常巨大,下面我们看下这段代码编译成字节码文件之后的内容:

从编译后的字节码文件中我们可以轻松的找到性能差距的原因,第一种字符串拼接的方法是在循环之外创建的StringBuffer对象,在循环内部只是重复的调用StringBuffer.append方法而已,而第二种则是在循环内部创建StringBuilder对象,然后先把原先的字符创通过StringBuilder.append方法添加到当前对象中,再把要拼接的字符串通过StringBuilder.append方法添加到当前对象中,在通过StringBuilder.toString得到本次循环拼接之后的字符串。然后在循环内部不断地重复此过程。其实StringBuilder的效率要高于StringBuilder的(具体原因在下一小节讲述)之所以第二种方法的效率低是因为它并没有重复的使用StringBuilder对象,而是每次循环都去创建一个新的StringBuilder对象,相比较第一种方法第二种方法还多了一步把原先的字符串放到对象里面的步骤,还有toString的步骤。在一个简单的循环里面多了这么多步骤,所以造成了性能上的极大差距。平常大家都认为 + 这种字符串拼接方式是低效的其实是不正确的,+ 通过编译优化之后是通过StringBuilder构建字符串的,如果不考虑重复使用对象的话,只是进行单次的字符串拼接的话我认为 + 的方式要比StringBuffer的方式效率还要高(因为StringBuilder的效率高于StringBuffer)。

3.StringBuilder对比StringBuffer:

上一小节我提到了StringBuilder要比StringBuffer的性能更好,接下来分析下原因,首先看下面一段代码:

运行结果如下:

从结果可以看出在字符串拼接方面,StringBuilder确实要比StringBuffer的性能更好,究其原因还是要看下源码的。

首先StringBuilder的append方法:

StringBuffer的append方法:

对比上面两个类中的append方法,我们大概可以看出原因,因为StringBuilder的append方法不是线程安全的,而StringBuffer的append方法则是线程安全的,所以造成了性能上的较大差距。如果仔细阅读这两个类的源码你会发现StringBuilder相比较StringBuffer要简单的多,StringBuilder仿佛就是为高性能而生。

简单的总结下:

1、在单线程或者保证线程安全的情况下使用StringBuilder最优。

2、在并发情况下不保证线程安全则使用StringBuffer,因为他的大多数方法都是同步方法,已经保证线程安全了。

3、想要提高性能尽可能的复用那些用于构建字符串的对象。

相关文章

  • StringBuilder性能优化

    在String字符串拼接性能优化博客中我已经介绍过了String "+" 拼接背后的StringBuilder实现...

  • 性能优化之字符串拼接

    前言:此篇文章迎来了我写简书之后的第一条评论,必须高度重视,在第一条评论中提到下文中的测试方法是不准确的,会因为j...

  • golang 几种字符串的连接方式

    最近在做性能优化,有个函数里面的耗时特别长,看里面的操作大多是一些字符串拼接的操作,而字符串拼接在 golang ...

  • 用数据告诉你Java字符串拼接谁的效率高

    撸代码的时候拼接字符串是很常见的,使用合适的拼接方式可以节约资源,优化性能,接下来我们进行一下比较。 当 num ...

  • 日志、字符串拼接

    关于字符串拼接效率: 单词调用字符串拼接性能 + > strings.Join > bytes.Buffer > ...

  • go语言string之Buffer与Builder

    操作字符串离不开字符串的拼接,但是Go中string是只读类型,大量字符串的拼接会造成性能问题。 字符串拼接的方式...

  • String字符串拼接性能优化

    前言: java.lang.String拼接操作是很常见的操作,这篇blog主要分析一下String拼接操作的性能...

  • 字符串

    一、字符串格式化 String.format()的使用 二、字符串拼接 字符串拼接性能比较 三、日志打印效率 使用...

  • 你所不知道的Java性能优化之String!

    Java性能优化之String字符串优化 1.字符串对象及其特点 Java中八大基本数据类型没有String类型,...

  • MS(4):Android之性能优化篇

    六、性能及优化 1、App优化之性能分析工具 Android App优化之性能分析工具 2、ListView优化 ...

网友评论

      本文标题:性能优化之字符串拼接

      本文链接:https://www.haomeiwen.com/subject/xhppxftx.html