核心是类加载器可见性问题：守护线程tccl为父加载器，无法解析子加载器加载的注解类；需在子加载器上下文执行注解读取、显式加载注解类或用asm预提取元数据。
这个问题的核心不是“抓不到注解”，而是守护线程的类加载上下文与注解所在类的命名空间不匹配——父加载器启动的线程，其线程上下文类加载器（TCCL）默认是父加载器本身，它天然看不到子加载器加载的类，自然也读不到那些类上的注解。
关键点：注解本身不“属于”类加载器，但读取注解的动作依赖类对象的可见性
Java 中通过反射获取注解（如 clazz.getAnnotation(MyConfig.class)）的前提是：MyConfig.class 必须对当前类加载器可见。如果 MyConfig 是子加载器加载的，而当前线程用的是 AppClassLoader 作为 TCCL，那么即使你拿到了目标类的 Class 对象（比如通过子加载器 loadClass 得到），只要你在父加载器上下文中调用它的 getAnnotation 方法，JVM 仍会尝试用 TCCL 去解析 MyConfig 的类型——此时就失败了。
常见死结场景还原
典型如自研插件框架中：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 主程序用 AppClassLoader 启动一个守护线程监听配置变更；
- 插件模块用 CustomPluginClassLoader 加载了 @EnableFeature 注解和被标注的 Service 类；
- 守护线程试图扫描所有已加载插件类、检查是否含该注解——结果 ClassCastException 或 AnnotationFormatError 频发。
破局方法：绕过 TCCL 依赖，显式指定类加载器解析注解
不能靠“让父加载器认识子类”，而要让注解读取逻辑在正确的命名空间里执行。有三种可靠路径：
- 在子加载器作用域内完成注解扫描：把注解识别逻辑封装成 Runnable/Supplier，用子加载器的 doPrivileged 或直接在其实例上调用，确保 getClass().getClassLoader() 就是它自己；
- 用 ClassLoader.loadClass 显式加载注解类再传入：例如 targetClass.getAnnotation(pluginLoader.loadClass("com.example.EnableFeature"))，避免 JVM 自动用 TCCL 解析；
- 改用字节码分析（ASM）提前提取注解信息：在 defineClass 阶段或类加载后立即用 ClassReader 扫描 Annotation 属性，把结果缓存为字符串或简单结构，后续守护线程只读缓存，完全脱离反射和类加载器绑定。
必须避开的坑
以下做法看似省事，实则埋雷：
- 把子加载器设为线程的 TCCL —— 守护线程可能长期存活，TCCL 被污染后会影响后续其他模块的类加载；
- 在父加载器中 try-catch ClassNotFoundException 然后 fallback 到子加载器 —— 违反双亲委派语义，且无法解决 getAnnotation 内部的隐式加载；
- 用 Unsafe.defineAnonymousClass 动态生成代理类读注解 —— 属于高危操作，现代 JDK 已限制，且沙箱环境通常禁用。
本质不是技术卡点，而是加载边界意识问题：谁加载的类，就该由谁或其下游来解释它的元数据。守住这条线，死结自然松开。
