为何Java编译器不将布尔变量调用内联到单个if条件中？

Great question—let's break down why you're seeing this behavior and what's going on under the hood.

First, let's recap your scenario:

• Your original code stores the results of someList.contains(id) and checkIfDisabled(id) in local variables, then uses && to check both.
• You expected the compiler to inline these into a single if condition (enabling short-circuit evaluation, so checkIfDisabled only runs if isHidden is true).
• But javac kept the local variables intact, meaning checkIfDisabled runs every time—this was hurting performance until you manually inlined the code.

Here's why the compiler doesn't automatically do this inline: #

1. javac is intentionally conservative with optimizations
   The standard Java compiler (javac) focuses on generating correct, debuggable bytecode, not aggressive runtime optimizations. Most heavy lifting (like inlining, loop unrolling, etc.) is delegated to the JVM's Just-In-Time (JIT) compiler, which kicks in during runtime when the code is executed repeatedly. javac won't rearrange your code structure unless it's guaranteed to have zero impact on semantics or debugging—this kind of inline falls outside its core responsibilities.

2. Local variables are preserved for debugging and readability
   Keeping those local variables around makes debugging easier: if you set a breakpoint in that method, you can inspect the values of isHidden and isDisabled directly. The compiler prioritizes preserving the structure you wrote (and the ability to debug it) over this specific performance optimization. The Java Language Specification doesn't mandate this optimization, so javac errs on the side of keeping your code's original structure.

3. Short-circuit evaluation depends on expression order in the && operator
   When you assign the results to local variables first, you've already forced both methods to execute before the && check runs. The bytecode for isHidden && isDisabled just operates on two boolean values that are already in memory—there's no way to "undo" the earlier method calls. The compiler can't retroactively change the execution order because that would alter the original code's behavior (even if it's logically equivalent for your use case).

What you can do about it: #

• Manual inline (like you did) is the most reliable way to guarantee short-circuit evaluation. Writing if (someList.contains(id) && checkIfDisabled(id)) ensures javac generates bytecode that skips checkIfDisabled when someList.contains(id) is false.
• Trust JIT optimizations (with caveats)：If your method is called frequently enough, the JVM's JIT compiler may eventually inline the local variables and optimize the short-circuit behavior. But this isn't guaranteed, especially during application startup (before JIT kicks in), so relying on this for critical performance paths is risky.

内容的提问来源于stack exchange，提问作者Allan