不能直接用 system.nanotime() 监控 invokedynamic 的动态生成过程，因其链接发生在字节码解析阶段、仅首次触发且不可被 java 层拦截；可观测手段限于 jvm ti、instrumentation 增强或诊断标志，但需警惕测量失真。
不能直接用 System.nanoTime() 监控 invokedynamic 指令本身的“动态生成”过程。
invokedynamic 的动态生成发生在字节码解析阶段，不是方法执行期行为
invokedynamic 指令本身不执行目标方法；它只在首次执行时触发“链接”（linking）：调用用户指定的引导方法（Bootstrap Method），由该方法返回一个 CallSite 实例，并绑定具体目标方法句柄。这个链接过程是 JVM 内部的一次性元操作，发生在方法第一次被调用时（可能在解释执行阶段，也可能在 JIT 编译前），不对应 Java 层可拦截的“方法体执行”。
因此，你在业务方法里插 nanoTime()，测到的是目标方法逻辑的耗时，而非 invokedynamic 链接开销。
若想观测 invokedynamic 的链接耗时，需从 JVM 底层介入
可行路径有且仅限以下几种：
- 启用 JVM 内置诊断标志：
-XX:+TraceClassLoading+-XX:+PrintAssembly（配合 hsdis）观察字节码解析与链接日志，但无纳秒级时间戳 - 使用 JVM TI（JVM Tool Interface）编写 native agent，在
JVMTI_EVENT_DYNAMIC_CODE_GENERATED或JVMTI_EVENT_COMPILED_METHOD_LOAD回调中打点——这能捕获 Lambda 生成的内部类字节码或InnerClassLambdaMetafactory的代码生成事件 - 通过
java.lang.instrument.Instrumentation注入对java.lang.invoke.LambdaMetafactory或InnerClassLambdaMetafactory关键静态方法（如metafactory）的字节码增强，在其入口/出口插入nanoTime()——这是最贴近“监控动态生成”的 Java 层手段
注意 nanoTime 在此场景下的典型干扰
即使成功插桩，也要警惕三类失真：
- 首次调用时的链接耗时包含类加载、常量池解析、方法句柄创建等，后续调用几乎为零开销，单次测量无统计意义
- JIT 编译器可能将引导方法内联或优化掉部分逻辑，导致多次运行耗时剧烈波动
- 如果插桩位置太深（如进入
MethodHandleImpl$IntrinsicMethodHandle），会显著拖慢链接过程，反而放大测量值，形成严重观察者效应
更实用的替代思路：监控 Lambda 实际调用性能
真正影响业务的是 Lambda 表达式**执行时**的表现，而非生成瞬间。建议聚焦于：
- 对 Lambda 对应的函数式接口方法（如
Consumer.accept()、Function.apply()）做字节码增强，测量其每次调用耗时 - 结合
StackWalker或Throwable.getStackTrace()提取调用栈，识别哪些 Lambda 来自哪个源码位置，实现按上下文归因 - 用
MethodHandles.lookup().findStatic()等反射方式预热 Lambda，规避首次调用抖动，再测稳态性能
