java中接口static方法在字节码中通过invokestatic指令调用，与类静态方法完全一致，属编译期静态绑定，不可重写但可被子接口同名方法隐藏。
最直接、可靠的方式是通过 javap 反编译字节码，观察编译器生成的指令——因为 JVM 本身不“自动调用”valueOf，真正做这件事的是 编译器在编译期插入的静态方法调用，而 JVM 在运行时只是执行这条指令。只要看到 invokestatic java/lang/Integer.valueOf，就等于实锤 JVM 正在执行它。
看字节码：javap 是铁证
写一段最简装箱代码：
public class BoxTest {
public static void main(String[] args) {
Integer a = 42;
}
}
编译后执行：
javac BoxTest.java javap -c BoxTest
关键输出如下：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
0: bipush 42 2: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
这说明：
– bipush 42 把整数 42 压入操作数栈；
– 紧接着 invokestatic 明确调用 Integer.valueOf(int)；
– 编译器没有生成 new Integer(42)，而是强制走工厂方法。
对比 new Integer() 可进一步验证
如果手动写 new Integer(42)：
Integer b = new Integer(42);
反编译后对应字节码是：
0: new #2 // class java/lang/Integer 3: dup 4: iconst_42 5: invokespecial #3 // Method java/lang/Integer."<init>":(I)V</init>
指令完全不同：new + invokespecial（调用构造器），而非 invokestatic valueOf。
二者行为差异（比如缓存复用）也由此而来。
运行时行为佐证：缓存现象就是 valueOf 的副作用
利用 Integer 缓存区间 [-128, 127] 的特性做验证：
-
Integer x = 100; Integer y = 100;→x == y为 true -
Integer m = 200; Integer n = 200;→m == n为 false
这个现象无法用“语法糖”模糊解释，只能由 valueOf 内部的缓存逻辑（查 IntegerCache.cache[]）导致。
JVM 执行时看到的是两个引用指向同一对象（或不同对象），根源正是 valueOf 的返回值策略。
注意一个常见误解
不是“JVM 在运行时动态决定要不要调 valueOf”，而是：
– Java 编译器（javac）在编译阶段就将 Integer a = 42 重写为 Integer.valueOf(42)；
– JVM 只负责执行这条已确定的 invokestatic 指令；
– 所以所谓“JVM 调用”，本质是 JVM 忠实执行了编译器安排好的静态方法调用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
