誰在關心tostring的性能？沒有人！除非當你有大量的資料在批量處理，使用tostring産生了許多日志。然後，你去調查為何如此之慢，才意識到大部分的tostring方法使用的是introspection，它其實是可以被優化的。
當做什麼：“傳回該對象的字元串表示，該結果必須簡明但表述詳實易懂。建議所有子類重寫該方法”。這裡最有趣的就是“簡明”和“詳實”。我們所鐘愛的
ide們常常為我們生成equals/hashcode/tostring這些方法，且我們通常不再去管它們。此外，這些ide們提供了許多方式來生成我
們自己的tostring：字元串連接配接（使用+号）、stringbuffer、stringbuilder、
tostringbuilder（commons lang 3）、 reflectiontostringbuilder (commons lang
3)、guava或者objects.tostring……該選哪一個？
在該基準測試中，我建立了一個複雜的對象圖（使用繼承、集合等等），而且我使用到了由ide生成的所有不同tostring的實作方式，來看看哪一
種性能更好。就一條經驗法則：簡潔。無論你使用哪種技術（如下），為一些屬性或者所有屬性（包括繼承、依賴或者集合）生成tosting，對性能會有巨大
的影響。
用 + 連接配接字元串
看看下面注解中使用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值可以被處理：
"att1='" + objects.tostring(att1) + ''' +
", att2='" + objects.tostring(att2) + ''' +
", att3='" + objects.tostring(att3) + ''' +
// (min, avg, max) = (138790,233, 140791,365, 142031,847)
// (最小, 平均, 最大) = (138790,233, 140791,365, 142031,847)
stringbuilder
另一種技術是使用stringbuilder。很難講清哪一種技術性能更好。如我前面所說，我已經使用了複雜的對象圖（att1、 att2和att3變量的命名是為了可讀性），jmh給出了或多或少相同的結果。後面這三種技術在性能方面非常接近。
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();
// (min, avg, max) = (96073,645, 141463,438, 146205,910)
// (最小, 平均, 最大) = (96073,645, 141463,438, 146205,910)
guava
return objects.tostringhelper(this)
.add("att1", att1)
.add("att2", att2)
.add("att3", att3)
.add("super", super.tostring()).tostring();
// (min, avg, max) = (97049,043, 110111,808, 114878,137)
// (最小, 平均, 最大) = (97049,043, 110111,808, 114878,137)
commons lang3
commons lang3有一些技術來生成tostring：從builder到 introspector。如同你猜測到的，introspection更容易使用，代碼量更少，但是性能比較糟糕：
return new tostringbuilder(this)
.append("att1", att1)
.append("att2", att2)
.append("att3", att3)
.append("super", super.tostring()).tostring();
// (min, avg, max) = ( 73510,509, 75165,552, 76406,370)
// (最小, 平均, 最大) = ( 73510,509, 75165,552, 76406,370)
return tostringbuilder.reflectiontostring(this, tostringstyle.short_prefix_style);
// (min, avg, max) = (31803,224, 34930,630, 35581,488)
// (最小, 平均, 最大) =(31803,224, 34930,630, 35581,488)
return reflectiontostringbuilder.tostring(this);
// (min, avg, max) = (14172,485, 23204,479, 30754,901)
// (最小, 平均, 最大) = (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
110.111,808
tostringbuilder (append)
75.165,552
tostringbuilder (reflectiontostring)
34.930,630
reflectiontostringbuilder
23.204,479
再說一次，如果你經常調用tostring方法，這是很重要的。否則，性能就真不是個事。
來源：51cto