String拼接也有用加号更好的时候

时间 2019-11-17

标签 string 拼接有用加号更好时候繁體版

原文原文链接

作String拼接时用StringBuilder(或StringBuffer)好仍是直接用+号性能好？通常来讲是前者，不过也有用加号略好的时候。
首先我一直认为用+号有很好的可读性，并且当String拼接在一个等式时，即形如
String s = “abc” + s2 + s3
jdk的实现原理也是转换为一个StringBuilder并一直append，效率也是差不太多的，因此我是比较喜欢在无循环或条件分支代码的状况下全使用String相加，若是有循环或分支，就是写成这样:java

StringBuilder hql =newStringBuilder(“select…………..”
+“  from”
+”  where”);
      If(xxxx){
      Hql.append(“xxxx”);
      }web

不过你们的代码通常都是全append方式，代码一写能够写出几百行，写的时候很差写，改的时候很差读，真有点看不过去了。
今天特别对两种拼接方式作了一下测试，来给你们一个参考。
找到项目中一个约200行的hql拼接，将append全转化为+号，如图sql

测试代码：

publicstaticvoid testStringJoin(){
      TestStringJoin instance =newTestStringJoin();
      longbegin, elapse;
      begin=System.currentTimeMillis();
      int execTimes =10000;
      for(int i =0; i < execTimes; i++){
         instance.testStringJoinWithPlus();
      }
      elapse =System.currentTimeMillis()-begin;
      System.out.println("testStringJoinWithPlus "+ execTimes
            +" times elapse = "+ elapse +"ms");

      begin=System.currentTimeMillis();
      for(int i =0; i < execTimes; i++){
         instance.testStringJoinWithStringBuilder();
      }
      elapse =System.currentTimeMillis()-begin;
      System.out.println("testStringJoinWithStringBuilder "+ execTimes
            +" times elapse = "+ elapse +"ms");
}app

结果：
testStringJoinWithPlus 10000 times elapse = 77ms
testStringJoinWithStringBuilder 10000 times elapse = 151ms （这里有StringBuilder扩容问题，见下面继续分析）函数

基本上可保持后者约为前者2倍时间的状况，也就是说，用StringBuilder拼接字符串有时候还不如直接用+号拼接。
为啥呢？对比了一下两方法的中间代码，只取一小段就能够看出问题了
用StringBuilder拼接字符串的方式：性能

Code:
0:new#2; //class java/lang/StringBuilder
3: dup
4: sipush 5000
7: invokespecial #3; //Method java/lang/StringBuilder."<init>":(I)V
10: astore_1
11: aload_1
12: ldc #4; //String SELECT
14: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
17: pop
18: aload_1
19: ldc #6; //String new map(
21: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
24: pop
25: aload_1
26: ldc #7; //String corp.id AS corpId,
28: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
31: pop测试

用+号拼接的方式

Code:
0:new#2; //class java/lang/StringBuilder
3: dup
4: invokespecial #85; //Method java/lang/StringBuilder."<init>":()V
7: ldc #86; //String SELECT new map( corp.id AS corpId, ( SELECT COUNT(*) FROM TPerson per, TXXJL jl WHERE per.CBh = jl.CBhPerson AND per.corpId = corp.id AND jl.CSJYJ IS NULL AND( jl.NSpcz = ? OR jl.NSpcz = ? OR( jl.NSpcz = ? AND jl.NSpjg = ? ) OR( jl.NSpcz = ? AND jl.NSpjg = ? ) ) AND( jl.CJdyj IS NULL OR jl.CJdyj = ? ) AND jl.CBh NOT IN( SELECT pctq.CBhJlxx FROM TXXPctq pctq, TXXPcxx pcxx WHERE pctq.CBhPcxx = pcxx.CBh AND pcxx.NLx = ? AND pcxx.CCjdw = corp.id ) )AS dcs, ( SELECT COUNT(*) FROM TPerson per, TXXJL jl WHERE per.CBh = jl.CBhPerson AND per.corpId = corp.id AND jl.CJdyj IS NULL AND( jl.NSpcz = ? OR jl.NSpcz = ? OR( jl.NSpcz = ? AND jl.NSpjg = ? ) OR( jl.NSpcz = ? AND jl.NSpjg = ? ) ) AND( jl.CSJYJ IS NULL OR jl.CSJYJ = ? ) AND jl.CBh NOT IN( SELECT pctq.CBhJlxx FROM TXXPctq pctq, TXXPcxx pcxx WHERE pctq.CBhPcxx = pcxx.CBh AND pcxx.NLx = ? AND pcxx.CCjdw = corp.id ) )AS dyyjd, ( SELECT COUNT(*) FROM TPerson per, TXXJL jl WHERE per.CBh = jl.CBhPerson AND per.corpId = corp.id AND( jl.CSJYJ = ? AND jl.CJdyj = ? ) AND( jl.NSpcz = ? OR jl.NSpcz = ? OR( jl.NSpcz = ? AND jl.NSpjg = ? ) OR( jl.NSpcz = ? AND jl.NSpjg = ? ) ) AND jl.CBh NOT IN( SELECT pctq.CBhJlxx FROM TXXPctq pctq, TXXPcxx pcxx WHERE pctq.CBhPcxx = pcxx.CBh AND pcxx.NLx = ? AND pcxx.CCjdw = corp.id ) )AS dfpqc, ( SELECT COUNT(*) FROM TXXJL jl, TZf zfxx, TXXPctq pctq WHERE jl.CBhPerson = zfxx.CBh AND pctq.CBhJlxx = jl.CBh AND pctq.CBhPcxx = ? AND jl.NSpzt = ? AND jl.NSpcz != ? AND zfxx.corpId = corp.id )AS dspbw, ( SELECT COUNT(DISTINCT pt.CBhJlxx) FROM TXXPctq pt, TXXJL tq, TPerson per, TXXPcxx pc WHERE pc.NLx =? AND pc.CCjdw = corp.id AND pt.CBhJlxx = tq.CBh AND tq.CBhPerson = per.CBh AND pt.CBhPcxx = pc.CBh AND per.NSfyx =? AND per.NSfyx =
9: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
12: getstatic #87; //Field SF_YES:Ljava/lang/Integer;
15: invokevirtual #88; //Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;
18: ldc #66; //String AND tq.NTqlb IS NOT NULL
20: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
23: ldc #67; //String AND tq.NSpzt >= ?
25: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
28: ldc #68; //String AND tq.NSpzt <=?
30: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;优化

后者说明，jdk在编译期已经将用加号拼接的字符串理解为一个字符串，不会再去建立一个StringBuilder一个一个的链接上去，而前者全程使用StringBuilder.append，就是实打实的拼接了，没有给jdk一个优化的机会。
我测试使用的jdk版本是：jdk1.5.0_22
这种性能差别少有人说起，不少人讨论过String相加的问题，直接得出尽可能用StringBuilder（或StringBuffer）的结论，而没有考虑到一直使用StringBuilder结构拼接字符串，除了不美观不易读外，还会有在性能上输给 +号拼接的问题
究其缘由，你们通常测试时都使用不多量的字符串拼接，不太符合实际场景，没有考虑到写代码时常常出现像上面的几百行append带来的影响。
固然，即使这样二者的性能差距仍然不大，并且也没有在循环中用+号链接与append链接的差距大，但还有一点就是前面说的全程append的可读性差得太多，用+号链接的可读性显然是更好的，难道不该该选择更好的方式吗？

还有一个好处

上面append代码改成全+号的那个截图不清晰，实际我在+号链接字符串时加入了一个整数常量

+" AND per.NSfyx = "+TestStringJoin.SF_YESui

由于字符串+号拼接时若是不出现变量、非字符串常量的时候，编译期就直接认为是一个字符串了，同时由于有字符串缓冲池的存在，
因而，这种状况下二者的性能差别是：
testStringJoinWithPlus 10000 times elapse = 0ms
testStringJoinWithStringBuilder 10000 times elapse = 157ms

因此我很是推荐在遇到循环或条件分支的以前，写sql就用+号拼接并合理换行排版，参数尽可能都用?绑定，优雅又高效。

append中用+号拼接String如何?

有时候你们在用new StringBuilder拼接字符串时发现超出80列，就回车换行，IDE自动识别为+号链接的字符串，若是忘了改就一直保持这样了。
以前我跟别人说不推荐在append中使用+号链接，由于这样在append方法中可能又会引发一次new StrinBuilder，不过看来应该改改了。
通过上面的测试，上面的拼接字符串方法我写成仅两次append，能够预料到会有下面这个状况：

Code:
0:new#2; //class java/lang/StringBuilder
3: dup
4: invokespecial #85; //Method java/lang/StringBuilder."<init>":()V
7: astore_1
8: aload_1
9: ldc #90; //String SELECT new map(corp.id AS corpId, (SELECT COUNT(*) FROM TPerson per, TXXJL jl WHERE per.CBh = jl.CBhPerson AND per.corpId = corp.id AND jl.CSJYJ IS NULL AND (jl.NSpcz = ? OR jl.NSpcz = ? OR (jl.NSpcz = ? AND jl.NSpjg = ?) OR (jl.NSpcz = ? AND jl.NSpjg = ?)) AND (jl.CJdyj IS NULL OR jl.CJdyj = ?) AND jl.CBh NOT IN (SELECT pctq.CBhJlxx FROM TXXPctq pctq, TXXPcxx pcxx WHERE pctq.CBhPcxx = pcxx.CBh AND pcxx.NLx = ? AND pcxx.CCjdw = corp.id)) AS dcs, (SELECT COUNT(*) FROM TPerson per, TXXJL jl
11: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
14: pop
15: aload_1
16: ldc #91; //String WHERE per.CBh = jl.CBhPerson AND per.corpId = corp.id AND jl.CJdyj IS NULL AND (jl.NSpcz = ? OR jl.NSpcz = ? OR (jl.NSpcz = ? AND jl.NSpjg = ?) OR (jl.NSpcz = ? AND jl.NSpjg = ?)) AND (jl.CSJYJ IS NULL OR jl.CSJYJ = ?) AND jl.CBh NOT IN (SELECT pctq.CBhJlxx FROM TXXPctq pctq, TXXPcxx pcxx WHERE pctq.CBhPcxx = pcxx.CBh AND pcxx.NLx = ? AND pcxx.CCjdw = corp.id)) AS dyyjd, (SELECT COUNT(*) FROM TPerson per, TXXJL jl WHERE per.CBh = jl.CBhPerson AND per.corpId = corp.id AND (jl.CSJYJ = ? AND jl.CJdyj = ?) AND (jl.NSpcz = ? OR jl.NSpcz = ? OR (jl.NSpcz = ? AND jl.NSpjg = ?) OR (jl.NSpcz = ? AND jl.NSpjg = ?)) AND jl.CBh NOT IN (SELECT pctq.CBhJlxx FROM TXXPctq pctq, TXXPcxx pcxx WHERE pctq.CBhPcxx = pcxx.CBh AND pcxx.NLx = ? AND pcxx.CCjdw = corp.id)) AS dfpqc, (SELECT COUNT(*) FROM TXXJL jl, TZf zfxx, TXXPctq pctq WHERE jl.CBhPerson = zfxx.CBh AND pctq.CBhJlxx = jl.CBh AND pctq.CBhPcxx = ? AND jl.NSpzt = ? AND jl.NSpcz != ? AND zfxx.corpId = corp.id) AS dspbw, (SELECT COUNT(DISTINCT pt.CBhJlxx) FROM TXXPctq pt, TXXJL tq, TPerson per, TXXPcxx pc WHERE pc.NLx = ? AND pc.CCjdw = corp.id AND pt.CBhJlxx = tq.CBh AND tq.CBhPerson = per.CBh AND pt.CBhPcxx = pc.CBh AND per.NSfyx = ? AND per.NSfyx = 1 AND tq.NTqlb IS NOT NULL AND tq.NSpzt >= ? AND tq.NSpzt <= ? AND tq.NSpcz = ? AND tq.NSpjg = ?) AS tbcl, (SELECT COUNT(DISTINCT pt.CBhJlxx) FROM TXXPcxx pc, TXXPctq pt, TXXJL tq, TZf zf WHERE pc.NLx = ? AND pc.CCjdw = corp.id AND pt.CBhJlxx = tq.CBh AND tq.CBhPerson = per.CBh AND pt.CBhPcxx = pc.CBh AND per.NSfyx = ? AND tq.NTqlb IS NOT NULL AND ((tq.NSpzt >= ? AND tq.NSpzt <= ? AND tq.NSpcz = ? AND tq.NSpjg = ?) O (tq.NSpzt = ? AND tq.NSpcz >= ?))) AS djwzx) FROM XfzxCorp corp
18: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
21: pop
22: aload_1
23: invokevirtual #84; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
26: areturnspa

编译后发现没有生成多余的StringBuilder。
就是说，若是仅仅是由于换行，而不是加入了其余的变量、常量、函数等状况下，append中的字符串能够出现+号拼接。
因此亲们，把sql、hql其余啥啥字符串拼接写得优雅点好不。

最后测试一下StringBuilder扩容问题

用+号链接字符串，当须要建立StrinBuilder时，jdk使用了无参数的构造函数，至关于new StringBuilder(16) 在测试方法中，直接建立StrinBuilder时的代码也是无参数的，这里面虽然无差异，但细心的人应该会考虑一下这个问题。 +号链接方式，因为上面的结论不少字符串相加而中间没有变量、非字符串常量等因素时，至关于一个字符串，也就是说至少须要14个外加进来的东西，才会引发一次扩容；而直接建立StrinBuilder时，有几回append就算占用了几个容量，所以这也是后者效率差的一个缘由。测试的sql为4789字节，使用new StringBuilder(5000)不会产生扩容问题，这种状况下看看顶楼两种代码的差距呢？结果以下： testStringJoinWithPlus 10000 times elapse = 66ms testStringJoinWithStringBuilder 10000 times elapse = 85ms 后者性能好了很多，虽然数值相差不大，但按百分比来讲效率提高约70%((151/85)-1)，不过从理论上来讲，不会超过+号链接字符串的状况