谁在关心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给出了或多或少相同的结果。后面这三种技术在性能方面非常接近。