誰在關(guān)心toString的性能？沒有人！除非當(dāng)你有大量的數(shù)據(jù)在批量處理，使用toString產(chǎn)生了許多日志。然后，你去調(diào)查為何如此之慢，才意識(shí)到大部分的toString方法使用的是introspection，它其實(shí)是可以被優(yōu)化的。

       不過，首先讓我們一起看看Javadoc回憶下Object.toString應(yīng)當(dāng)做什么：“返回該對(duì)象的字符串表示，該結(jié)果必須簡(jiǎn)明但表述詳實(shí)易懂。建議所有子類重寫該方法”。這里最有趣的就是“簡(jiǎn)明”和“詳實(shí)”。我們所鐘愛的IDE們常常為我們生成equals/hashcode/toString這些方法，且我們通常不再去管它們。此外，這些IDE們提供了許多方式來生成我們自己的toString：字符串連接（使用+號(hào)）、StringBuffer、StringBuilder、ToStringBuilder（Commons Lang 3）、 ReflectionToStringBuilder (Commons Lang 3)、Guava或者Objects.toString……該選哪一個(gè)？

       如果你想知道哪種toString的實(shí)現(xiàn)方式會(huì)更高效，不要去猜測(cè)，而是去測(cè)試！這時(shí)你需要用到JMH。我曾在博客上寫過有關(guān)它的文章，所以這里不再細(xì)談JMH如何工作的細(xì)節(jié)。

       在該基準(zhǔn)測(cè)試中，我創(chuàng)建了一個(gè)復(fù)雜的對(duì)象圖（使用繼承、集合等等），而且我使用到了由IDE生成的所有不同toString的實(shí)現(xiàn)方式，來看看哪一種性能更好。就一條經(jīng)驗(yàn)法則：簡(jiǎn)潔。無論你使用哪種技術(shù)（如下），為一些屬性或者所有屬性（包括繼承、依賴或者集合）生成toSting，對(duì)性能會(huì)有巨大的影響。

       用 + 連接字符串

       讓我們先從最高效的方法開始：用 + 連接字符串。曾經(jīng)這種被認(rèn)為是邪惡的使用方式（“不要用 + 連接字符串?。?！”），已變得很酷且高效！如今JVM編譯器（大部分時(shí)候）會(huì)把 + 編譯成一個(gè)string builder。所以，不用猶豫，用它就是了。唯一的缺點(diǎn)是null值不會(huì)被處理，你需要自己來處理它。

       看看下面注解中使用JMH統(tǒng)計(jì)出來的平均性能。

     public String toString() {
             return "MyObject{" +
            "att1=" + att1 + +
            ", att2=" + att2 + +
            ", att3=" + att3 + +
            "} " + super.toString();
         }
 
       // Average performance with JMH (ops/s)
       // (min, avg, max) = (140772,314, 142075,167, 143844,717)
       // 使用JMH測(cè)出來的平均性能
       // (最小, 平均, 最大) = (140772,314, 142075,167, 143844,717)
     

       用Objects.toString連接字符串

       Java SE 7帶來了Objects類和它的一些靜態(tài)方法。Objects.toString的優(yōu)點(diǎn)是它可以處理null值，甚至可以給null設(shè)置默認(rèn)值。其性能與上一個(gè)相比略低，但是null值可以被處理：

       StringBuilder

       另一種技術(shù)是使用StringBuilder。很難講清哪一種技術(shù)性能更好。如我前面所說，我已經(jīng)使用了復(fù)雜的對(duì)象圖（att1、 att2和att3變量的命名是為了可讀性），JMH給出了或多或少相同的結(jié)果。后面這三種技術(shù)在性能方面非常接近。

       Guava

       Guava有一些helper類：其中一個(gè)可以幫助你生成toString。這比純JDK API性能要差一點(diǎn)，但是它可以提供給你一些額外的服務(wù)（我這里指的Guava）：

       Commons Lang3

       Commons Lang3有一些技術(shù)來生成toString：從builder到 introspector。如同你猜測(cè)到的，introspection更容易使用，代碼量更少，但是性能比較糟糕：

       總結(jié)

       如今有了JVM優(yōu)化，我們可以安全使用+來連接字符串（及使用Objects.toString來處理null）。有了內(nèi)置到JDK的實(shí)用工具類，不需要外部框架來處理null值。因此，與本文中講述的其它技術(shù)相比，開箱即用的JDK擁有更好的性能（如果你有其它的框架/技術(shù)，請(qǐng)留下評(píng)論我來試試看）。

       作為總結(jié)，下面是一個(gè)從JMH得到的平均性能數(shù)據(jù)表格（從最高效依次遞減）

       再說一次，如果你經(jīng)常調(diào)用toString方法，這是很重要的。否則，性能就真不是個(gè)事。