如何在构建阶段检测类中Java方法引用（双冒号）的使用并校验注解合规性

认知澄清 #

之前感知到的「ASM不支持识别双冒号方法引用」属于使用方式误区：
Java 8引入的双冒号方法引用语法，编译后本质是携带特定引导方法的invokedynamic字节码指令，ASM从Java 8版本开始就完整支持这类指令的解析，只是多数写ASM的场景下，大家只关注常规的INVOKEVIRTUAL/INVOKESTATIC等普通方法调用指令，没专门处理invokedynamic携带的元数据，才会出现识别不到方法引用的问题。IntelliJ IDEA的Ctrl+点击跳转目标方法能力，也是靠解析这类字节码层的方法引用元数据实现的，不存在特殊的不可复现的黑盒能力。

具体实现步骤 #

1. 基于ASM实现精准方法引用识别 #

• 方法引用的字节码存储规则：所有::形式的方法引用，最终都会被编译为调用java/lang/invoke/LambdaMetafactory生成函数式接口实例的invokedynamic指令，指令的引导方法参数中，会直接存储目标方法的归属类、方法名、方法签名等完整元数据，对应ASM API中的Handle类型对象
• 自定义ASM访问逻辑：
  • 重写MethodVisitor#visitInvokeDynamicInsn方法，捕获所有方法引用/简单Lambda生成的invokedynamic调用
  • 定位构造Info类的标准字节码序列（对应NEW Info、栈上压入参数、INVOKESPECIAL Info.<init>的固定流程），筛选出传入Info构造器的函数式参数，提取其对应的目标方法Handle
  • 根据Handle中存储的类名、方法名、签名信息，定位对应类的目标方法，扫描方法上是否存在@Good注解，缺失注解时直接抛出构建错误
• 全场景覆盖：不管是静态方法引用X::beta、实例方法引用x::beta、类的构造方法引用X::new，都会在Handle对象中携带完整的方法定位信息，不需要额外区分方法引用的语法类型，所有实例/静态方法引用场景都能精准识别。

2. 覆盖简单委托类Lambda的检测 #

• 语法上不符合团队规范的new Info(x -> x.alpha())这类直接委托式Lambda，编译后同样走LambdaMetafactory生成实例的流程，目标方法的元数据存储结构和纯方法引用完全一致，直接复用上述ASM解析逻辑即可识别，不需要额外做源码层的语法树解析
• 带多行逻辑、分支判断的复杂Lambda属于本来就会被代码评审拦截的场景，且编译后会被映射到编译器生成的合成方法，不是直接指向用户编写的原方法，不需要纳入自动检测范围。

3. 构建阶段集成 #

• 把字节码扫描逻辑绑定到构建流程的编译后环节，比如Maven的process-classes阶段、Gradle的afterJavaCompile任务节点，在测试执行、打包完成前完成全量类的扫描
• 校验规则做范围限定：只对传入Info类构造器的函数式参数做注解校验，不要全量扫描项目里所有的方法引用，避免规则误伤正常业务代码
• 输出明确的错误提示，直接定位到违规代码对应的类、方法、位置，比如类X的init方法中传入Info构造器的X::alpha未标注@Good注解，不符合团队编码规范

方案价值 #

对比之前采用动态代理的运行时校验逻辑，这套静态扫描方案的核心优势：

• 问题前置：在编码后的构建环节就能拦截违规代码，不需要等到运行时触发对应业务逻辑才暴露问题
• 无侵入：完全基于编译后的字节码做扫描，不修改原有业务代码的运行逻辑，没有动态代理带来的类加载开销
• 识别精度和IDE对齐：直接读取和IntelliJ同源的字节码层方法引用元数据，不会出现识别偏差、漏判的问题

内容的提问来源于stack exchange，提问作者bodrin