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

我们正在开发一个对延迟敏感的应用程序，并一直在对各种方法进行微基准标记（使用）。在对查找方法进行微基准测试并对结果感到满意后，我实现了最终版本，结果发现最终版本比我刚刚基准测试的慢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();
    }

}

仅更改函数的返回类型就可以将性能更改近3倍

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

性能差异的原因是什么

---

更新

我共享了maven项目，因此任何人都可以克隆它并运行基准测试。如果有人有时间/兴趣，那么看看其他人是否可以复制相同的结果会很有帮助。（我已经在两台不同的机器上进行了复制，Windows 64和Linux 64都使用了Oracle Java 1.7 JVM的风格）@哲卡科兹洛夫说，他没有发现两种方法之间有任何区别

要运行：（克隆存储库后）

---

为了澄清一些人对引用和内存的误解（@Mzf），让我们深入了解Java虚拟机规范。 但在此之前，必须澄清一件事——对象永远无法从内存中检索，只能从其字段中检索。事实上，没有操作码可以执行如此广泛的操作

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

此外，如果方法调用根据规范正常完成，则从堆栈顶部弹出的值被推送到方法调用器的堆栈上（第2.6.4节）

你的问题是什么导致了执行时间的差异。第二章前言回答：

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

换句话说，由于文档中没有出于逻辑原因（它最终只是一个堆栈字，如

int

或

float

are），因此您只能搜索实现的源代码，或者根本找不到

---

在某种程度上，我们不应该总是责怪实施，在寻找答案时，你可以从中得到一些线索。Java为操作数字和引用定义了单独的指令。引用操作说明以

a

开头（例如

astore

、

aload

或

areturn

），是唯一允许使用引用的说明。特别是，您可能对查看

areturn

'的实现感兴趣

TL；医生：你不应该盲目相信任何事情。

第一件事：在得出结论之前，验证实验数据是很重要的。仅仅声称某个东西快/慢3倍是很奇怪的，因为你真的需要跟进性能差异的原因，而不仅仅是相信数字。这对于像您这样的nano基准测试尤其重要

其次，实验者应该清楚地了解他们控制什么和不控制什么。在您的特定示例中，您正在从

@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

方法，那么您将看到如下内容：

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

具有和的重载，仅此一项就足以证明性能差异的合理性

为什么这些方法看起来不同，有一个基本原理：它们试图以尽可能快的速度处理它们的论点类型。它们不一定表现出相同的性能特征，即使我们尝试匹配它们，因此使用较新的JMH会得到更对称的结果。现在，您甚至可以转到

-prof perfasm

查看为测试生成的代码，并了解性能不同的原因，但这超出了本文的重点

如果您真的想了解返回原语和/或引用在性能方面的差异，那么您需要进入一个大的灰色区域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

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

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;
}

@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