invokestatic指令只认类名，不看对象实际类型：编译时即根据类名和方法签名生成指令并固化符号引用，运行时直接执行，不依赖对象实例、不查虚方法表、无多态性，仅支持隐藏而非重写。
invokestatic 指令只认类名，不看对象实际类型
当你在代码里写 String.valueOf(123) 或 Math.max(1, 2)，javac 会直接生成 invokestatic 指令，并把目标方法的符号引用（比如 java/lang/String.valueOf:(I)Ljava/lang/String;）固化进常量池。运行时 JVM 完全不关心你是不是用 new String("x") 的实例去调，甚至传 null 进去也不会触发空指针——因为根本没取对象引用。
常见错误现象：((List)null).of(1) 能编译通过且运行正常，输出 [1]；但换成非 static 方法如 ((List)null).size() 就会抛 NullPointerException。区别就在这里：of 是 static 方法，绑定靠类名 List，size 是实例方法，绑定靠对象引用，而引用是 null。
使用场景：所有明确知道调用目标、无需多态的场合，比如工具类方法、工厂方法、常量计算。
invokespecial 只允许三种合法调用，不是“普通 super 调用”的万能指令
invokespecial 不是“父类方法调用”的同义词，它只用于三类情况：构造器、private 方法、显式用 super.xxx() 调用父类版本。哪怕子类重写了该方法，只要用了 super.xxx()，字节码就是 invokespecial，强制跳过虚方法表（vtable）查找。
容易踩的坑：
- 反射中对 public 实例方法调用
Method.invoke(obj, args)时，如果该方法被子类重写，JVM 仍走invokevirtual查 vtable，不会变成invokespecial；强行用字节码工具改指令会触发IllegalAccessError - 写
this.xxx()调用本类 private 方法，生成的是invokespecial；但若调用的是本类 public 方法，即使没重写，javac 仍生成invokevirtual（为未来继承留余地） - final 实例方法字节码仍是
invokevirtual，只是 JIT 编译时可能内联——这不是编译期决定的，不能靠反编译看指令判断是否“真正静态绑定”
从 javap 输出一眼识别绑定时机
用 javap -v MyClass.class 看字节码，关键不是记住每条指令含义，而是看“谁在调用、怎么写的”。例如：
class A { static void m() {} }
class B extends A { static void m() {} }
A a = new B();
a.m(); // javap 显示 invokestatic A.m:()V —— 绑定在声明类型 A 上
再比如：
B b = new B(); b.m(); // javap 显示 invokestatic B.m:()V —— 同样是 <code>m()</code>，但指令目标变了
参数差异：static 方法调用指令没有对象引用压栈操作（不需要 aload_0），而 invokespecial 构造器调用前一定有 new + dup + invokespecial <init></init> 三连；super.xxx() 前通常跟着 aload_0（当前 this），但目标方法签名永远指向父类声明。
为什么 final 方法字节码还是 invokevirtual
final 实例方法不能被重写，语义上等价于静态绑定，但 javac 仍生成 invokevirtual，因为 JVM 规范要求：只要不是 static/private/构造器，一律视为虚方法，必须保留运行时查 vtable 的能力。这是为了兼容性——万一未来某个子类加了同签名方法（虽然编译报错，但字节码层面可能绕过），JVM 需要能拒绝非法调用，而不是静默执行错版本。
性能影响：现代 HotSpot 对 final 方法做激进内联，实际运行几乎无开销；但如果你在性能敏感路径反复调用，又不确定是否被 JIT 优化，可考虑改用 static 工具方法（前提是逻辑真不依赖 this 状态）。
真正容易被忽略的是：invokestatic 和 invokespecial 都属于“非虚方法调用”，它们在类加载解析阶段就能完成符号引用到直接引用的转换；而 invokevirtual 必须等到运行时，靠对象的实际 class 找 vtable 再定位——这个延迟虽小，但在高频循环或 GC 敏感场景下，仍可能成为瓶颈线索。
