Java toString的效能優化方案比較
誰在關心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值不會被處理,你需要自己來處理它。
看看下面註解中使用JMH統計出來的平均效能。
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測出來的平均效能 // (最小, 平均, 最大) = (140772,314, 142075,167, 143844,717)
用Objects.toString連線字串
Java SE 7帶來了Objects類和它的一些靜態方法。Objects.toString的優點是它可以處理null值,甚至可以給null設定預設值。其效能與上一個相比略低,但是null值可以被處理:
public String toString() { return "MyObject{" + "att1='" + Objects.toString(att1) + ''' + ", att2='" + Objects.toString(att2) + ''' + ", att3='" + Objects.toString(att3) + ''' + "} " + super.toString(); } // Average performance with JMH (ops/s) // (min, avg, max) = (138790,233, 140791,365, 142031,847) // 使用JMH測出來的平均效能 // (最小, 平均, 最大) = (138790,233, 140791,365, 142031,847)
StringBuilder
另一種技術是使用StringBuilder。很難講清哪一種技術效能更好。如我前面所說,我已經使用了複雜的物件圖(att1、 att2和att3變數的命名是為了可讀性),JMH給出了或多或少相同的結果。後面這三種技術在效能方面非常接近。
public String toString() { final StringBuilder sb = new StringBuilder("MyObject{"); sb.append("att1='").append(att1).append('''); sb.append(", att2='").append(att2).append('''); sb.append(", att3='").append(att3).append('''); sb.append(super.toString()); return sb.toString(); } // Average performance with JMH (ops/s) // (min, avg, max) = (96073,645, 141463,438, 146205,910) // 使用JMH測出來的平均效能 // (最小, 平均, 最大) = (96073,645, 141463,438, 146205,910)
Guava
Guava有一些helper類:其中一個可以幫助你生成toString。這比純JDK API效能要差一點,但是它可以提供給你一些額外的服務(我這裡指的Guava):
public String toString() { return Objects.toStringHelper(this) .add("att1", att1) .add("att2", att2) .add("att3", att3) .add("super", super.toString()).toString(); } // Average performance with JMH (ops/s) // (min, avg, max) = (97049,043, 110111,808, 114878,137) // 使用JMH測出來的平均效能 // (最小, 平均, 最大) = (97049,043, 110111,808, 114878,137)
Commons Lang3
Commons Lang3有一些技術來生成toString:從builder到 introspector。如同你猜測到的,introspection更容易使用,程式碼量更少,但是效能比較糟糕:
public String toString() { return new ToStringBuilder(this) .append("att1", att1) .append("att2", att2) .append("att3", att3) .append("super", super.toString()).toString(); } // Average performance with JMH (ops/s) // (min, avg, max) = ( 73510,509, 75165,552, 76406,370) // 使用JMH測出來的平均效能 // (最小, 平均, 最大) = ( 73510,509, 75165,552, 76406,370) public String toString() { return ToStringBuilder.reflectionToString(this, ToStringStyle.SHORT_PREFIX_STYLE); } // Average performance with JMH (ops/s) // (min, avg, max) = (31803,224, 34930,630, 35581,488) // 使用JMH測出來的平均效能 // (最小, 平均, 最大) =(31803,224, 34930,630, 35581,488) public String toString() { return ReflectionToStringBuilder.toString(this); } // Average performance with JMH (ops/s) // (min, avg, max) = (14172,485, 23204,479, 30754,901) // 使用JMH測出來的平均效能 // (最小, 平均, 最大) = (14172,485, 23204,479, 30754,901)
總結
如今有了JVM優化,我們可以安全使用+來連線字串(及使用Objects.toString來處理null)。有了內建到JDK的實用工具類,不需要外部框架來處理null值。因此,與本文中講述的其它技術相比,開箱即用的JDK擁有更好的效能(如果你有其它的框架/技術,請留下評論我來試試看)。
作為總結,下面是一個從JMH得到的平均效能資料表格(從最高效依次遞減)
使用技術 | 平均操作次數/秒 |
---|---|
用’+’連線字串 | 142.075,167 |
String builder | 141.463,438 |
Objects.toString | 140.791,365 |
Guava | 110.111,808 |
ToStringBuilder (append) | 75.165,552 |
ToStringBuilder (reflectionToString) | 34.930,630 |
ReflectionToStringBuilder | 23.204,479 |
再說一次,如果你經常呼叫toString方法,這是很重要的。否則,效能就真不是個事。
相關文章
- JAVA IO效能比較Java
- java效能優化方案——使用entrySet()Java優化
- Java Bean Copy元件的效能比較JavaBean元件
- Java中List集合效能比較Java
- 由react效能優化擴充套件出來的bind與閉包的比較(效能)React優化套件
- java效能優化方案1——使用StringBuilderJava優化UI
- MySQL 效能優化方案MySql優化
- Java JIT與AOT效能比較 - foojayJava
- 人人都能掌握的Java服務端效能優化方案Java服務端優化
- Apache與Nginx的優缺點、效能比較,到底選擇哪個比較好?ApacheNginx
- java效能優化Java優化
- java效能優化方案3——不要使用iterator()方法Java優化
- 前端效能優化方案索引前端優化索引
- java效能優化方案9——優化自定義hasCode()方法和equals()方法Java優化
- Java不同壓縮演算法的效能比較Java演算法
- Java中不同的併發實現的效能比較Java
- [java][效能優化]java高階開發必會的50個效能優化Java優化
- java效能優化方案2——避免使用正規表示式Java優化
- java效能優化方案5——使用原始型別和棧Java優化型別
- 比較全面的MySQL優化參考MySql優化
- Java幾種常用JSON庫效能比較JavaJSON
- 前端開發效能優化方案前端優化
- 微信小程式效能優化方案微信小程式優化
- React效能優化方案之PureRenderMixinReact優化
- 批量更新效能比較
- 不同解決方案的比較
- Java效能優化的5個技巧Java優化
- JAVA效能優化思路探究Java優化
- 【Java效能優化思路方向】Java優化
- Java效能優化技巧集合Java優化
- Vue-cli3.0的打包效能優化方案Vue優化
- React效能優化方案之PureComponentReact優化
- Java 比較器Java
- JAVA字串比較Java字串
- 七種WebSocket框架的效能比較Web框架
- eAccelerator的安裝和效能比較
- DECODE和CASE的效能比較
- switch...case && if...else效率比較和優化優化