静态方法调用直接使用invokestatic指令编译为一条call指令，目标地址编译期确定，无需加载this、不查vtable；实例方法调用通过invokevirtual生成间接call，需先读对象头、查klass和vtable，依赖运行时数据，分支预测难度大、延迟更高。
直接看汇编指令，能更真实地反映 static 方法和实例方法在 CPU 层面的调用差异——不是靠“理论上快”，而是看它到底少做了什么。
静态方法调用：一条 call 指令直达目标地址
静态方法没有 this 参数，JVM 编译后生成的字节码通常是 invokestatic，JIT 编译为汇编时，通常对应一条直接的 call 指令（如 x86-64 下 call 0x00007f...），目标地址在编译期或类加载期就可确定。
这意味着：
- 不需要从寄存器或栈中读取对象引用（比如
rdi或rax中的this） - 不涉及虚函数表（vtable）查表跳转
- 无动态分派开销，CPU 可以高效预测分支、预取指令
例如，调用 Math.abs(-5) 编译后的关键汇编片段可能类似：
mov eax, -5 call Math::abs ; 直接跳转，地址固定，无间接寻址
实例方法调用：多一步对象基址解引用 + 可能的 vtable 查找
实例方法默认是虚方法（Java 中除 private/final/static 外），字节码为 invokevirtual。JIT 编译后，典型汇编流程包含：
- 先加载对象引用（如
mov rax, [rbp-8]—— 从局部变量取this） - 再通过该引用读取对象头中的 klass 指针（
mov rdx, [rax]） - 然后查 klass 的 vtable（如
mov rdx, [rdx+0x10]获取方法入口偏移） - 最后
call [rdx+0x200]—— 间接调用，依赖内存读取结果
即使 JIT 做了内联或单实现优化（monomorphic call），底层仍需验证接收者类型；而未优化时，这条路径存在至少 2–3 次内存访问，且 call 是间接跳转，影响分支预测器准确率。
关键区别不在“有没有对象”，而在“寻址是否依赖运行时数据”
-
static方法：目标地址静态可知 → 直接 call → CPU 流水线友好 - 实例方法（尤其未内联时）：目标地址藏在对象内存里 → load + offset + indirect call → 更多指令、更多 cache 访问、更高延迟
注：现代 JVM（如 HotSpot）对热点实例方法会做去虚拟化（devirtualization）甚至内联，此时汇编可能和 static 方法几乎一样。但这种优化有前提——方法被频繁调用、类型稳定、无重写。一旦条件不满足（如接口多实现、反射调用），就必须走完整虚调用链。
如何实际观察？
用 -XX:+PrintAssembly（配合 hsdis）或 JMH + perf asm 可捕获真实汇编。重点关注：
- 是否出现
callq *0x...(%rip)（间接调用，大概率是 invokevirtual） - 是否出现
callq 0x...（直接调用，常见于 invokestatic 或已内联方法） -
this引用是否在调用前被显式加载（如mov %rdi,%r10），这暴露了参数传递开销
不复杂但容易忽略：性能差距的本质，是静态方法把“去哪里执行”这件事提前到编译/加载阶段决定，而实例方法把部分决策推迟到运行时——CPU 不喜欢猜，越早确定，越快执行。
