显然在我的带有 HotSpot JDK 1.7.0_45(所有编译器/VM 选项设置为默认值)的 Windows 8 笔记本电脑上，下面的循环

final int n = Integer.MAX_VALUE;
int i = 0;
while (++i < n) {
}

至少比以下速度快 2 个数量级(~10 ms 对 ~5000 ms):

final int n = Integer.MAX_VALUE;
int i = 0;
while (i++ < n) {
}

我在编写一个循环来评估另一个不相关的性能问题时碰巧注意到了这个问题。和++i < n的区别和 i++ < n大到足以显着影响结果。

如果我们看字节码，更快版本的循环体是:

iinc
iload
ldc
if_icmplt

对于较慢的版本:

iload
iinc
ldc
if_icmplt

所以对于 ++i < n , 它首先增加局部变量 i 1，然后将其压入操作数堆栈，而 i++ < n以相反的顺序执行这两个步骤。但这似乎并不能解释为什么前者要快得多。后一种情况是否涉及任何临时副本？或者是字节码之外的东西(VM 实现、硬件等)应该对性能差异负责？

我读过一些关于 ++i 的其他讨论。和 i++ (虽然不是详尽无遗)，但没有找到任何特定于 Java 且与 ++i 的情况直接相关的答案。或 i++参与值(value)比较。

最佳答案

正如其他人所指出的，该测试在许多方面存在缺陷。

您没有准确地告诉我们您是如何进行此测试的。但是，我尝试像这样实现“幼稚”测试(无冒犯):

class PrePostIncrement
{
    public static void main(String args[])
    {
        for (int j=0; j<3; j++)
        {
            for (int i=0; i<5; i++)
            {
                long before = System.nanoTime();
                runPreIncrement();
                long after = System.nanoTime();
                System.out.println("pre  : "+(after-before)/1e6);
            }
            for (int i=0; i<5; i++)
            {
                long before = System.nanoTime();
                runPostIncrement();
                long after = System.nanoTime();
                System.out.println("post : "+(after-before)/1e6);
            }
        }
    }

    private static void runPreIncrement()
    {
        final int n = Integer.MAX_VALUE;
        int i = 0;
        while (++i < n) {}
    }

    private static void runPostIncrement()
    {
        final int n = Integer.MAX_VALUE;
        int i = 0;
        while (i++ < n) {}
    }
}

使用默认设置运行此程序时，似乎存在细微差别。但是，当您使用 -server 标志运行它时，基准的 真正 缺陷会变得很明显。在我的情况下，结果类似于

...
pre  : 6.96E-4
pre  : 6.96E-4
pre  : 0.001044
pre  : 3.48E-4
pre  : 3.48E-4
post : 1279.734543
post : 1295.989086
post : 1284.654267
post : 1282.349093
post : 1275.204583

显然，预增量版本已完全优化。原因很简单:结果没有被使用。循环是否执行都没有关系，因此 JIT 只是将其删除。

看一下热点反汇编就证实了这一点:预增量版本导致这段代码:

[Entry Point]
[Verified Entry Point]
[Constants]
  # {method} {0x0000000055060500} 'runPreIncrement' '()V' in 'PrePostIncrement'
  #           [sp+0x20]  (sp of caller)
  0x000000000286fd80: sub    $0x18,%rsp
  0x000000000286fd87: mov    %rbp,0x10(%rsp)    ;*synchronization entry
                                                ; - PrePostIncrement::runPreIncrement@-1 (line 28)

  0x000000000286fd8c: add    $0x10,%rsp
  0x000000000286fd90: pop    %rbp
  0x000000000286fd91: test   %eax,-0x243fd97(%rip)        # 0x0000000000430000
                                                ;   {poll_return}
  0x000000000286fd97: retq   
  0x000000000286fd98: hlt    
  0x000000000286fd99: hlt    
  0x000000000286fd9a: hlt    
  0x000000000286fd9b: hlt    
  0x000000000286fd9c: hlt    
  0x000000000286fd9d: hlt    
  0x000000000286fd9e: hlt    
  0x000000000286fd9f: hlt    

后增量版本的结果如下:

[Entry Point]
[Verified Entry Point]
[Constants]
  # {method} {0x00000000550605b8} 'runPostIncrement' '()V' in 'PrePostIncrement'
  #           [sp+0x20]  (sp of caller)
  0x000000000286d0c0: sub    $0x18,%rsp
  0x000000000286d0c7: mov    %rbp,0x10(%rsp)    ;*synchronization entry
                                                ; - PrePostIncrement::runPostIncrement@-1 (line 35)

  0x000000000286d0cc: mov    $0x1,%r11d
  0x000000000286d0d2: jmp    0x000000000286d0e3
  0x000000000286d0d4: nopl   0x0(%rax,%rax,1)
  0x000000000286d0dc: data32 data32 xchg %ax,%ax
  0x000000000286d0e0: inc    %r11d              ; OopMap{off=35}
                                                ;*goto
                                                ; - PrePostIncrement::runPostIncrement@11 (line 36)

  0x000000000286d0e3: test   %eax,-0x243d0e9(%rip)        # 0x0000000000430000
                                                ;*goto
                                                ; - PrePostIncrement::runPostIncrement@11 (line 36)
                                                ;   {poll}
  0x000000000286d0e9: cmp    $0x7fffffff,%r11d
  0x000000000286d0f0: jl     0x000000000286d0e0  ;*if_icmpge
                                                ; - PrePostIncrement::runPostIncrement@8 (line 36)

  0x000000000286d0f2: add    $0x10,%rsp
  0x000000000286d0f6: pop    %rbp
  0x000000000286d0f7: test   %eax,-0x243d0fd(%rip)        # 0x0000000000430000
                                                ;   {poll_return}
  0x000000000286d0fd: retq   
  0x000000000286d0fe: hlt    
  0x000000000286d0ff: hlt    

我并不完全清楚为什么它似乎没有删除后增量版本。 (事实上​​，我认为这是一个单独的问题)。但至少，这解释了为什么您可能会看到“数量级”的差异......

编辑:有趣的是，将循环的上限从 Integer.MAX_VALUE 更改为 Integer.MAX_VALUE-1，然后是 both 版本被优化掉并且需要“零”时间。不知何故，这个限制(在程序集中仍然显示为 0x7fffffff)阻止了优化。据推测，这与映射到(singed!) cmp 指令的比较有关，但除此之外我无法给出深刻的原因。 JIT 以神秘的方式工作...

关于java - 为什么 "while (i++ < n) {}"明显比 "while (++i < n) {}"慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25322679/