性能优化之字符串拼接

前言:此篇文章迎来了我写简书之后的第一条评论,必须高度重视,在第一条评论中提到下文中的测试方法是不准确的,会因为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、想要提高性能尽可能的复用那些用于构建字符串的对象。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,117评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,963评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,897评论 0 240
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,805评论 0 203
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,208评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,535评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,797评论 2 311
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,493评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,215评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,477评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,988评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,325评论 2 252
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,971评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,807评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,544评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,455评论 2 266

推荐阅读更多精彩内容