为什么Java 7中的StringBuilder＃append（int）比Java 8中的快？

孟征

2023-03-14

问题内容：

在调查使用以及将整数原语转换为字符串的简短辩论时"" + 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)（stringBuilder2microbenchmark）的结果似乎并不快。

这种性能差异是否是测试工具的问题？或者我的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中一样多的对源代码的引用。

我认为这是由于OpenJDK7进行了更积极的优化而导致的，或者更可能是为某些StringBuilder操作插入了手写的低级代码的结果。我不确定为什么在我的JVM8实现中不会发生这种优化，或者为什么Integer#toString(int)在JVM 7
中没有实现相同的优化。我猜想熟悉JRE源代码相关部分的人必须回答这些问题…

问题答案：

TL; DR： 副作用append显然破坏了StringConcat优化。

原始问题和更新中的分析非常好！

为了完整起见，以下是一些缺少的步骤：

请-XX:+PrintInlining同时参阅7u55和8u5。在7u55中，您将看到以下内容：

 @ 16   org.sample.IntStr::inlineSideEffect (25 bytes)   force inline
by CompilerOracle
@ 4 java.lang.StringBuilder:: (7 bytes) inline (hot)
@ 18 java.lang.StringBuilder::append (8 bytes) already compiled
into a big method
@ 21 java.lang.StringBuilder::toString (17 bytes) inline (hot)

…在8u5中：

 @ 16   org.sample.IntStr::inlineSideEffect (25 bytes)   force inline
by CompilerOracle
@ 4 java.lang.StringBuilder:: (7 bytes) inline (hot)
@ 3 java.lang.AbstractStringBuilder:: (12 bytes) inline
(hot)
@ 1 java.lang.Object:: (1 bytes) inline (hot)
@ 18 java.lang.StringBuilder::append (8 bytes) inline (hot)
@ 2 java.lang.AbstractStringBuilder::append (62 bytes) already
compiled into a big method
@ 21 java.lang.StringBuilder::toString (17 bytes) inline (hot)
@ 13 java.lang.String:: (62 bytes) inline (hot)
@ 1 java.lang.Object:: (1 bytes) inline (hot)
@ 55 java.util.Arrays::copyOfRange (63 bytes) inline (hot)
@ 54 java.lang.Math::min (11 bytes) (intrinsic)
@ 57 java.lang.System::arraycopy (0 bytes) (intrinsic)

您可能会注意到7u55版本较浅，并且在StringBuilder方法之后似乎什么也没叫-这很好地表明了字符串优化已经生效。确实，如果您使用来运行7u55
-XX:-OptimizeStringConcat，子调用将重新出现，并且性能将下降到8u5级别。

好的，因此我们需要弄清楚为什么8u5没有进行相同的优化。使用Grep http://hg.openjdk.java.net/jdk9/jdk9/hotspot查找“ StringBuilder”，以了解VM在哪里处理StringConcat优化。这将带您进入src/share/vm/opto/stringopts.cpp
hg log src/share/vm/opto/stringopts.cpp找出那里的最新变化。候选人之一是：

changeset:   5493:90abdd727e64
user:        iveresov
date:        Wed Oct 16 11:13:15 2013 -0700
summary:     8009303: Tiered: incorrect results in VM tests

stringconcat…

在OpenJDK邮件列表上查找审阅线程（很容易用Google搜索更改集摘要）：http : //mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-October/012084.html
现货“字符串连接优化，将模式折叠成单个字符串分配并直接形成结果。在优化代码中可能发生的所有可能的取消操作都从头开始重新启动该模式（从StringBuffer分配开始）。 这意味着，整个模式必须我没有副作用。 “尤里卡？
写下对比基准：

@Fork(5)
@Warmup(iterations = 5)
@Measurement(iterations = 5)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class IntStr {
    private int counter;

    @GenerateMicroBenchmark
    public String inlineSideEffect() {
        return new StringBuilder().append(counter++).toString();
    }

    @GenerateMicroBenchmark
    public String spliceSideEffect() {
        int cnt = counter++;
        return new StringBuilder().append(cnt).toString();
    }
}

在JDK 7u55上进行测量，看到内联/拼接副作用的性能相同：

Benchmark                       Mode   Samples         Mean   Mean
error Units
o.s.IntStr.inlineSideEffect avgt 25 65.460 1.747
ns/op
o.s.IntStr.spliceSideEffect avgt 25 64.414 1.323
ns/op

在JDK 8u5上对其进行测量，看到内联效果会导致性能下降：

Benchmark                       Mode   Samples         Mean   Mean
error Units
o.s.IntStr.inlineSideEffect avgt 25 84.953 2.274
ns/op
o.s.IntStr.spliceSideEffect avgt 25 65.386 1.194
ns/op

提交错误报告（https://bugs.openjdk.java.net/browse/JDK-8043677），以与VM人员讨论此行为。原始修复的基本原理是坚如磐石，但是有趣的是，如果我们能够/应该在这种琐碎的情况下恢复这种优化。
???
利润。

是的，我应该发布基准的结果，该基准将增量从StringBuilder链中移出，并在整个链之前进行。同样，切换到平均时间和ns / op。这是JDK
7u55：

Benchmark                      Mode   Samples         Mean   Mean error
Units
o.s.IntStr.integerToString avgt 25 153.805 1.093
ns/op
o.s.IntStr.stringBuilder0 avgt 25 128.284 6.797
ns/op
o.s.IntStr.stringBuilder1 avgt 25 131.524 3.116
ns/op
o.s.IntStr.stringBuilder2 avgt 25 254.384 9.204
ns/op
o.s.IntStr.stringFormat avgt 25 2302.501 103.032
ns/op

这是8u5：

Benchmark                      Mode   Samples         Mean   Mean error
Units
o.s.IntStr.integerToString avgt 25 153.032 3.295
ns/op
o.s.IntStr.stringBuilder0 avgt 25 127.796 1.158
ns/op
o.s.IntStr.stringBuilder1 avgt 25 131.585 1.137
ns/op
o.s.IntStr.stringBuilder2 avgt 25 250.980 2.773
ns/op
o.s.IntStr.stringFormat avgt 25 2123.706 25.105
ns/op

stringFormat实际上在8u5中要快一些，其他所有测试都相同。这巩固了原问题中主要罪魁祸首中SB链副作用断裂的假说。

为什么Java 7中的StringBuilder＃append（int）比Java 8中的快？

相关阅读

相关文章

相关问答

相关工具

相关文档