Java toString 效能優化方案比較
阿新 • • 發佈：2018-12-18
誰在關心toString的效能？沒有人！除非當你有大量的資料在批量處理，使用toString產生了許多日誌。然後，你去調查為何如此之慢，才意識到大部分的toString方法使用的是introspection，它其實是可以被優化的。
不過，首先讓我們一起看看Javadoc回憶下Object.toString應 當做什麼：“返回該物件的字串表示，該結果必須簡明但表述詳實易懂。建議所有子類重寫該方法”。這裡最有趣的就是“簡明”和“詳實”。我們所鍾愛的 IDE們常常為我們生成equals/hashcode/toString這些方法，且我們通常不再去管它們。此外，這些IDE們提供了許多方式來生成我 們自己的toString：字串連線（使用+號）、StringBuffer、StringBuilder、 ToStringBuilder（Commons
Lang 3）、 ReflectionToStringBuilder (Commons Lang 3)、Guava或者Objects.toString……該選哪一個？
如果你想知道哪種toString的實現方式會更高效，不要去猜測，而是去測試！這時你需要用到JMH。我曾在部落格上寫過有關它的文章，所以這裡不再細談JMH如何工作的細節。
在該基準測試中，我建立了一個複雜的物件圖（使用繼承、集合等等），而且我使用到了由IDE生成的所有不同toString的實現方式，來看看哪一 種性能更好。就一條經驗法則：簡潔。無論你使用哪種技術（如下），為一些屬性或者所有屬性（包括繼承、依賴或者集合）生成toSting，對效能會有巨大 的影響。
用 + 連線字串
讓我們先從最高效的方法開始：用 + 連線字串。曾經這種被認為是邪惡的使用方式（“不要用 + 連線字串！！！”），已變得很酷且高效！如今JVM編譯器（大部分時候）會把 + 編譯成一個string builder。所以，不用猶豫，用它就是了。唯一的缺點是null值不會被處理，你需要自己來處理它。