Java Agent必须通过-javaagent参数加载，MANIFEST.MF需正确配置Premain-Class或Agent-Class；Byte Buddy拦截受限于方法可见性、JDK类权限及匹配精度；耗时监控应使用System.nanoTime()并异步采集；retransform需JVM支持且避开核心类。
Java Agent怎么加载字节码增强逻辑
Java Agent必须通过 -javaagent 启动参数挂载，JVM在类加载前才给它介入机会；不加这个参数，premain 或 agentmain 根本不会执行。
常见错误是写完 MANIFEST.MF 却漏掉启动参数，或者把 agent.jar 放错路径导致找不到。JVM只认绝对路径或相对当前工作目录的路径，不能用 classpath 里的 jar。
-
MANIFEST.MF中必须包含Premain-Class（对应premain）或Agent-Class（对应agentmain），大小写敏感 - 如果同时支持 attach 和启动时加载，两个 Class 都得写，且不能共用同一个类——
premain方法签名是(String, Instrumentation)，agentmain是(String, Instrumentation)，但调用时机和类加载状态不同 - 使用
Instrumentation#addTransformer时，第二个参数canRetransform设为true才能后续调用retransformClasses，否则改了字节码也刷不进已加载类
Byte Buddy插桩时为什么方法没被拦截
不是所有方法都能被 Byte Buddy 拦截：构造器、静态初始化块、private 方法（默认不匹配）、JDK 内部类（如 java.util.ArrayList）默认受 net.bytebuddy.dynamic.loading.ClassInjector.UsingLookup 权限限制，需显式开启 enableBootstrapClassLoaderInjection()。
更常踩的坑是匹配表达式写得太宽或太窄。比如用 named("toString") 只能匹配 public toString，而 ElementMatchers.any() 又会误伤 synthetic 方法（如 lambda 生成的桥接方法），导致运行时报 java.lang.VerifyError。
立即学习“Java免费学习笔记（深入）”；
- 优先用
ElementMatchers.named(...).and(ElementMatchers.isPublic())明确作用域 - 对 JDK 类插桩，必须配合
ByteBuddy().with(AnnotationDescription.Builder.ofType(Inline.class).build())这类策略，或改用MethodDelegation.to(...)而非Advice，避免Unsafe.defineAnonymousClass权限问题 - 调试时加
.disableClassFormatChanges()+.ignore(new ElementMatcher.Junction[]{...})排除无关类，防止干扰
监控方法耗时用 Timer 还是 System.nanoTime()
别用 Timer ——它是调度任务的，不是测时工具；真正该用的是 System.nanoTime()，它不受系统时间调整影响，精度高，开销极低（纳秒级，实际在现代 JVM 上通常 10–20 纳秒一次调用）。
但直接裸写 nanoTime() 容易出错：忘记捕获异常导致监控逻辑崩溃、没处理 long 溢出、或者把耗时统计塞进业务线程阻塞路径里拖慢主流程。
- 耗时采集必须异步化：用
ThreadLocal存起始时间，再由独立线程或 RingBuffer 批量消费，避免 GC 压力和锁竞争 - 不要在
Advice.OnMethodExit里直接打日志——日志 IO 是重操作，应只存结构化数据到内存缓冲区 - 注意
System.nanoTime()返回值是 long，做减法前确认没溢出；实践中建议用Math.subtractExact或封装成带检查的工具方法
生产环境 retransformClasses 失败的典型原因
最常见的失败不是代码写错，而是 JVM 层面的限制：JDK 8 默认关闭 retransformation 支持，必须启动时加 -XX:+UnlockDiagnosticVMOptions -XX:+EnableDynamicAgentLoading；JDK 9+ 虽默认开启，但若用了 --illegal-access=deny，又没在 MANIFEST.MF 里声明 Can-Redefine-Classes: true 和 Can-Retransform-Classes: true，照样失败。
另一个隐蔽问题是类已经进入「不可重定义」状态：比如该类被 JIT 编译过、或已被 Unsafe.defineAnonymousClass 引用过、或其常量池被其他类强引用——此时 retransformClasses 抛 UnsupportedOperationException，但堆栈里不体现具体哪条类出了问题。
- 上线前务必用
Instrumentation.isRedefineClassesSupported()和isRetransformClassesSupported()主动校验 - 批量 retransform 时逐个 try-catch，记录失败类名，而不是全量失败就退出
- 避免对
java.*包下类做 retransform，JVM 可能在任意版本收紧限制，尤其涉及ClassLoader、Thread等核心类
字节码插桩不是“写完就能跑”，每个环节都卡在 JVM 的安全边界上；最麻烦的往往不是怎么插，而是插完之后类还能不能被 JIT、GC 还能不能识别它的对象头、以及监控数据会不会反向拖垮业务吞吐。这些点不提前压测，上线后只能看 GC 日志和 jstack 猜。
