在调查使用以及将整数原语转换为字符串的辩论时"" + n
,Integer.toString(int)
我写了这个JMH微基准测试:
@Fork(1)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class IntStr {
protected int counter;
@GenerateMicroBenchmark
public String integerToString() {
return Integer.toString(this.counter++);
}
@GenerateMicroBenchmark
public String stringBuilder0() {
return new StringBuilder().append(this.counter++).toString();
}
@GenerateMicroBenchmark
public String stringBuilder1() {
return new StringBuilder().append("").append(this.counter++).toString();
}
@GenerateMicroBenchmark
public String stringBuilder2() {
return new StringBuilder().append("").append(Integer.toString(this.counter++)).toString();
}
@GenerateMicroBenchmark
public String stringFormat() {
return String.format("%d", this.counter++);
}
@Setup(Level.Iteration)
public void prepareIteration() {
this.counter = 0;
}
}
我在Linux机器上的两个Java VM上都使用默认的JMH选项运行了它(最新的Mageia 4 64位,Intel i7-3770 CPU,32GB RAM)。第一个JVM是Oracle JDK 8u5 64位提供的:
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
有了这个JVM,我得到了我所期望的:
Benchmark Mode Samples Mean Mean error Units
b.IntStr.integerToString thrpt 20 32317.048 698.703 ops/ms
b.IntStr.stringBuilder0 thrpt 20 28129.499 421.520 ops/ms
b.IntStr.stringBuilder1 thrpt 20 28106.692 1117.958 ops/ms
b.IntStr.stringBuilder2 thrpt 20 20066.939 1052.937 ops/ms
b.IntStr.stringFormat thrpt 20 2346.452 37.422 ops/ms
也就是说,StringBuilder
由于创建StringBuilder
对象和附加空字符串会产生额外的开销,因此使用该类的速度较慢。使用String.format(String, ...)
速度甚至要慢一个数量级左右。
另一方面,发行版提供的编译器基于OpenJDK 1.7:
java version "1.7.0_55"
OpenJDK Runtime Environment (mageia-2.4.7.1.mga4-x86_64 u55-b13)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
这里的结果很有趣:
Benchmark Mode Samples Mean Mean error Units
b.IntStr.integerToString thrpt 20 31249.306 881.125 ops/ms
b.IntStr.stringBuilder0 thrpt 20 39486.857 663.766 ops/ms
b.IntStr.stringBuilder1 thrpt 20 41072.058 484.353 ops/ms
b.IntStr.stringBuilder2 thrpt 20 20513.913 466.130 ops/ms
b.IntStr.stringFormat thrpt 20 2068.471 44.964 ops/ms
为什么StringBuilder.append(int)
使用此JVM出现得这么快?查看StringBuilder
类源代码并没有发现任何特别有趣的问题-该方法与Integer#toString(int)
。有趣的是,附加Integer.toString(int)
(stringBuilder2
microbenchmark)的结果似乎并不快。
这种性能差异是否是测试工具的问题?或者我的OpenJDK JVM是否包含会影响此特定代码(反)模式的优化?
编辑:
为了进行更直接的比较,我安装了Oracle JDK 1.7u55:
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
结果与OpenJDK相似:
Benchmark Mode Samples Mean Mean error Units
b.IntStr.integerToString thrpt 20 32502.493 501.928 ops/ms
b.IntStr.stringBuilder0 thrpt 20 39592.174 428.967 ops/ms
b.IntStr.stringBuilder1 thrpt 20 40978.633 544.236 ops/ms
看来这是Java 7 vs Java 8的更一般问题。也许Java 7具有更积极的字符串优化功能?
编辑2:
为了完整起见,以下是这两个JVM的与字符串相关的VM选项:
对于Oracle JDK 8u5:
$ /usr/java/default/bin/java -XX:+PrintFlagsFinal 2>/dev/null | grep String
bool OptimizeStringConcat = true {C2 product}
intx PerfMaxStringConstLength = 1024 {product}
bool PrintStringTableStatistics = false {product}
uintx StringTableSize = 60013 {product}
对于OpenJDK 1.7:
$ java -XX:+PrintFlagsFinal 2>/dev/null | grep String
bool OptimizeStringConcat = true {C2 product}
intx PerfMaxStringConstLength = 1024 {product}
bool PrintStringTableStatistics = false {product}
uintx StringTableSize = 60013 {product}
bool UseStringCache = false {product}
该UseStringCache
选项在Java 8中已删除,没有替代品,因此我怀疑这有什么区别。其余选项似乎具有相同的设置。
编辑3:
与的源代码的并排比较AbstractStringBuilder
,StringBuilder
以及Integer
来自src.zip
文件的类均未发现缺点。除了进行了大量的外观和文档更改外,Integer
现在还对无符号整数提供了一些支持,并且StringBuilder
已进行了稍微的重构以与共享更多代码StringBuffer
。StringBuilder#append(int)
尽管我可能错过了一些内容,但这些更改似乎都没有影响所使用的代码路径。
比较为IntStr#integerToString()
和生成的汇编代码IntStr#stringBuilder0()
更有趣。IntStr#integerToString()
为这两个JVM生成的代码的基本布局是相似的,尽管Oracle JDK 8u5似乎更积极地插入Integer#toString(int)
代码中的某些调用。与Java源代码之间存在明显的对应关系,即使对于汇编经验最少的人也是如此。
IntStr#stringBuilder0()
但是,的汇编代码完全不同。Oracle JDK 8u5生成的代码再次与Java源代码直接相关-我可以轻松地识别相同的布局。相反,未经训练的眼睛(如我的眼睛)几乎无法识别OpenJDK 7生成的代码。该new StringBuilder()
呼叫被看似除去,因为是在所述阵列的创建StringBuilder
构造函数。另外,反汇编程序插件无法像JDK 8中那样提供对源代码的尽可能多的引用。
我认为这是由于OpenJDK 7进行了更积极的优化而导致的,或者更可能是为某些StringBuilder
操作插入了手写的低级代码的结果。我不确定为什么在我的JVM 8实现中不会发生这种优化,或者为什么Integer#toString(int)
在JVM 7中没有实现相同的优化。我猜想熟悉JRE源代码相关部分的人必须回答这些问题...
new StringBuilder().append(this.counter++).toString();
和第三次测试return "" + this.counter++;
吗?