Java中关于String.format的性能问题

首先需要说明的是本文所说的是java中的String的format方法性能,可能其他语言有所差异。

下面进入正题。一般新入职一家公司的时候,会去看新公司现有的代码。我记得我来的时候用了一段时间把项目的各个业务结合代码实现整个看了个遍,我清楚的记得,我刚来的时候,我们总监的一句话,业务永远是最重要的。

当然有一些Java的用法也是以前没见到过。比如以前字符串拼接,都会用String类型直接加号拼接字符串,顶多心里知道其实有StringBuilder和StringBuffer效率更好。但是效率差的不多就还是用字符串拼接。在这里发现有人在代码中用String的format方法,感觉很方便,也就跟着用了。

其实这个这个用法到现在也用了好久了,现在想来性能并不一定很好,也还是简单介绍一下。下面先看个简单的例子吧。

用法就是这样,第一个参数是个字符串,里面有一些替换的字符,同时有对应类型,后面是个变长数组参数。其中%d对应整型数字,%c为char类型,%f为浮点型,%s为字符串,%b为布尔型,学过c语言的可能会比较熟悉。当然还有很多其他用法,这里就不详细介绍了。

附带说下,其实我们经常输出的log日志,也有类似的用法。

只不过不用指定具体类型,更省事了~

这样用真的好吗,对于一般要求不高的系统,其实这样用比字符串拼接看起来还更加清晰一点,但是性能怎么样呢。这里之前写的一篇文章,《Java使用JMH进行简单的基准测试Benchmark》(怎么用?点去看看),来做个测试,测试代码如下。

我们来运行一下,得到的测试结果如下。

直接关注最后一行,性能差好多。用结果说话,String的format性能真的没有字符串拼接性能好,而且是差太多,更别说StringBuilder了。

为什么性能这么差呢?虽然我们得到了结果,也来了解下原因吧。首先可以想到的是,String的format需要去逐个替换占位符,另外由于不同的类型,还需要去匹配类型,这肯定比直接字符串相加性能消耗多了很多。

下面来简单了解下关键部位的源码就知道了。

这里就不粘这里面的parse方法了,也是个循环。

到此我们应该知道他有多慢,而且为什么这么慢了。以后什么时候该用哪个还是要根据具体情况来选择。

本文原创于赵伊凡BLOG转载请注明出处。

©原创文章,转载请注明来源: 赵伊凡's Blog
©本文链接地址: Java中关于String.format的性能问题