invokedynamic指令不处理“Lambda变量”，而是动态生成并绑定Lambda表达式对应的函数式接口实例；javac将其编译为私有静态方法，运行时通过LambdaMetafactory引导生成实现类并缓存调用点。
invokedynamic 指令本身不处理“Lambda 变量”，Java 中也没有“Lambda 变量”这一语法概念。它真正支撑的是 Lambda 表达式——即形如 x -> x + 1 或 System.out::println 这类可传递、可赋值给函数式接口的匿名函数对象。它的核心作用，是让 JVM 在运行时按需生成并绑定这些函数逻辑，而不是在编译期就固化为一堆匿名类。
invokedynamic 如何把 Lambda 表达式变成可执行对象
你写下的 Lambda 并不会直接编译成一个独立的 .class 文件。javac 做的是三件事：
- 把 Lambda 主体（比如
s -> s.length()）编译成一个私有静态方法（如lambda$main$0(String)），放在当前类里； - 在调用位置（比如赋值语句或方法参数处）插入一条
invokedynamic指令，并在常量池中关联引导方法（LambdaMetafactory.metafactory）和必要参数（目标接口、方法签名、静态方法的方法句柄等）； - 运行时首次执行该指令时，JVM 调用引导方法，动态生成一个实现了对应函数式接口（如
Function<string integer></string>）的类，并创建其实例，再把这个实例绑定到调用点（CallSite）上。
为什么不用匿名内部类，而要引入 invokedynamic
匿名内部类的问题是“太早、太重、太死板”：
- 编译期就必须生成完整类文件（如
Outer$1.class），哪怕这个类只用一次； - 每个不同逻辑的 Lambda 都对应一个新类，容易引发类加载压力和元空间膨胀；
- 无法复用：两个结构完全一样的 Lambda（如都写
() -> 42）仍会生成两个类实例； - JVM 对其优化有限，比如难以内联、逃逸分析受限。
invokedynamic 把整个过程延迟到首次运行时，且支持缓存与复用。相同签名和逻辑的 Lambda 实例可能共享同一个生成类，JVM 还能对稳定调用点做多态内联缓存（PIC），让后续调用接近直接调用性能。
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
调用点（CallSite）和方法句柄（MethodHandle）的关键角色
invokedynamic 不是直接跳转，而是通过中间层完成解耦：
- 引导方法只执行一次，负责“组装”出一个 CallSite；
- CallSite 是一个可变容器，持有当前有效的 MethodHandle；
-
MethodHandle 是轻量级函数指针，指向那个编译生成的静态方法，并确保它能适配函数式接口的抽象方法签名（例如把
int applyAsInt(int)转成Integer apply(Integer)的桥接）。
后续每次调用，JVM 直接通过 CallSite 获取 MethodHandle 执行，绕过引导开销，也避免反射的慢与不安全。
它不解决变量捕获，但影响捕获方式的实现效率
Lambda 中引用外部变量（如局部变量、this、成员字段）属于“变量捕获”，这部分由 javac 在编译期处理：
- 引用 final 或事实 final 的局部变量 → 编译器将其值复制进生成的静态方法参数；
- 引用 this 或实例成员 → 方法变成实例方法，隐式传入 this；
- invokedynamic 本身不参与捕获逻辑，但它让这种捕获结果能以更轻量的方式封装（无需额外类加载），并允许 JVM 对捕获后的调用链做深度优化。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
