通过汇编指令观察 CPU 底层行为，能清晰揭示 static 方法与实例方法在调用效率上的本质差异。直接看 CPU 到底做了什么，远比停留在“理论上更快”更有说服力。
先说核心结论：静态方法调用时，CPU 的执行路径更短、更直接；而实例方法调用则涉及至少两到三次额外的内存读取，并伴随一次间接跳转。这种性能差距在多线程高频调用的场景下会显著放大，成为性能瓶颈的源头。
静态方法调用：一条 call 指令直达目标地址
静态方法没有 this 隐式参数，编译成字节码是 invokestatic，经过 JIT 编译为汇编后，通常就是一条直接的 call 指令——目标地址在编译期或类加载阶段就已经确定。这意味着 CPU 无需从寄存器或栈中读取对象引用，无需查询虚函数表（vtable），也不必执行动态分派。
简单来说，调用 Math.abs(-5) 时，编译后看到的汇编大概率是这样的：
mov eax, -5call Math::abs ; 直接跳转，地址固定，无间接寻址
这一条直接 call 没有任何间接依赖，CPU 的流水线可以顺利预取后续指令，分支预测器也能轻松命中。好比乘客前往一个固定地址，司机无需中途问路，直接送达即可。
实例方法调用：多一步对象基址解引用 + 可能的 vtable 查找
实例方法的调用路径就复杂多了。它默认是虚方法（Java 中除 private、final、static 外均为虚方法），字节码指令为 invokevirtual。JIT 编译后的汇编流程通常包含以下关键步骤：
- 第一步，从局部变量区加载
this引用（例如mov rax, [rbp-8]） - 第二步，通过对象引用读取对象内存头部的 klass 指针（
mov rdx, [rax]） - 第三步，在 klass 的虚函数表（vtable）中查询方法入口地址（如
mov rdx, [rdx+0x10]） - 第四步，执行间接调用（
call [rdx+0x200]）
每一步都依赖内存访问，而且最后一步是间接跳转——分支预测器往往难以准确预测，因为调用目标地址在运行时才能确定。即使 JIT 做了去虚拟化（devirtualization）或内联优化，底层仍需验证接收者类型。在未经优化的场景下，这条路径比静态方法多出至少 2 到 3 次内存读取，而且间接寻址的 call 指令会严重干扰 CPU 的指令预取与分支预测效率。
关键区别不在“有没有对象”，而在“寻址是否依赖运行时数据”
静态方法的入口地址在编译期就已固定，CPU 能直接跳转，指令预取顺畅无阻。而实例方法的地址则深藏在对象的内存结构中：CPU 需要先读取对象头，再计算偏移量，最后间接跳转——每一步都可能打断流水线的连续执行。换句话说，核心差异在于方法地址的确定时机：静态方法在编译或加载阶段就已锁定目标，实例方法则将决策推迟到运行时。
值得留意的是，现代 JVM（如 HotSpot）对热点实例方法确实会实施去虚拟化甚至内联优化，此时生成的汇编代码可能与静态方法几乎无异。但这种优化有严格前提：方法调用的频率需足够高、接收者类型稳定、且没有子类重写。一旦条件不满足（例如接口多实现、反射调用），就必须走完整的虚调用链，性能差距就会重新暴露出来。
如何实际观察？
想实际验证这些差异？方法很简单：用 -XX:+PrintAssembly 配合 hsdis 插件，或借助 JMH 结合 perf asm 就能抓取真实的汇编指令。关键要看以下几个特征：
- 是否出现
callq *0x...(%rip)（间接调用，大概率对应invokevirtual） - 是否出现
callq 0x...（直接调用，常见于invokestatic或已内联的方法） this引用是否在调用前被显式加载（如mov %rdi,%r10），这暴露了参数传递的额外开销
原理并不复杂但容易被忽略：静态方法把“去哪儿执行”这件事提前到了编译或加载阶段，而实例方法把部分决策留到了运行时。CPU 天生不喜欢不确定性——决策越早确定，执行效率越高。
