invokedynamic 指令通过常量池索引定位 bootstrapmethods 表项，由 metafactory 或 altmetafactory 引导方法决定 lambda 实现路径，其参数定义接口契约、目标方法句柄与闭包形式，jvm 动态生成 $$lambda$n/0x... 类并由 jit 编译为机器码。
直接看字节码里的 invokedynamic 指令，就能定位 Lambda 运行期的机器码生成起点——它不产生固定类文件，而是靠 JVM 在首次执行时触发引导方法，动态组装调用逻辑并交由 JIT 编译为本地机器码。
从 invokedynamic 指令定位引导入口
这条指令本身不包含目标方法，只带一个常量池索引，例如：
10: invokedynamic #4, 0 // InvokeDynamic #0:run:()V
这个 #4 指向常量池中 BootstrapMethods 表的第 4 项。真正决定后续路径的是那里声明的引导方法：
- 若显示
invokestatic java/lang/invoke/LambdaMetafactory.metafactory，说明走标准 Lambda 路径 - 若指向
altMetafactory，说明涉及默认方法桥接或更复杂适配（JDK 15+） - 若缺失 BootstrapMethods 或指向非 Lambda 类型引导方法，则不是标准 Lambda 实现
通过引导方法参数看清 JIT 可优化的关键信息
metafactory 接收的三个核心参数，直接对应 JIT 后续编译决策依据：
-
接口类型与抽象方法签名（如
Runnable.run:()V）：定义对外契约，JIT 会据此生成虚表跳转或内联桩 -
实际逻辑的方法句柄（如指向
lambda$main$0()V）：这是真实要编译成机器码的目标，JIT 对它做常规方法内联、逃逸分析 -
捕获变量的封装方式：若方法参数多出
int或MyClass，说明闭包已固化，JIT 可能将整个调用链折叠为单次函数跳转
观察运行期动态类名确认机器码归属实体
执行 lambda.getClass().getName() 返回类似：
com.example.MyClass$$Lambda$1/0x0000000800062040
这个类名不是字符串拼接结果，而是 JVM 动态生成类在方法区的真实标识。它的存在意味着：
- JIT 已将该类的
run()方法（仅一行跳转）和其指向的静态方法lambda$main$0一起编译为本地代码 - 相同结构的 Lambda 可能共享同一份机器码（因底层类复用），不同结构则各自编译
- 若看到
$$Lambda$N/0x...但无对应lambda$xxx$0方法，说明 JIT 已彻底内联，原始字节码被优化掉
用 JVM 参数验证机器码生成行为
启动时加以下参数可交叉印证：
-
-XX:+PrintCompilation：看到类似123 45 n 0 java.lang.invoke.LambdaForm$MH::invoke_MT (11 bytes)，表示 Lambda 相关桩方法已被 JIT 编译 -
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）：直接查看lambda$main$0对应的汇编码 -
-Djdk.internal.lambda.dumpProxyClasses=/tmp：导出动态类字节码，再用javap -c看其run()方法是否只剩一条invokestatic，这正是 JIT 可安全内联的信号
