redefineclasses只能修改已有方法体的字节码，不能新增字段、删除方法、修改签名或改变继承关系。
redefineClasses 能改什么，不能改什么
直接说结论：redefineClasses 只能修改已有方法体的字节码（比如修复 if 条件、修正数值计算），不能新增字段、不能删方法、不能改签名、不能动继承关系。JVM 规范硬性限制，违反就抛 UnsupportedOperationException。
常见误操作包括：在热修复时加了个 private String patchNote = "v2"，或把 int calc() 改成 long calc()——这两类都会失败，且不会报编译错误，而是在调用 redefineClasses 时直接拒绝。
真正安全的修改范围只有：
- 方法内部逻辑（变量赋值、条件分支、return 值）
- 字面量常量（如把
"timeout=3000"改成"timeout=5000"） - 对已有字段/方法的调用顺序或参数调整（前提是签名不变）
ClassFileTransformer 拦截时机与类加载器陷阱
ClassFileTransformer 在类被定义（ClassLoader.defineClass）前触发，但**只对后续新加载的类生效**。已加载的类（比如 Spring Boot 启动时初始化的 OrderService）不会自动走这个流程——你得先用 retransformClasses 主动触发重转换。
容易踩的坑是：写了 Transformer 却发现补丁没生效。原因往往是目标类已被 AppClassLoader 加载完毕，而你的 Agent 没调用 instrumentation.retransformClasses(...)。
验证是否命中 Transformer 的最简方式：
- 在
transform方法开头加日志：System.err.println("Transforming: " + className); - 启动时加
-verbose:class，观察类加载顺序 - 确认目标类没被多个 ClassLoader 加载（如 Tomcat 的 WebAppClassLoader 和 SharedClassLoader 冲突）
Arthas retransform 和自研 Agent 的关键差异
Arthas 的 retransform 命令本质是封装了 Instrumentation.retransformClasses，但它做了三件事你手动做容易漏：
- 自动反编译（
jad）→ 保证源码结构和原始字节码兼容 - 校验修改后 class 文件的常量池、行号表等结构完整性（避免
ClassFormatError） - 按类依赖顺序批量重定义（防止 A 依赖 B，但 B 还没重定义导致
NoClassDefFoundError）
自己写 Agent 时，如果跳过编译环节，直接用 ASM 修改原始字节码再传给 redefineClasses，必须确保：
- 调用
ClassWriter(COMPUTE_FRAMES)而非COMPUTE_MAXS（后者不校验栈帧，线上易 crash） - 不改动类的
major/minor version（必须和原 class 一致，否则 JVM 拒绝加载） - 避免在 Transformer 中抛异常（会静默吞掉，类按原样加载）
生产环境热修复必须做的三件事
不是改完代码就能上线。以下动作缺一不可：
- 用
jad --source-only com.example.BugClass > BugClass.java备份原始字节码对应的源结构 - 记录原始类的
md5sum和classLoaderHash（通过sc -d获取），用于故障回滚 - 补丁上线后，立刻用
watch com.example.BugClass buggyMethod returnObj观察实际返回值，确认逻辑已生效
最容易被忽略的是：热修复后的类，其 toString()、equals() 等 inherited 方法若被子类覆盖，可能因字节码变更导致 JIT 编译失效，引发短暂性能抖动——建议补丁上线后盯 5 分钟 GC 日志和 CPU 使用率。
