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方法,这是很重要的。否则,性能就真不是个事。

时间: 2024-10-12 13:33:02

Java toString的性能优化方案比较的相关文章

JDBC性能优化方案

近期用到了利用JDBC查询Oracle数据库,但是查询效率不尽人意,研究了一下JDBC方面可以优化的地方,在这里跟大家分享一下. 1.设置最优的预取值 defaultRowPrefetch:预取条数默认值 defaultBatchValue:触发查询操作的批量请求值 这两个参数的默认值都是10,我们可以通过增加这两个参数值来减少数据库请求以提高查询效率,当然具体值大小要视具体情况而定. 2.通过连接池获取连接 创建连接的代价很大,通过连接池获取连接可省去创建连接时间. 3.选择合适的Statem

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

java流的性能优化1-文件复制

传统的I/O速度相对比较慢,它会成为系统性能的瓶颈,所以在java1.4之后提供了NIO,它是一种全新的流:它具有以下特性: 1.为所有的原是类型提供Buffer缓存支持: 2.使用java.nio.charset.Charset作为字符编码解码解决方案: 3.增加通道(Channel)对象,作为新的原始I/O抽象: 4.支持锁和内存映射文件的文件访问接口: 5.提供基于Selector的异步网络I/O: NIO是一种全新的流,跟流式的I/O不同,NIO是基于块的,它以块为基本单位处理数据.在N

kvm性能优化方案

kvm性能优化方案 kvm性能优化,主要集中在cpu.内存.磁盘.网络,4个方面,当然对于这里面的优化,也是要分场景的,不同的场景其优化方向也是不同的,下面具体聊聊这4个方面的优化细节. cpu 在介绍cpu之前,必须要讲清楚numa的概念,建议先参考如下两篇文章 CPU Topology 玩转cpu-topology 查看cpu信息脚本: #!/bin/bash # Simple print cpu topology # Author: kodango function get_nr_proc

GNU Linux高并发性能优化方案

/*********************************************************** * Author : Samson * Date : 07/14/2015 * Test platform: * gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 * GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu) * Nginx version: * Nginx 1.6.2 * Nginx 1.8.0

Glusterfs目录ls性能优化方案分析

Glusterfs目录ls性能优化方案分析 目的和优化思路 讨论了glusterfs对文件系统爬虫rsync/ls目录性能的现有优化措施和可能的进一步优化方案.优化思路是减少本地文件系统的元数据操作,减少fuse client的负载,减少req的网络轮询次数,减少一次网络通信时间,缓存预抓取,并发,异步,bulk 传输 fuse readdirplus centos 6.4最新内核,支持fuse readdirplus.微调mount timeout参数. FUSE: Adaptive NFS-

web前端9大性能优化方案汇总

网页的性能问题是产品开发过程中的一个重要的环节,在产品成功地把功能实现后,性能能好与坏就直接影响了用户体验,以至于影响了产品的成败! 作为web前端开发者,对前端部分进行性能上的优化,是责无旁贷,刻不容缓的工作.下面简介一下9种性能优化方案. 一.罪魁祸首是http请求 一般网页,80%的响应时间花在下载网页内容(images, stylesheets, javascripts, scripts, flash等).减少请求次数是缩短响应时间的关键!可以通过简化页面设计来减少请求次数,但页面内容较

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP

Redmine性能优化方案

近来公司redmine服务器表现很糟糕,在16核,64GRAM的机器上,压测结果竟然只有每秒5~7个请求,部分页面一个都出不来. 以下是我对Redmine性能优化方案: redmine服务器性能问题排查与优化建议: 以下建议的方案是基于redmine运行期的log文件中的render耗时.activerecord耗时,linux系统性能指标采样与 mysql 性能指标采样分析,以及redmine在不同web server下的benchmark而得:   一. 问题排查与定量分析 通过分析redm