Java中是否应停止使用局部变量？字节码差异与性能疑问

我写了两段功能完全等价的Java和C代码，直觉上认为R1和R2的目标代码大小、内容应该一致。用g 9.4带-O1编译C++代码时确实如此（无-O1时仅差4字节），但Java字节码里R2明显更长，这让我很意外。我想知道：Java字节码是不是和源码高度绑定？是不是意味着单行链式写法始终比用局部变量的写法更高效、更优化？

C++代码 #

int A(int a) { return 0; }
int B(int b) { return 0; }
int C(int c) { return 0; }
int D(int d) { return 0; }

int R1() {
  return  A(B(C(3)+D(3)));
}

int R2() {
  int d = D(3);
  int c = C(3);
  int b = B(c + d);
  return A(b);
}

// 随后在main()中调用R1()和R2()

Java代码 #

class MyClass {
  static int A(int a) { return 0; }
  static int B(int b) { return 0; }
  static int C(int c) { return 0; }
  static int D(int d) { return 0; }
  
  static int R1() {
    return  A(B(C(3)+D(3)));
  }
  
  static int R2() {
    int d = D(3);
    int c = C(3);
    int b = B(c + d);
    
    return A(b);
  }

  // 随后在Main()中调用R1和R2
}

编译反汇编结果 #

C++（g++ -O1 prog.cpp） #

R1:
  1251: f3 0f 1e fa             endbr64 
  1255: 53                      push   %rbx
  1256: bf 03 00 00 00          mov    $0x3,%edi
  125b: e8 9d ff ff ff          callq  11fd <_Z1Ci>
  1260: 89 c3                   mov    %eax,%ebx
  1262: bf 03 00 00 00          mov    $0x3,%edi
  1267: e8 bb ff ff ff          callq  1227 <_Z1Di>
  126c: 8d 3c 03                lea    (%rbx,%rax,1),%edi
  126f: e8 5f ff ff ff          callq  11d3 <_Z1Bi>
  1274: 89 c7                   mov    %eax,%edi
  1276: e8 2e ff ff ff          callq  11a9 <_Z1Ai>
  127b: 5b                      pop    %rbx
  127c: c3                      retq   

R2:
  <exact same as R1>

Java（javap -c MyClass） #

javap -c Appel 
static int R1();
  Code:
     0: iconst_3
     1: invokestatic  #8                  // Method C:(I)I
     4: iconst_3
     5: invokestatic  #9                  // Method D:(I)I
     8: iadd
     9: invokestatic  #10                 // Method B:(I)I
    12: invokestatic  #11                 // Method A:(I)I
    15: ireturn

static int R2();
  Code:
     0: iconst_3
     1: invokestatic  #9                  // Method D:(I)I
     4: istore_0
     5: iconst_3
     6: invokestatic  #8                  // Method C:(I)I
     9: istore_1
    10: iload_1
    11: iload_0
    12: iadd
    13: invokestatic  #10                 // Method B:(I)I
    16: istore_2
    17: iload_2
    18: invokestatic  #11                 // Method A:(I)I
    21: ireturn

解答 #

1. Java字节码为何和源码更贴近？ #

Java编译器（javac）本身做的优化非常有限，它的核心职责是生成符合JVM规范的字节码，尽可能保留源码的结构和语义，把大部分优化工作交给**JVM的即时编译器（JIT）**来完成。而C的g是直接编译成机器码，在编译阶段就会进行大量优化（比如-O1级别），所以会直接把R1和R2的冗余局部变量消除，生成完全一致的机器码。

你看到的Java字节码差异，只是javac忠实还原了源码的执行步骤：R1直接把计算结果留在操作数栈上传递，R2则多了把结果存入局部变量再加载的步骤，但这只是字节码层面的差异，不是最终执行效率的差异。

2. 单行写法是不是始终更高效？ #

不是。JVM在运行时，JIT编译器会进行深度优化，比如逃逸分析、冗余消除、指令重排等。当代码被多次调用触发JIT编译后，R1和R2会被优化成几乎完全一致的机器码，执行效率没有区别。

甚至在某些场景下，使用局部变量的写法反而更利于JIT优化——比如局部变量能帮助编译器更清晰地识别值的生命周期，或者在调试时保留更清晰的执行轨迹。

总结 #

不要被Java字节码的表面差异误导，javac生成的字节码只是中间产物，真正的性能优化在JIT编译阶段。编码时应该优先考虑代码的可读性，而不是纠结字节码的长短。

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