在Java中，&可以比&&快吗？

好的，所以你想知道它在较低级别的行为......那么让我们看看字节码！

^{编辑：最后添加了为 AMD64 生成的汇编代码。看看一些有趣的注释。
EDIT 2（re：OP 的“Update 2”）：也为 Guava's isPowerOfTwo method 添加了 asm 代码。}

Java 源代码

我写了这两个快速方法：

public boolean AndSC(int x, int value, int y) {
    return value >= x && value <= y;
}

public boolean AndNonSC(int x, int value, int y) {
    return value >= x & value <= y;
}

如您所见，它们完全相同，除了 AND 运算符的类型。

Java 字节码

这是生成的字节码：

  public AndSC(III)Z
   L0
    LINENUMBER 8 L0
    ILOAD 2
    ILOAD 1
    IF_ICMPLT L1
    ILOAD 2
    ILOAD 3
    IF_ICMPGT L1
   L2
    LINENUMBER 9 L2
    ICONST_1
    IRETURN
   L1
    LINENUMBER 11 L1
   FRAME SAME
    ICONST_0
    IRETURN
   L3
    LOCALVARIABLE this Ltest/lsoto/AndTest; L0 L3 0
    LOCALVARIABLE x I L0 L3 1
    LOCALVARIABLE value I L0 L3 2
    LOCALVARIABLE y I L0 L3 3
    MAXSTACK = 2
    MAXLOCALS = 4

  // access flags 0x1
  public AndNonSC(III)Z
   L0
    LINENUMBER 15 L0
    ILOAD 2
    ILOAD 1
    IF_ICMPLT L1
    ICONST_1
    GOTO L2
   L1
   FRAME SAME
    ICONST_0
   L2
   FRAME SAME1 I
    ILOAD 2
    ILOAD 3
    IF_ICMPGT L3
    ICONST_1
    GOTO L4
   L3
   FRAME SAME1 I
    ICONST_0
   L4
   FRAME FULL [test/lsoto/AndTest I I I] [I I]
    IAND
    IFEQ L5
   L6
    LINENUMBER 16 L6
    ICONST_1
    IRETURN
   L5
    LINENUMBER 18 L5
   FRAME SAME
    ICONST_0
    IRETURN
   L7
    LOCALVARIABLE this Ltest/lsoto/AndTest; L0 L7 0
    LOCALVARIABLE x I L0 L7 1
    LOCALVARIABLE value I L0 L7 2
    LOCALVARIABLE y I L0 L7 3
    MAXSTACK = 3
    MAXLOCALS = 4

AndSC (&&) 方法按预期生成 两个 条件跳转：

它将 value 和 x 加载到堆栈中，如果 value 较低，则跳转到 L1。否则它会继续运行下一行。它将 value 和 y 加载到堆栈中，如果 value 更大，它也会跳转到 L1。否则它会继续运行下一行。如果两次跳跃都没有发生，这恰好是一个返回 true。然后我们将标记为 L1 的行返回 false。

但是，AndNonSC (&) 方法会生成 三个 条件跳转！

它将 value 和 x 加载到堆栈中，如果 value 较低，则跳转到 L1。因为现在它需要保存结果来与AND的其他部分进行比较，所以它必须执行“save true”或“save false”，它不能用相同的指令同时执行。它将 value 和 y 加载到堆栈中，如果 value 更大，则跳转到 L1。再一次，它需要保存 true 或 false，这取决于比较结果是两条不同的行。现在两个比较都完成了，代码实际上执行了 AND 操作——如果两者都为真，它会跳转（第三次）返回真；否则它会继续执行到下一行以返回 false。

（初步）结论

虽然我对 Java 字节码的经验不是很丰富，而且我可能忽略了一些东西，但在我看来，& 在任何情况下实际上都会比 && 执行更糟糕：它会生成更多指令执行，包括更多的条件跳转来预测和可能失败。

正如其他人建议的那样，重写代码以用算术运算替换比较可能是使 & 成为更好选择的一种方法，但代价是使代码变得不那么清晰。
恕我直言，这不值得99% 的场景的麻烦（不过，对于需要极度优化的 1% 循环来说，这可能是非常值得的）。

编辑：AMD64 组件

正如评论中所指出的，相同的 Java 字节码可能会导致不同系统中的不同机器码，因此虽然 Java 字节码可能会提示我们哪个 AND 版本的性能更好，但获取编译器生成的实际 ASM 是唯一的方法真正找出答案。我为这两种方法打印了 AMD64 ASM 指令；以下是相关行（剥离的入口点等）。

注意：除非另有说明，否则所有使用 java 1.8.0_91 编译的方法。

使用默认选项的方法 AndSC

  # {method} {0x0000000016da0810} 'AndSC' '(III)Z' in 'AndTest'
  ...
  0x0000000002923e3e: cmp    %r8d,%r9d
  0x0000000002923e41: movabs $0x16da0a08,%rax   ;   {metadata(method data for {method} {0x0000000016da0810} 'AndSC' '(III)Z' in 'AndTest')}
  0x0000000002923e4b: movabs $0x108,%rsi
  0x0000000002923e55: jl     0x0000000002923e65
  0x0000000002923e5b: movabs $0x118,%rsi
  0x0000000002923e65: mov    (%rax,%rsi,1),%rbx
  0x0000000002923e69: lea    0x1(%rbx),%rbx
  0x0000000002923e6d: mov    %rbx,(%rax,%rsi,1)
  0x0000000002923e71: jl     0x0000000002923eb0  ;*if_icmplt
                                                ; - AndTest::AndSC@2 (line 22)

  0x0000000002923e77: cmp    %edi,%r9d
  0x0000000002923e7a: movabs $0x16da0a08,%rax   ;   {metadata(method data for {method} {0x0000000016da0810} 'AndSC' '(III)Z' in 'AndTest')}
  0x0000000002923e84: movabs $0x128,%rsi
  0x0000000002923e8e: jg     0x0000000002923e9e
  0x0000000002923e94: movabs $0x138,%rsi
  0x0000000002923e9e: mov    (%rax,%rsi,1),%rdi
  0x0000000002923ea2: lea    0x1(%rdi),%rdi
  0x0000000002923ea6: mov    %rdi,(%rax,%rsi,1)
  0x0000000002923eaa: jle    0x0000000002923ec1  ;*if_icmpgt
                                                ; - AndTest::AndSC@7 (line 22)

  0x0000000002923eb0: mov    $0x0,%eax
  0x0000000002923eb5: add    $0x30,%rsp
  0x0000000002923eb9: pop    %rbp
  0x0000000002923eba: test   %eax,-0x1c73dc0(%rip)        # 0x0000000000cb0100
                                                ;   {poll_return}
  0x0000000002923ec0: retq                      ;*ireturn
                                                ; - AndTest::AndSC@13 (line 25)

  0x0000000002923ec1: mov    $0x1,%eax
  0x0000000002923ec6: add    $0x30,%rsp
  0x0000000002923eca: pop    %rbp
  0x0000000002923ecb: test   %eax,-0x1c73dd1(%rip)        # 0x0000000000cb0100
                                                ;   {poll_return}
  0x0000000002923ed1: retq   

方法 AndSC 和 -XX:PrintAssemblyOptions=intel 选项

  # {method} {0x00000000170a0810} 'AndSC' '(III)Z' in 'AndTest'
  ...
  0x0000000002c26e2c: cmp    r9d,r8d
  0x0000000002c26e2f: jl     0x0000000002c26e36  ;*if_icmplt
  0x0000000002c26e31: cmp    r9d,edi
  0x0000000002c26e34: jle    0x0000000002c26e44  ;*iconst_0
  0x0000000002c26e36: xor    eax,eax            ;*synchronization entry
  0x0000000002c26e38: add    rsp,0x10
  0x0000000002c26e3c: pop    rbp
  0x0000000002c26e3d: test   DWORD PTR [rip+0xffffffffffce91bd],eax        # 0x0000000002910000
  0x0000000002c26e43: ret    
  0x0000000002c26e44: mov    eax,0x1
  0x0000000002c26e49: jmp    0x0000000002c26e38

使用默认选项的方法 AndNonSC

  # {method} {0x0000000016da0908} 'AndNonSC' '(III)Z' in 'AndTest'
  ...
  0x0000000002923a78: cmp    %r8d,%r9d
  0x0000000002923a7b: mov    $0x0,%eax
  0x0000000002923a80: jl     0x0000000002923a8b
  0x0000000002923a86: mov    $0x1,%eax
  0x0000000002923a8b: cmp    %edi,%r9d
  0x0000000002923a8e: mov    $0x0,%esi
  0x0000000002923a93: jg     0x0000000002923a9e
  0x0000000002923a99: mov    $0x1,%esi
  0x0000000002923a9e: and    %rsi,%rax
  0x0000000002923aa1: cmp    $0x0,%eax
  0x0000000002923aa4: je     0x0000000002923abb  ;*ifeq
                                                ; - AndTest::AndNonSC@21 (line 29)

  0x0000000002923aaa: mov    $0x1,%eax
  0x0000000002923aaf: add    $0x30,%rsp
  0x0000000002923ab3: pop    %rbp
  0x0000000002923ab4: test   %eax,-0x1c739ba(%rip)        # 0x0000000000cb0100
                                                ;   {poll_return}
  0x0000000002923aba: retq                      ;*ireturn
                                                ; - AndTest::AndNonSC@25 (line 30)

  0x0000000002923abb: mov    $0x0,%eax
  0x0000000002923ac0: add    $0x30,%rsp
  0x0000000002923ac4: pop    %rbp
  0x0000000002923ac5: test   %eax,-0x1c739cb(%rip)        # 0x0000000000cb0100
                                                ;   {poll_return}
  0x0000000002923acb: retq   

方法 AndNonSC 和 -XX:PrintAssemblyOptions=intel 选项

  # {method} {0x00000000170a0908} 'AndNonSC' '(III)Z' in 'AndTest'
  ...
  0x0000000002c270b5: cmp    r9d,r8d
  0x0000000002c270b8: jl     0x0000000002c270df  ;*if_icmplt
  0x0000000002c270ba: mov    r8d,0x1            ;*iload_2
  0x0000000002c270c0: cmp    r9d,edi
  0x0000000002c270c3: cmovg  r11d,r10d
  0x0000000002c270c7: and    r8d,r11d
  0x0000000002c270ca: test   r8d,r8d
  0x0000000002c270cd: setne  al
  0x0000000002c270d0: movzx  eax,al
  0x0000000002c270d3: add    rsp,0x10
  0x0000000002c270d7: pop    rbp
  0x0000000002c270d8: test   DWORD PTR [rip+0xffffffffffce8f22],eax        # 0x0000000002910000
  0x0000000002c270de: ret    
  0x0000000002c270df: xor    r8d,r8d
  0x0000000002c270e2: jmp    0x0000000002c270c0

首先，生成的 ASM 代码会根据我们选择默认的 AT&T 语法还是 Intel 语法而有所不同。

使用 AT&T 语法：AndSC 方法的 ASM 代码实际上更长，每个字节码 IF_ICMP* 转换为两条汇编跳转指令，总共有 4 次条件跳转。同时，对于 AndNonSC 方法，编译器生成更直接的代码，其中每个字节码 IF_ICMP* 仅转换为一条汇编跳转指令，保持原来的 3 次条件跳转计数。

AndSC 方法的 ASM 代码实际上更长，每个字节码 IF_ICMP* 都被翻译成两条汇编跳转指令，总共有 4 次条件跳转。

同时，对于 AndNonSC 方法，编译器生成更直接的代码，其中每个字节码 IF_ICMP* 仅转换为一条汇编跳转指令，保持原来的 3 次条件跳转计数。

使用 Intel 语法：AndSC 的 ASM 代码更短，只有 2 个条件跳转（不包括最后的非条件 jmp）。实际上它只是两个 CMP、两个 JL/E 和一个 XOR/MOV，具体取决于结果。 AndNonSC 的 ASM 代码现在比 AndSC 的代码长！但是，它只有一个条件跳转（用于第一次比较），使用寄存器直接将第一个结果与第二个结果进行比较，没有更多的跳转。

AndSC 的 ASM 代码更短，只有 2 个条件跳转（不包括最后的非条件 jmp）。实际上它只是两个 CMP、两个 JL/E 和一个 XOR/MOV，具体取决于结果。

AndNonSC 的 ASM 代码现在比 AndSC 的代码长！但是，它只有一个条件跳转（用于第一次比较），使用寄存器直接将第一个结果与第二个结果进行比较，没有更多的跳转。

ASM代码分析后的结论

在 AMD64 机器语言级别，& 运算符似乎生成具有较少条件跳转的 ASM 代码，这对于高预测失败率（例如随机值）可能更好。

另一方面，&& 运算符似乎生成的 ASM 代码指令较少（无论如何都使用 -XX:PrintAssemblyOptions=intel 选项），这对于具有预测友好输入的真正长循环可能更好，其中 CPU 周期数较少从长远来看，每次比较都会产生影响。

正如我在一些评论中所说，这在系统之间会有很大差异，所以如果我们谈论分支预测优化，唯一真正的答案是：它取决于你的 JVM 实现、你的编译器、你的 CPU 和你的输入数据。

附录：Guava 的 isPowerOfTwo 方法

在这里，Guava 的开发人员提出了一种计算给定数字是否为 2 的幂的简洁方法：

public static boolean isPowerOfTwo(long x) {
    return x > 0 & (x & (x - 1)) == 0;
}

引用 OP：

这种使用 & （其中 && 会更正常）是真正的优化吗？

为了确定是否是，我在我的测试类中添加了两个类似的方法：

public boolean isPowerOfTwoAND(long x) {
    return x > 0 & (x & (x - 1)) == 0;
}

public boolean isPowerOfTwoANDAND(long x) {
    return x > 0 && (x & (x - 1)) == 0;
}

英特尔的 Guava 版本的 ASM 代码

  # {method} {0x0000000017580af0} 'isPowerOfTwoAND' '(J)Z' in 'AndTest'
  # this:     rdx:rdx   = 'AndTest'
  # parm0:    r8:r8     = long
  ...
  0x0000000003103bbe: movabs rax,0x0
  0x0000000003103bc8: cmp    rax,r8
  0x0000000003103bcb: movabs rax,0x175811f0     ;   {metadata(method data for {method} {0x0000000017580af0} 'isPowerOfTwoAND' '(J)Z' in 'AndTest')}
  0x0000000003103bd5: movabs rsi,0x108
  0x0000000003103bdf: jge    0x0000000003103bef
  0x0000000003103be5: movabs rsi,0x118
  0x0000000003103bef: mov    rdi,QWORD PTR [rax+rsi*1]
  0x0000000003103bf3: lea    rdi,[rdi+0x1]
  0x0000000003103bf7: mov    QWORD PTR [rax+rsi*1],rdi
  0x0000000003103bfb: jge    0x0000000003103c1b  ;*lcmp
  0x0000000003103c01: movabs rax,0x175811f0     ;   {metadata(method data for {method} {0x0000000017580af0} 'isPowerOfTwoAND' '(J)Z' in 'AndTest')}
  0x0000000003103c0b: inc    DWORD PTR [rax+0x128]
  0x0000000003103c11: mov    eax,0x1
  0x0000000003103c16: jmp    0x0000000003103c20  ;*goto
  0x0000000003103c1b: mov    eax,0x0            ;*lload_1
  0x0000000003103c20: mov    rsi,r8
  0x0000000003103c23: movabs r10,0x1
  0x0000000003103c2d: sub    rsi,r10
  0x0000000003103c30: and    rsi,r8
  0x0000000003103c33: movabs rdi,0x0
  0x0000000003103c3d: cmp    rsi,rdi
  0x0000000003103c40: movabs rsi,0x175811f0     ;   {metadata(method data for {method} {0x0000000017580af0} 'isPowerOfTwoAND' '(J)Z' in 'AndTest')}
  0x0000000003103c4a: movabs rdi,0x140
  0x0000000003103c54: jne    0x0000000003103c64
  0x0000000003103c5a: movabs rdi,0x150
  0x0000000003103c64: mov    rbx,QWORD PTR [rsi+rdi*1]
  0x0000000003103c68: lea    rbx,[rbx+0x1]
  0x0000000003103c6c: mov    QWORD PTR [rsi+rdi*1],rbx
  0x0000000003103c70: jne    0x0000000003103c90  ;*lcmp
  0x0000000003103c76: movabs rsi,0x175811f0     ;   {metadata(method data for {method} {0x0000000017580af0} 'isPowerOfTwoAND' '(J)Z' in 'AndTest')}
  0x0000000003103c80: inc    DWORD PTR [rsi+0x160]
  0x0000000003103c86: mov    esi,0x1
  0x0000000003103c8b: jmp    0x0000000003103c95  ;*goto
  0x0000000003103c90: mov    esi,0x0            ;*iand
  0x0000000003103c95: and    rsi,rax
  0x0000000003103c98: and    esi,0x1
  0x0000000003103c9b: mov    rax,rsi
  0x0000000003103c9e: add    rsp,0x50
  0x0000000003103ca2: pop    rbp
  0x0000000003103ca3: test   DWORD PTR [rip+0xfffffffffe44c457],eax        # 0x0000000001550100
  0x0000000003103ca9: ret    

英特尔的 && 版本的 asm 代码

  # {method} {0x0000000017580bd0} 'isPowerOfTwoANDAND' '(J)Z' in 'AndTest'
  # this:     rdx:rdx   = 'AndTest'
  # parm0:    r8:r8     = long
  ...
  0x0000000003103438: movabs rax,0x0
  0x0000000003103442: cmp    rax,r8
  0x0000000003103445: jge    0x0000000003103471  ;*lcmp
  0x000000000310344b: mov    rax,r8
  0x000000000310344e: movabs r10,0x1
  0x0000000003103458: sub    rax,r10
  0x000000000310345b: and    rax,r8
  0x000000000310345e: movabs rsi,0x0
  0x0000000003103468: cmp    rax,rsi
  0x000000000310346b: je     0x000000000310347b  ;*lcmp
  0x0000000003103471: mov    eax,0x0
  0x0000000003103476: jmp    0x0000000003103480  ;*ireturn
  0x000000000310347b: mov    eax,0x1            ;*goto
  0x0000000003103480: and    eax,0x1
  0x0000000003103483: add    rsp,0x40
  0x0000000003103487: pop    rbp
  0x0000000003103488: test   DWORD PTR [rip+0xfffffffffe44cc72],eax        # 0x0000000001550100
  0x000000000310348e: ret    

在这个具体示例中，JIT 编译器为 && 版本生成的汇编代码比为 Guava 的 & 版本少远（而且，在昨天的结果之后，我真的对此感到惊讶）。
与 Guava 相比，&& 版本转换为 JIT 编译的字节码减少了 25%，汇编指令减少了 50%，并且只有两个条件跳转（& 版本有四个）。

因此，一切都表明 Guava 的 & 方法效率低于更“自然”的 && 版本。

……或者是吗？

如前所述，我使用 Java 8 运行上述示例：

C:\....>java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

但是如果我切换到 Java 7 会怎样？

C:\....>c:\jdk1.7.0_79\bin\java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
C:\....>c:\jdk1.7.0_79\bin\java -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,*AndTest.isPowerOfTwoAND -XX:PrintAssemblyOptions=intel AndTestMain
  .....
  0x0000000002512bac: xor    r10d,r10d
  0x0000000002512baf: mov    r11d,0x1
  0x0000000002512bb5: test   r8,r8
  0x0000000002512bb8: jle    0x0000000002512bde  ;*ifle
  0x0000000002512bba: mov    eax,0x1            ;*lload_1
  0x0000000002512bbf: mov    r9,r8
  0x0000000002512bc2: dec    r9
  0x0000000002512bc5: and    r9,r8
  0x0000000002512bc8: test   r9,r9
  0x0000000002512bcb: cmovne r11d,r10d
  0x0000000002512bcf: and    eax,r11d           ;*iand
  0x0000000002512bd2: add    rsp,0x10
  0x0000000002512bd6: pop    rbp
  0x0000000002512bd7: test   DWORD PTR [rip+0xffffffffffc0d423],eax        # 0x0000000002120000
  0x0000000002512bdd: ret    
  0x0000000002512bde: xor    eax,eax
  0x0000000002512be0: jmp    0x0000000002512bbf
  .....

惊喜！ Java 7 中 JIT 编译器为 & 方法生成的汇编代码现在只有 一个 条件跳转，而且要短得多！而 && 方法（在这个方法上你必须相信我，我不想弄乱结尾！）保持不变，只有两个条件跳转和几个指令，顶部。
毕竟，Guava 的工程师似乎知道他们在做什么！ （如果他们试图优化 Java 7 的执行时间，那就是 ;-)

回到OP的最新问题：

这种使用 & （其中 && 会更正常）是真正的优化吗？

恕我直言，答案是相同的，即使对于这个（非常！）特定场景：它取决于您的 JVM 实现、编译器、CPU 和输入数据。

---

对于这类问题，您应该运行微基准测试。我在这个测试中使用了 JMH。

基准实现为

// boolean logical AND
bh.consume(value >= x & y <= value);

和

// conditional AND
bh.consume(value >= x && y <= value);

和

// bitwise OR, as suggested by Joop Eggen
bh.consume(((value - x) | (y - value)) >= 0)

根据基准名称使用 value, x and y 的值。

吞吐量基准测试的结果（五次预热和十次测量迭代）是：

Benchmark                                 Mode  Cnt    Score    Error   Units
Benchmark.isBooleanANDBelowRange          thrpt   10  386.086 ▒ 17.383  ops/us
Benchmark.isBooleanANDInRange             thrpt   10  387.240 ▒  7.657  ops/us
Benchmark.isBooleanANDOverRange           thrpt   10  381.847 ▒ 15.295  ops/us
Benchmark.isBitwiseORBelowRange           thrpt   10  384.877 ▒ 11.766  ops/us
Benchmark.isBitwiseORInRange              thrpt   10  380.743 ▒ 15.042  ops/us
Benchmark.isBitwiseOROverRange            thrpt   10  383.524 ▒ 16.911  ops/us
Benchmark.isConditionalANDBelowRange      thrpt   10  385.190 ▒ 19.600  ops/us
Benchmark.isConditionalANDInRange         thrpt   10  384.094 ▒ 15.417  ops/us
Benchmark.isConditionalANDOverRange       thrpt   10  380.913 ▒  5.537  ops/us

评估本身的结果并没有什么不同。只要在那段代码上没有发现性能影响，我就不会尝试优化它。根据代码中的位置，热点编译器可能会决定进行一些优化。上述基准可能未涵盖这些内容。

一些参考资料：

boolean logical AND - 如果两个操作数值为 true，则结果值为 true；否则，结果为 false
conditional AND - 类似于 &，但仅当其左侧操作数的值为 true
bitwise OR 时才计算其右侧操作数 -结果值是操作数值的按位或

---

我将从不同的角度来讨论这个问题。

考虑这两个代码片段，

  if (value >= x && value <= y) {

和

  if (value >= x & value <= y) {

如果我们假设 value、x、y 具有原始类型，那么这两个（部分）语句将对所有可能的输入值给出相同的结果。 （如果涉及包装器类型，则它们不完全等效，因为对 y 的隐式 null 测试可能在 & 版本而不是 && 版本中失败。）

如果 JIT 编译器做得很好，它的优化器将能够推断出这两个语句做同样的事情：

如果一个比另一个更快，那么它应该能够在 JIT 编译代码中使用更快的版本。

如果不是，那么在源代码级别使用哪个版本都没有关系。

由于 JIT 编译器在编译之前会收集路径统计信息，因此它可能拥有更多关于程序员（！）的执行特征的信息。

如果当前一代的 JIT 编译器（在任何给定的平台上）没有优化到足以处理这个问题，那么下一代可以做得很好……取决于经验证据是否表明这是一个值得优化的模式。

实际上，如果您以一种为此优化的方式编写 Java 代码，那么通过选择更“晦涩”的代码版本，您可能会抑制当前或未来 JIT 编译器的优化能力。

总之，我认为你不应该在源代码层面做这种微优化。如果你接受这个论点 1 并遵循它的逻辑结论，那么哪个版本更快的问题是...... moot2。

1 - 我不声称这几乎是一个证据。

- 除非你是真正编写 Java JIT 编译器的一小群人......

“非常著名的问题”在两个方面很有趣：

一方面，这是一个示例，其中所需的优化类型远远超出了 JIT 编译器的能力。

另一方面，对数组进行排序不一定是正确的事情......只是因为可以更快地处理排序的数组。对数组进行排序的成本很可能（远）大于节省的成本。

---

使用 & 或 && 仍然需要评估一个条件，因此它不太可能节省任何处理时间 - 考虑到您在只需要评估一个表达式时同时评估两个表达式，它甚至可能会增加它。

如果在极少数情况下使用 & 而不是 && 来节省一纳秒是没有意义的，那么与使用 & 而不是 && 所节省的时间相比，您已经浪费了更多的时间来考虑差异。

编辑

我很好奇，决定做一些基准测试。

我做了这门课：

public class Main {

    static int x = 22, y = 48;

    public static void main(String[] args) {
        runWithOneAnd(30);
        runWithTwoAnds(30);
    }

    static void runWithOneAnd(int value){
        if(value >= x & value <= y){

        }
    }

    static void runWithTwoAnds(int value){
        if(value >= x && value <= y){

        }
    }
}

并使用 NetBeans 运行了一些分析测试。我没有使用任何打印语句来节省处理时间，只知道两者都评估为 true。

第一次测试：

https://i.stack.imgur.com/1e8iG.png

第二次测试：

https://i.stack.imgur.com/bxZ7t.png

第三次测试：

https://i.stack.imgur.com/W0L6z.png

从分析测试中可以看出，与使用两个 && 相比，仅使用一个 & 的运行时间实际上要长 2-3 倍。这确实有点奇怪，因为我确实期望只有一个 & 有更好的性能。

我不是 100% 确定为什么。在这两种情况下，都必须计算两个表达式，因为它们都是真的。我怀疑 JVM 在幕后做了一些特殊的优化来加速它。

故事的寓意：约定是好的，过早的优化是坏的。

编辑 2

我根据@SvetlinZarev 的评论和其他一些改进重新编写了基准代码。这是修改后的基准代码：

public class Main {

    static int x = 22, y = 48;

    public static void main(String[] args) {
        oneAndBothTrue();
        oneAndOneTrue();
        oneAndBothFalse();
        twoAndsBothTrue();
        twoAndsOneTrue();
        twoAndsBothFalse();
        System.out.println(b);
    }

    static void oneAndBothTrue() {
        int value = 30;
        for (int i = 0; i < 2000; i++) {
            if (value >= x & value <= y) {
                doSomething();
            }
        }
    }

    static void oneAndOneTrue() {
        int value = 60;
        for (int i = 0; i < 4000; i++) {
            if (value >= x & value <= y) {
                doSomething();
            }
        }
    }

    static void oneAndBothFalse() {
        int value = 100;
        for (int i = 0; i < 4000; i++) {
            if (value >= x & value <= y) {
                doSomething();
            }
        }
    }

    static void twoAndsBothTrue() {
        int value = 30;
        for (int i = 0; i < 4000; i++) {
            if (value >= x & value <= y) {
                doSomething();
            }
        }
    }

    static void twoAndsOneTrue() {
        int value = 60;
        for (int i = 0; i < 4000; i++) {
            if (value >= x & value <= y) {
                doSomething();
            }
        }
    }

    static void twoAndsBothFalse() {
        int value = 100;
        for (int i = 0; i < 4000; i++) {
            if (value >= x & value <= y) {
                doSomething();
            }
        }
    }

    //I wanted to avoid print statements here as they can
    //affect the benchmark results. 
    static StringBuilder b = new StringBuilder();
    static int times = 0;

    static void doSomething(){
        times++;
        b.append("I have run ").append(times).append(" times \n");
    }
}

以下是性能测试：

测试1：

https://i.stack.imgur.com/yXjrp.png

测试 2：

https://i.stack.imgur.com/HNfC8.png

测试 3：

https://i.stack.imgur.com/KUC1x.png

这也考虑了不同的值和不同的条件。

当两个条件都为真时，使用一个 & 需要更多时间，大约多 60% 或 2 毫秒。当一个或两个条件都为假时，一个 & 运行得更快，但它的运行速度只快了大约 0.30-0.50 毫秒。所以 & 在大多数情况下会比 && 运行得更快，但性能差异仍然可以忽略不计。

---

你所追求的是这样的：

x <= value & value <= y
value - x >= 0 & y - value >= 0
((value - x) | (y - value)) >= 0  // integer bit-or

有趣的是，几乎想看看字节码。但很难说。我希望这是一个 C 问题。

---

我也很好奇这个答案，所以我为此编写了以下（简单）测试：

private static final int max = 80000;
private static final int size = 100000;
private static final int x = 1500;
private static final int y = 15000;
private Random random;

@Before
public void setUp() {
    this.random = new Random();
}

@After
public void tearDown() {
    random = null;
}

@Test
public void testSingleOperand() {
    int counter = 0;
    int[] numbers = new int[size];
    for (int j = 0; j < size; j++) {
        numbers[j] = random.nextInt(max);
    }

    long start = System.nanoTime(); //start measuring after an array has been filled
    for (int i = 0; i < numbers.length; i++) {
        if (numbers[i] >= x & numbers[i] <= y) {
            counter++;
        }
    }
    long end = System.nanoTime();
    System.out.println("Duration of single operand: " + (end - start));
}

@Test
public void testDoubleOperand() {
    int counter = 0;
    int[] numbers = new int[size];
    for (int j = 0; j < size; j++) {
        numbers[j] = random.nextInt(max);
    }

    long start = System.nanoTime(); //start measuring after an array has been filled
    for (int i = 0; i < numbers.length; i++) {
        if (numbers[i] >= x & numbers[i] <= y) {
            counter++;
        }
    }
    long end = System.nanoTime();
    System.out.println("Duration of double operand: " + (end - start));
}

最终结果是与 && 的比较总是在速度方面获胜，比 & 快大约 1.5/2 毫秒。

编辑：正如@SvetlinZarev 指出的那样，我还在测量 Random 获得整数所花费的时间。将其更改为使用预填充的随机数数组，这导致单操作数测试的持续时间大幅波动；几次运行之间的差异高达 6-7 毫秒。

---

向我解释的方式是，如果系列中的第一个检查为假， && 将返回假，而 & 检查系列中的所有项目，无论有多少是假的。 IE

如果 (x>0 && x <=10 && x

会跑得比

如果 (x>0 & x <=10 & x

如果 x 大于 10，因为单 & 号将继续检查其余条件，而双 & 号将在第一个非真条件后中断。

---