Java中 ASM 字节码框架怎么识别并正确生成 ACC_BRIDGE 与 ACC

桥接方法是编译器为解决泛型擦除导致的多态失效而自动生成的合成方法，标记为acc_bridge和acc_synthetic，方法体仅含类型转换与转发逻辑，需通过method.isbridge()或字节码flags识别。

java中 asm 字节码框架怎么识别并正确生成 acc_bridge 与 acc_synthetic 标记

ASM 识别和生成 ACC_BRIDGE 与 ACC_SYNTHETIC 标记，核心在于理解它们的语义、触发场景和 ASM 的 API 使用逻辑——不是手动“打标记”，而是通过正确构造方法结构，让 ASM 自动推导或显式设置标志。

在 ASM 中，读取类时无法直接靠方法名或签名判断是否为桥接方法；必须依赖字节码层面的标志位：

使用 MethodVisitor.visitAnnotation("Ljava/lang/Synthetic;", true) 可检测 @Synthetic 注解（但非所有桥接方法都带该注解）
更可靠的方式是：在 ClassReader 解析时启用 ClassReader.EXPAND_FRAMES，然后在 MethodVisitor.visitAttribute(Attribute attr) 中检查 attr 是否为 CodeAttribute 或自定义属性，并结合 MethodVisitor.visitCode() 后观察指令模式
但最直接的做法是：用 ASM 的 MethodNode（继承自 MethodVisitor）读取完整方法后，调用其 access 字段判断：(methodNode.access & Opcodes.ACC_BRIDGE) != 0 且 (methodNode.access & Opcodes.ACC_SYNTHETIC) != 0

ASM 不会自动为你添加 ACC_BRIDGE 或 ACC_SYNTHETIC —— 即使你复制了一个泛型重写方法的逻辑，若不设标志，JVM 就不认它是桥接方法：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

创建 MethodVisitor 时，visitMethod(int access, String name, String descriptor, String signature, String[] exceptions) 的 access 参数需包含 Opcodes.ACC_BRIDGE | Opcodes.ACC_SYNTHETIC
例如生成一个返回 Object、转发给真实 String get(int) 的桥接方法：
mv = cw.visitMethod(Opcodes.ACC_PUBLIC | Opcodes.ACC_BRIDGE | Opcodes.ACC_SYNTHETIC,
"get", "(I)Ljava/lang/Object;", null, null);
方法体中只需两步：aload_0 + iload_1 + invokevirtual 调用真实方法 + areturn（无需手动类型转换，JVM 在调用时自动处理）

很多开发者以为“只要签名不同就自动是桥接方法”，其实不然：

仅设置 ACC_SYNTHETIC 而不设 ACC_BRIDGE → JVM 不视为桥接方法，多态分派失败
设了标志但方法体没做正确转发（比如漏掉参数加载或返回指令）→ 运行时报 VerifyError
在 visitMethod 中传入了泛型 signature（如 "(I)Ljava/lang/String;"），但 descriptor 写成 "(I)Ljava/lang/Object;" → 签名与 descriptor 不匹配，验证失败
忘记清除局部变量表或跳过 visitLocalVariable → 桥接方法应无 LocalVariableTable，否则可能被某些工具误判为人工编写

生成完 class 字节码后，务必用标准工具确认：

用 javap -v YourClass.class 查看目标方法，确认 flags 行同时含 ACC_BRIDGE 和 ACC_SYNTHETIC
检查 descriptor 是否宽于实际方法（如父类期望 Object，子类实现 String）
确认 Code 区只有极简指令：加载 this 和参数、一次 invokevirtual、一次 areturn（无多余逻辑）
检查 LineNumberTable 是否缺失或全为 0 —— 正常桥接方法不应有源码行号