静态变量隔离失效源于类加载时机与加载器归属错配：准备阶段仅赋零值，初始化阶段才执行赋值且仅一次；不同classloader加载同名类可隔离，但双亲委派导致先加载者垄断初始化；验证需检查classloader身份、字段独立性及初始化堆栈；编码须禁用默认urlclassloader、杜绝classloader复用、避免跨加载器传递含静态变量实例，并统一剥离共享依赖。
静态变量在多个自定义 ClassLoader 下看似“各用各的”，实则常因加载时机、委托链或误判共享导致配置数据割裂——比如插件 A 读到的 Config.timeout = 3000，插件 B 却仍是默认值 1000，表面是配置没生效，根源却是两个加载器各自初始化了一次，又各自维护了一份独立副本。
确认是否真为多加载器重复实例化
不能只看类名相同，必须验证运行时隔离性：
- 在目标类（如
AppConfig）的静态块中加诊断日志：
System.err.println("[CONFIG-INIT] loaded by " + AppConfig.class.getClassLoader()); - 启动时加上
-verbose:class，比对日志中[Loaded com.example.AppConfig from ...]的路径与上面打印的加载器是否匹配 - 若同一类名出现两次以上不同加载器（如
PluginClassLoader@123和LaunchedURLClassLoader@456），且都触发了静态块，则确认发生了重复实例化
检查静态字段是否真正独立
打印字段值本身不具说服力，要验证跨加载器访问行为：
- 在插件 A 中执行
AppConfig.setRetryCount(5) - 在插件 B 中调用
AppConfig.getRetryCount()，结果应仍为初始值（如3），而非5 - 若返回
5，说明不是隔离失败，而是加载器复用或 TCCL 未切换——此时两个插件实际共享了同一个 ClassLoader
排查初始化触发点是否被污染
静态变量是否被“你以为的那个加载器”初始化，取决于谁最先访问它：
- 避免在插件代码中直接写
AppConfig.VERSION或new AppConfig()—— 这会使用当前类的加载器，而非插件专属加载器 - 正确做法：显式通过插件加载器触发初始化，例如
Class.forName("com.example.AppConfig", true, pluginLoader)，其中第二个参数true表示强制初始化 - 确保线程上下文类加载器已设为插件加载器：
Thread.currentThread().setContextClassLoader(pluginLoader)，尤其在 Servlet Filter、RPC 回调等跨上下文场景中
修复策略：统一控制初始化入口
不依赖 JVM 的“类只初始化一次”语义，改由应用层保障单次性：
- 在静态块中引入加载器标识守门机制：
private static volatile boolean inited = false;
synchronized (AppConfig.class) {
if (!inited && AppConfig.class.getClassLoader() == expectedLoader) {
doLoadFromYaml();
inited = true;
}
} - 若需全局唯一配置（如所有插件共用一套超时策略），应将配置类移至系统级加载器（如
ApplicationClassLoader）加载，避免放在插件 jar 内 - 禁用插件内
URLClassLoader默认构造方式（无父加载器），始终显式传入父加载器：new URLClassLoader(urls, parentLoader)，防止跳过双亲委派造成类重复定义
