排查类加载期代理死锁需先用jstack定位blocked线程是否等待class初始化锁，而代理线程已持有该锁；典型表现为main线程等待serviceimpl类锁，cglib线程却已锁定它。
排查因不安全动态代理框架在类加载阶段引发的死锁，关键在于识别“类初始化锁”与“代理生成逻辑”的交叉阻塞。这类死锁隐蔽性强——它不发生在业务线程执行期，而卡在 ClassLoader.loadClass 或 Class.forName 触发的静态初始化阶段，且常被误判为“服务启动慢”或“JVM卡住”。
确认是否为类加载期死锁
先排除常规线程死锁，聚焦 JVM 初始化锁（java.lang.Class 对象的 intrinsic lock）的竞争：
- 用
jstack -l <pid></pid>抓取启动卡顿时刻的线程栈，搜索关键词：java.lang.ClassLoader.loadClass、clinit、defineClass、Unsafe.defineAnonymousClass - 重点看 BLOCKED 线程是否在等待某个
Class的初始化锁，而该 Class 的<clinit></clinit>方法又正调用代理工厂（如 CGLIB 的Enhancer.create或 JDK Proxy 的Proxy.getProxyClass） - 典型线索：
"main" ... waiting to lock (a java.lang.Class for com.example.ServiceImpl) ... "CGLIB Enhancer" ... locked—— 表明代理生成线程已持有了目标类的初始化锁，而主线程又在等这个锁完成初始化
定位代理框架介入时机
不安全动态代理常在类首次使用前就触发增强，尤其在以下场景易埋雷：
-
Spring AOP 的 @Aspect 在 @Configuration 类中定义：若切面 Bean 依赖了尚未初始化的被代理类（如
@Bean方法里 new 了一个 Service 实例），Spring 会在代理创建时强制触发该 Service 的类加载和静态初始化 -
CGLIB 的
Enhancer.setSuperclass()调用过早：某些框架（如老版本 MyBatis、自研 ORM）在扫描 Mapper 接口时，未加判断就对所有候选类调用Enhancer.create()，导致其父类（含静态块）被提前加载 -
JDK Proxy 的
getProxyClass(ClassLoader, ...)被传入启动类加载器：当代理接口由 Bootstrap 或 Extension ClassLoader 加载，而实现类由 AppClassLoader 加载时，可能触发跨加载器的锁竞争
验证与复现手段
不依赖生产环境，用最小闭环验证：
- 写一个极简测试类，含静态块 + 依赖另一个带代理逻辑的类，在 main 方法首行调用它，同时用
-XX:+TraceClassLoading启动，观察类加载顺序和阻塞点 - 用 Arthas 的
trace命令监控关键方法：trace java.lang.ClassLoader loadClass、trace net.sf.cglib.proxy.Enhancer create、trace java.lang.Class getDeclaredConstructors（CGLIB 内部会反射获取构造器，可能触发目标类加载） - 添加 JVM 参数
-XX:+UnlockDiagnosticVMOptions -XX:+PrintClassHistogramAfterFullGC，对比卡死前后类加载数量突变，锁定可疑类族
规避与加固建议
核心原则：**切断代理生成与目标类静态初始化的耦合路径**：
- 禁止在
<clinit></clinit>、@PostConstruct、@Bean初始化方法内直接 new 代理对象；改用 Spring 的ObjectProvider<t></t>或延迟初始化代理 Bean - 升级 CGLIB 至 3.3.0+，启用
Enhancer.setUseCache(true)并预热常用代理类，避免运行时高频生成 - 对 Spring AOP，将切面逻辑从
@Configuration类中剥离，改用@EnableAspectJAutoProxy(proxyTargetClass = false)+ 独立@Aspect类，并确保切面不持有被代理类的强引用 - 在类加载器层面隔离：为代理生成逻辑单独创建子 ClassLoader，避免污染主应用类加载链
