直接修改字节码测接口调用耗时，本质是可控注入计时逻辑并结合JVM诊断选项（如-Xint、-XX:+PrintInterpreter）精准观测itable分派开销，而非单纯改字节码；需避免JIT干扰、预热类加载，并优先采用JMH或JFR等更可靠方案。
明确观测目标：接口方法调用走的是 itable，不是 vtable
接口方法（invokeinterface）和类方法（invokevirtual）的分派机制不同：
– 类继承体系用 vtable，槽位固定、查找 O(1)；
– 接口实现体系用 itable（interface method table），每个类维护一份接口方法映射表，需先定位接口在 itable 中的起始偏移，再查具体方法槽位，多一层间接寻址。
所以测“接口调用耗时”，实际是在测 JVM 查 itable + 二次跳转的开销，而非单纯方法执行时间。
需要提前准备的底层条件
-
启用 JVM 内置诊断选项：如
-XX:+PrintMethodHandleResolver、-XX:+TraceClassLoading可辅助确认接口方法是否已解析；更关键的是-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter（配合解释执行模式）可观察指令级 dispatch 路径。 -
避免 JIT 干预干扰测量：用
-Xint（纯解释模式）或-XX:TieredStopAtLevel=1禁用 C1/C2 编译，确保每次调用都走完整 itable 查找流程。 -
选择稳定基准对象：确保被测对象已完成类加载、itable 初始化（可通过
Unsafe.defineAnonymousClass或反射触发LinkageError前的预热），避免首次调用混入类加载开销。
字节码层面可做的轻量级注入
不需要重写整个方法体，只需在调用点前后插入计时逻辑（例如使用 ASM 或 Byte Buddy 插入 System.nanoTime()）：
– 在 invokeinterface 指令前 push 当前纳秒时间戳；
– 在其后 pop 时间戳并相减，存入 ThreadLocal 或原子计数器；
– 注意：不要用 System.currentTimeMillis()，精度不够；也不建议在循环内高频打点，避免 GC 噪声掩盖信号。
真正有价值的字节码干预是控制分派路径复杂度：比如人为构造一个实现多个接口（如 A、B、C）的类，并让同一方法名在多个接口中重复声明（如 void run()），迫使 JVM 在 itable 中做线性扫描匹配——这会放大分派耗时，便于观测差异。
比字节码修改更有效的替代方案
多数情况下，直接修改字节码收益有限，推荐组合使用以下方式：
– JMH 微基准测试：写两个对照组，一组调用接口引用（Runnable r = ...; r.run()），一组调用具体类引用（MyTask t = ...; t.run()），固定 warmup/iterations，JMH 自动剔除 JIT 预热、GC 等噪声；
– JVM TI agent 或 JFR 事件采集：开启 jdk.VirtualCallEvent 或自定义 probe，捕获每次 invokeinterface 的入口、itable 查找深度、目标方法地址，导出为结构化数据；
– 对比 -XX:+PrintCompilation 输出：观察接口方法是否被内联（如出现 inline (hot)），若被内联则 itable 分派已被优化掉，此时测到的是零开销——这本身就是结论。
