不能靠 invokedynamic 直接实现非侵入式 AOP 动态代理，因其仅解决调用目标定位，不提供方法拦截钩子；真正需结合字节码增强织入 + 自定义 BSM 绑定 MethodHandle 实现低开销 AOP。
不能靠 invokedynamic 直接实现“非侵入式 AOP 动态代理”——它本身不生成代理类，也不拦截方法调用；但它是构建低开销、无类膨胀 AOP 机制的关键基础设施。真正起作用的是：用 invokedynamic 替代反射调用 + 自定义引导方法绑定 MethodHandle + 配合运行时字节码增强（如 Byte Buddy）做切面织入。
为什么不能直接用 invokedynamic 做 AOP 代理
invokedynamic 指令本身不修改目标方法字节码，也不提供方法入口/出口钩子。它只解决“调用目标在哪”这个问题，而不是“调用前/后要做什么”。AOP 需要的是对原方法执行流的拦截与增强，这必须发生在目标方法被调用的前后位置，而 JVM 原生不支持这种钩子。
常见误解是：既然 Lambda 用 invokedynamic 实现，那我也能用它“动态替换方法调用”，从而绕过代理类。但实际中：
-
invokedynamic的引导方法（BSM）只在首次调用时执行一次，后续完全跳过逻辑判断，无法插入切面代码； - 它返回的
CallSite绑定的是一个固定MethodHandle，不能在每次调用时动态决定是否执行前置/后置逻辑； - 若强行在 BSM 中做切面逻辑，会导致所有使用该
invokedynamic的调用点共享同一份增强行为，丧失按方法、按注解、按条件定制的能力。
invokedynamic 如何真正降低 AOP 的类生成开销
传统基于 java.lang.reflect.Proxy 或 CGLIB 的代理，每次创建代理实例都可能触发新类生成（尤其是 CGLIB 子类），导致元空间压力大、类加载慢、热更困难。而 invokedynamic 可以把“调用转发”这个动作本身做得极轻量，前提是：把切面逻辑下沉到字节码增强层，让 invokedynamic 只负责最终执行。
典型协作路径是：
- 用 Byte Buddy 或 ASM 在类加载时（或 redefine 时）修改目标方法字节码，在关键位置插入
invokedynamic指令； - 该指令指向一个自定义引导方法，该方法根据当前对象、方法签名等上下文，动态查找并绑定一个已预热好的
MethodHandle（比如封装了日志、权限校验逻辑的静态方法）； - 后续调用不再走反射或虚方法分派，而是直通
MethodHandle.invokeExact()，性能接近 invokevirtual； - 所有切面逻辑复用已有类中的静态方法，无需为每个代理对象生成新类。
例如：Spring AOP 5.3+ 已在部分场景尝试将 ReflectiveMethodInvocation 中的反射调用路径替换为 MethodHandle + invokedynamic 缓存，实测在高频调用下减少 15%~20% 的调用开销，且完全避免新增代理类。
自定义引导方法（BSM）的关键约束
你写的 BSM 不是随便一个 static 方法就能当引导方法——JVM 对签名、权限、返回值有硬性要求：
- 必须是
static方法，且参数顺序固定为：MethodHandles.Lookup lookup, String name, MethodType type； - 返回值必须是
CallSite子类（常用ConstantCallSite或MutableCallSite）； - 方法必须声明在启动类路径（boot classpath）或由
BootstrapMethod注册的类中，否则lookup.findStatic()会抛IllegalAccessException； - BSM 内部若需访问目标类私有成员，必须通过
lookup调用findSpecial/findVirtual，不能直接 new 或反射； - 不要在 BSM 中做耗时操作（如 IO、锁竞争），它只执行一次，但会阻塞首次调用线程。
一个最小可用 BSM 示例：
public static CallSite bootstrap(MethodHandles.Lookup lookup,
String name,
MethodType type) throws Throwable {
// 假设切面逻辑已封装在 MyAspect.logAndInvoke()
MethodHandle target = lookup.findStatic(
MyAspect.class, "logAndInvoke",
MethodType.methodType(Object.class, Object.class, Object[].class)
);
return new ConstantCallSite(target);
}
invokedynamic 不解决但必须配合的问题
即使用了 invokedynamic，AOP 的核心难题仍需其他机制兜底：
- 切点表达式（如
@annotation(Trace)）解析仍需 AspectJ 或 Spring AOP 的匹配引擎，invokedynamic不参与这部分； - 环绕通知（
ProceedingJoinPoint）需要保存原方法调用上下文，这依赖字节码增强时插入的局部变量或栈帧操作，不是invokedynamic能提供的； - 如果要支持运行时启用/禁用切面，得用
MutableCallSite并配合 volatile 字段控制setTarget()，但频繁切换会破坏 JIT 优化，慎用； - 调试体验变差：IDE 无法跳转到被
invokedynamic调用的真实切面方法，堆栈里只显示MethodHandle.linkToStatic。
真正落地时，invokedynamic 是“最后一公里”的加速器，不是整套 AOP 的替代方案。最容易被忽略的一点是：它要求你放弃“运行时动态注册任意方法为切面”的灵活性，转而接受“编译/加载期静态绑定 + 运行期高速复用”的范式——这对工程可维护性提出了更高要求。
