retransformClasses是重转换已加载类的字节码而非重载类，不改变Class对象身份，仅覆盖运行时行为；需目标类已加载、非final、未禁用Attach机制，且不能修改方法签名或结构，Spring Boot 4.0通过InstrumentationBridge默认支持该能力。
retransformClasses 不是“重载类”，而是“重转换字节码”
很多人误以为 retransformClasses 和类加载器热替换（如自定义 ClassLoader）是一回事，其实完全相反：它不创建新类、不触发类卸载、也不改变 Class 对象身份（== 仍为 true），只是让 JVM 用新字节码“覆盖”当前已加载类的运行时行为。关键前提是目标类必须已通过标准类加载器加载完成，且未被 final 修饰或处于不可重转换状态（如某些 JVM 内部类、启动类）。Spring Boot 4.0 的 InstrumentationBridge 默认启用该能力，但需确认 JVM 启动时未加 -XX:+DisableAttachMechanism 或禁用 java.lang.instrument。
必须绕开的三个 runtime 陷阱
即使字节码合法，retransformClasses 仍可能静默失败或行为异常：
- 不能修改方法签名：增减参数、改返回类型、抛出新 checked exception 都会直接抛
UnsupportedOperationException - 不能新增/删除字段或方法：JVM 不允许在运行时变更类结构，哪怕只是加个
private int debugFlag - Spring 代理类（如
$ProxyXX、CGLIB$$）默认不可重转换——必须对原始目标类（如OrderService）操作，而非其代理实例
验证是否生效最简单的方式是：调用 instrumentation.isModifiableClass(targetClass)，返回 false 就别往下试了。
Arthas 中 retransform 的实操链路
生产环境推荐用 Arthas 而非手写 Instrumentation 代码，因为它自动处理了 classpath 查找、字节码校验、冲突检测和回滚保护：
- 先用
sc -d com.example.service.PaymentService确认类已加载且路径正确 - 编译修复后的 Java 文件，生成单个
.class（确保与原类同包同名，且未带调试信息冗余） - 执行
retransform /path/to/PaymentService.class；若提示 “conflict with other agent”，加--force - 立刻用
watch com.example.service.PaymentService calculateFee '{params, returnObj}' -n 1观察逻辑是否已变
注意：retransform 是叠加式修改，多次执行会基于上一次结果再改；而 redefine 是覆盖式，旧字节码彻底丢失——线上修复只用 retransform。
Spring Boot 4.0 下的自动协同增强点
如果你用的是 Spring Boot 4.0 + spring-boot-starter-agent，无需手动注册 ClassFileTransformer。框架会在 ApplicationContext refresh 前触发 AgentRegistrationSPI，自动将你声明的 @EnhanceAt 方法或 META-INF/spring/agents.yml 中配置的类纳入可重转换白名单。此时真正要做的只有两件事：
- 确保修复类的编译版本（
javac -source 17 -target 17）与运行时 JDK 严格一致，否则retransform会因常量池不匹配失败 - 避免在
static {}块或构造器中做不可逆初始化（如注册单例监听器），因为重转换后这些代码不会再次执行
最易被忽略的一点：JVM TI 模式下（JDK 21+ 启用 -XX:+EnableJVMCI），retransformClasses 的延迟可压到 15ms 内，但若应用启用了 GraalVM Native Image，则整个机制不可用——热修复前务必确认运行时模式。
