为啥返回 Java 对象引用比返回原语慢得多

Posted 2023-03-31

【中文标题】为啥返回 Java 对象引用比返回原语慢得多

【英文标题】：Why is returning a Java object reference so much slower than returning a primitive为什么返回 Java 对象引用比返回原语慢得多

【发布时间】：2015-06-10 22:34:33

【问题描述】：

我们正在开发一个对延迟敏感的应用程序，并且一直在对各种方法进行微基准测试（使用 jmh）。在对查找方法进行微基准测试并对结果感到满意后，我实施了最终版本，却发现最终版本比我刚刚进行基准测试的速度慢 3 倍。

罪魁祸首是实现的方法返回一个enum 对象而不是int。这是基准代码的简化版本：

@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class ReturnEnumObjectVersusPrimitiveBenchmark 

    enum Category 
        CATEGORY1,
        CATEGORY2,
    

    @Param( "3", "2", "1" )
    String value;

    int param;

    @Setup
    public void setUp() 
        param = Integer.parseInt(value);
    

    @Benchmark
    public int benchmarkReturnOrdinal() 
        if (param < 2) 
            return Category.CATEGORY1.ordinal();
        
        return Category.CATEGORY2.ordinal();        
    


    @Benchmark
    public Category benchmarkReturnReference() 
        if (param < 2) 
            return Category.CATEGORY1;
        
        return Category.CATEGORY2;      
    


    public static void main(String[] args) throws RunnerException 
            Options opt = new OptionsBuilder().include(ReturnEnumObjectVersusPrimitiveBenchmark.class.getName()).warmupIterations(5)
                .measurementIterations(4).forks(1).build();
        new Runner(opt).run();
    

以上的基准测试结果：

# VM invoker: C:\Program Files\Java\jdk1.7.0_40\jre\bin\java.exe
# VM options: -Dfile.encoding=UTF-8

Benchmark                   (value)   Mode  Samples     Score     Error   Units
benchmarkReturnOrdinal            3  thrpt        4  1059.898 ±  71.749  ops/us
benchmarkReturnOrdinal            2  thrpt        4  1051.122 ±  61.238  ops/us
benchmarkReturnOrdinal            1  thrpt        4  1064.067 ±  90.057  ops/us
benchmarkReturnReference          3  thrpt        4   353.197 ±  25.946  ops/us
benchmarkReturnReference          2  thrpt        4   350.902 ±  19.487  ops/us
benchmarkReturnReference          1  thrpt        4   339.578 ± 144.093  ops/us

只需更改函数的返回类型，性能就几乎提高了 3 倍。

我认为返回枚举对象与整数之间的唯一区别是一个返回一个 64 位值（引用），另一个返回一个 32 位值。我的一位同事猜测返回枚举会增加额外的开销，因为需要跟踪潜在 GC 的引用。 （但鉴于枚举对象是静态最终引用，它需要这样做似乎很奇怪）。

性能差异的解释是什么？

---

更新

我分享了 maven 项目here，以便任何人都可以克隆它并运行基准测试。如果有人有时间/兴趣，看看其他人是否可以复制相同的结果会很有帮助。 （我在 2 台不同的机器上进行了复制，Windows 64 和 Linux 64，两者都使用 Oracle Java 1.7 JVM 的风格）。 @ZhekaKozlov 说他没有看到这些方法之间有任何区别。

运行：（克隆存储库后）

mvn clean install
java -jar .\target\microbenchmarks.jar function.ReturnEnumObjectVersusPrimitiveBenchmark -i 5 -wi 5 -f 1

【问题讨论】：

评论不用于扩展讨论；这个对话是moved to chat。

【参考方案1】：

TL;DR：你不应该盲目相信任何事情。

首先要做的是：在得出结论之前验证实验数据非常重要。仅仅声称某些东西快/慢 3 倍是奇怪的，因为您确实需要跟进性能差异的原因，而不仅仅是相信数字。这对于像您这样的纳米基准尤其重要。

其次，实验者应该清楚地了解他们控制什么，不控制什么。在您的特定示例中，您正在从 @Benchmark 方法返回值，但是您能否合理地确定外部的调用者将对原语和参考做同样的事情？如果您问自己这个问题，那么您会意识到您基本上是在测量测试基础架构。

言归正传。在我的机器上（i5-4210U，Linux x86_64，JDK 8u40），测试结果：

Benchmark                    (value)   Mode  Samples  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt        5  0.876 ± 0.023  ops/ns
...benchmarkReturnOrdinal          2  thrpt        5  0.876 ± 0.009  ops/ns
...benchmarkReturnOrdinal          1  thrpt        5  0.832 ± 0.048  ops/ns
...benchmarkReturnReference        3  thrpt        5  0.292 ± 0.006  ops/ns
...benchmarkReturnReference        2  thrpt        5  0.286 ± 0.024  ops/ns
...benchmarkReturnReference        1  thrpt        5  0.293 ± 0.008  ops/ns

好的，所以参考测试看起来慢了 3 倍。但是等等，它使用的是旧的 JMH (1.1.1)，让我们更新到当前最新的 (1.7.1)：

Benchmark                    (value)   Mode  Cnt  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt    5  0.326 ± 0.010  ops/ns
...benchmarkReturnOrdinal          2  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnOrdinal          1  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnReference        3  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        2  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        1  thrpt    5  0.288 ± 0.002  ops/ns

糟糕，现在它们只是稍微慢了一点。顺便说一句，这也告诉我们测试是受基础设施约束的。好的，我们能看看到底发生了什么吗？

如果您构建基准，并查看究竟调用了您的 @Benchmark 方法，那么您会看到类似的内容：

public void benchmarkReturnOrdinal_thrpt_jmhStub(InfraControl control, RawResults result, ReturnEnumObjectVersusPrimitiveBenchmark_jmh l_returnenumobjectversusprimitivebenchmark0_0, Blackhole_jmh l_blackhole1_1) throws Throwable 
    long operations = 0;
    long realTime = 0;
    result.startTime = System.nanoTime();
    do 
        l_blackhole1_1.consume(l_longname.benchmarkReturnOrdinal());
        operations++;
     while(!control.isDone);
    result.stopTime = System.nanoTime();
    result.realTime = realTime;
    result.measuredOps = operations;

l_blackhole1_1 有一个 consume 方法，它“使用”这些值（有关基本原理，请参阅 Blackhole）。 Blackhole.consume 对 references 和 primitives 有重载，仅此一项就足以证明性能差异是合理的。

这些方法看起来不同是有原因的：它们试图尽可能快地处理它们的论点类型。即使我们尝试匹配它们，它们也不一定表现出相同的性能特征，因此新 JMH 的结果更加对称。现在，您甚至可以转到 -prof perfasm 查看为您的测试生成的代码，并了解为什么性能会有所不同，但这已经超出了这里的重点。

如果您真的想了解返回原语和/或引用在性能方面有何不同，您需要输入一个可怕的灰色地带 细致入微的性能基准测试。例如。类似这样的测试：

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(5)
public class PrimVsRef 

    @Benchmark
    public void prim() 
        doPrim();
    

    @Benchmark
    public void ref() 
        doRef();
    

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private int doPrim() 
        return 42;
    

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private Object doRef() 
        return this;
    

...对于原语和引用产生相同的结果：

Benchmark       Mode  Cnt  Score   Error  Units
PrimVsRef.prim  avgt   25  2.637 ± 0.017  ns/op
PrimVsRef.ref   avgt   25  2.634 ± 0.005  ns/op

正如我上面所说，这些测试需要跟进结果的原因。在这种情况下，两者生成的代码几乎相同，这就解释了结果。

主要：

                  [Verified Entry Point]
 12.69%    1.81%    0x00007f5724aec100: mov    %eax,-0x14000(%rsp)
  0.90%    0.74%    0x00007f5724aec107: push   %rbp
  0.01%    0.01%    0x00007f5724aec108: sub    $0x30,%rsp         
 12.23%   16.00%    0x00007f5724aec10c: mov    $0x2a,%eax   ; load "42"
  0.95%    0.97%    0x00007f5724aec111: add    $0x30,%rsp
           0.02%    0x00007f5724aec115: pop    %rbp
 37.94%   54.70%    0x00007f5724aec116: test   %eax,0x10d1aee4(%rip)        
  0.04%    0.02%    0x00007f5724aec11c: retq  

参考：

                  [Verified Entry Point]
 13.52%    1.45%    0x00007f1887e66700: mov    %eax,-0x14000(%rsp)
  0.60%    0.37%    0x00007f1887e66707: push   %rbp
           0.02%    0x00007f1887e66708: sub    $0x30,%rsp         
 13.63%   16.91%    0x00007f1887e6670c: mov    %rsi,%rax     ; load "this"
  0.50%    0.49%    0x00007f1887e6670f: add    $0x30,%rsp
  0.01%             0x00007f1887e66713: pop    %rbp
 39.18%   57.65%    0x00007f1887e66714: test   %eax,0xe3e78e6(%rip)
  0.02%             0x00007f1887e6671a: retq   

[讽刺] 看看这有多容易！ [/讽刺]

模式是：问题越简单，你就越需要努力做出合理可靠的答案。

【讨论】：

合格的答案。那么你建议什么来执行有效的基准测试呢？我建议在基准方法本身中构建一个循环和一个不可优化的消费者。这样，测试框架的性能就会消失在噪音中。

呃，我先笼统地回答一下。我建议从某件事开始，看看它最终做了什么，然后修复它，直到它完成你想要的。

现在，更具体的答案。 JMH 自己生成循环，并为用户调用“不可优化”Blackhole.consume。您可以可能将其拉入@Benchmark 方法，并使用不可内联的方法将结果放入其中，但这仅在您遇到更智能的优化器之前有效...虽然我们可以重新考虑 JMH当这种情况发生时确实卧底，用户黑客将不可避免地落后。然后，那些更信任他们的神圣代码而不是神圣的基准测试框架的用户将在地狱中燃烧！

@usr 有了 Hotspot，您可以使用-Xint，您的大部分基准测试问题都会迎刃而解。 （请不要）“电力公司因此而讨厌我。” (c)

很好的答案。就我个人而言，我肯定会只查看给定测试的程序集，因为即使使用 jmh，这些微测试也很容易出错，正如这个问题很好地展示的那样。如果您那么担心性能，那么了解汇编是一个非常有用的工具。 @usr 如果我有足够的时间，我真的想为 .NET 实现类似 jmh 的东西（我已经完成了大约三分之一），而且与 Java/HotSpot 相比，它非常非常容易；）

【参考方案2】：

为了消除对 reference 和 memory 有些人陷入的误解 (@Mzf)，让我们深入了解 Java 虚拟机规范。 但是在去那里之前，必须澄清一件事 - 一个对象永远不能从内存中检索，只有它的字段可以。事实上，没有任何操作码可以执行如此广泛的操作。

本文档将引用定义为第一类的堆栈类型（因此它可能是对堆栈执行操作的指令的结果或参数） - 采用单个堆栈字的类型类别（ 32 位）。见表 2.3 .

此外，如果方法调用按照规范正常完成，则从堆栈顶部弹出的值被压入方法调用者的堆栈（第 2.6.4 节）。

您的问题是导致执行时间不同的原因。第2章前言答案：

不属于 Java 虚拟机规范的实现细节 会不必要地限制实施者的创造力。例如， 运行时数据区域的内存布局、使用的垃圾收集算法，以及 Java 虚拟机指令的任何内部优化（例如， 将它们翻译成机器代码）由实现者自行决定。

换句话说，由于出于逻辑原因，文档中没有说明与引用使用有关的性能损失之类的事情（它最终只是一个堆栈词，如 int 或 float 是），你只剩下搜索您的实现的源代码或根本找不到。

在某种程度上，我们实际上不应该总是责怪实施，在寻找答案时，您可以采取一些线索。 Java 定义了用于操作数字和引用的单独指令。引用操作指令以a 开头（例如astore、aload 或areturn）并且是唯一允许使用引用的指令。特别是您可能有兴趣查看areturn 的实现。

【讨论】：

引用一定要占用32 bits?

这如何回答这个问题还不是很明显。

在想知道 Java 程序的性能总是时谈论 Java 字节码没有抓住重点。 “看看areturn 的实现”没有任何意义——这不是现代编译器的工作方式（出于性能原因，即使是 HotSpot 解释器也不再真正一次解释一条指令）