bootstrapmethods属性是class文件中专为invokedynamic指令服务的静态引导清单，首次执行时由jvm读取并调用其中方法（如lambdametafactory.metafactory）生成callsite；它包含引导方法引用及参数列表，参数中第0项为函数式接口签名、第1项为编译器生成的桥接方法（如lambda$main$0），其static性取决于是否捕获外部变量，且整个机制绕过类加载、动态生成实现类。
怎么看 BootstrapMethods 属性里的引导方法
BootstrapMethods 是 class 文件里的一个固定属性，它不参与运行，只在 invokedynamic 指令首次执行时被 JVM 读取并调用。它本质是一张“启动清单”，告诉 JVM：当遇到这个动态调用点时，该找哪个静态方法来生成真正的调用目标。
用 javap -v 查看编译后的 class 文件，搜索 BootstrapMethods: 就能看到类似这样的内容：
BootstrapMethods:
0: #23 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:
(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#24 ()V
#25 invokestatic LambdaDemo.lambda$main$0:()Ljava/lang/String;
#24 ()V
关键不是记住所有字段含义，而是盯住三样东西：
-
invokestatic后面的类和方法名——这里是LambdaMetafactory.metafactory，它是 JDK 提供的标准引导方法 -
Method arguments列表里的第 1 项（索引 0）是函数式接口抽象方法的签名（如#24 ()V），它定义了“对外承诺的契约” - 第 2 项（索引 1）是编译器生成的桥接方法引用，比如
lambda$main$0，这才是真正干活的逻辑所在
为什么 metafactory 要传三个 MethodType 参数
LambdaMetafactory.metafactory 的签名里有三个 MethodType 类型参数，它们分别对应：
- 第一个
MethodType（#24）：函数式接口抽象方法的类型，即调用方“期望怎么调用” - 第二个
MethodType（#24再次出现）：桥接方法（如lambda$main$0）的签名，即“实际怎么实现” - 第三个
MethodType（常与第二个相同）：用于校验桥接方法是否满足接口契约；若不一致，JVM 在首次链接时就抛LambdaConversionException
这三者必须能对齐，否则哪怕代码编译通过，运行到 invokedynamic 第一次执行时也会失败。常见翻车点是桥接方法访问了非 final 的局部变量，导致编译器生成的是实例方法而非静态方法，签名对不上。
Bridge method 不一定是 static，得看捕获了什么
编译器生成的桥接方法（如 lambda$main$0）是否为 static，取决于 Lambda 是否捕获了外部变量：
- 没捕获任何变量（包括
this、局部变量、实例字段）→ 编译为private static方法 - 捕获了
this或实例字段 → 编译为普通实例方法（private，无static） - 捕获了非
final或“事实 final”不成立的局部变量 → 编译失败，报错local variables referenced from a lambda expression must be final or effectively final
这个细节直接影响 MethodHandle 的创建方式：对静态桥接方法，metafactory 用 findStatic 获取句柄；对实例方法，则需先绑定 this，再用 findVirtual，整个 CallSite 构建过程更重。
首次调用后 CallSite 就固化了，但可被重新链接
invokedynamic 的核心优势是“懒链接”——只有第一次执行才触发 BootstrapMethods 中的方法，生成 CallSite 并绑定真实目标。之后所有调用都走已链接的路径，开销接近直接调用。
但要注意：CallSite 不是完全不可变的。如果使用了 MutableCallSite（Lambda 默认不用），或触发了 JVM 的去优化（如类重定义、JIT 撤销），链接可能被打破并重新走引导流程。不过对标准 Lambda 场景，你基本只会看到一次引导 + 永久缓存。
真正容易被忽略的是：这个机制完全绕过了传统类加载流程。Lambda 实现类由 ASM 动态生成、直接 define 到内存，不会落盘、不可反射获取类名（名字形如 com.example.LambdaDemo$$Lambda$1/0x0000000800061840），调试时看不到源码跳转，堆栈里也只显示桥接方法名。
