静态变量隔离失效源于类加载时机与加载器归属错配：准备阶段仅赋零值，初始化阶段才执行赋值且仅一次；不同ClassLoader加载同名类可隔离，但双亲委派导致先加载者垄断初始化；验证需检查ClassLoader身份、字段独立性及初始化堆栈；编码须禁用默认URLClassLoader、杜绝ClassLoader复用、避免跨加载器传递含静态变量实例，并统一剥离共享依赖。
静态变量在多类加载器环境下看似“被隔离”，实则极易因加载顺序、委托链、实例复用等细节失效。排查难点不在代码写法本身，而在于理解 JVM 类加载各阶段中静态变量真正被初始化的时机与归属。
准备阶段赋默认值 ≠ 初始化阶段赋业务值
Java 类加载的“准备”阶段只为静态变量分配内存并设零值（如 int count = 0），但真正执行 count = 10 或静态代码块，发生在“初始化”阶段——且该阶段仅触发一次，由首次主动使用该类时的线程触发。
这意味着：
- 若模块 A 和模块 B 的同名类由不同 ClassLoader 加载，各自会独立走一遍初始化流程，静态变量互不影响；
- 但若某类被 AppClassLoader 先加载（例如因双亲委派未被绕过），后续插件加载器再尝试加载同名类，根本不会进入初始化阶段——因为类已存在，只是“不可见”；
- 此时你以为插件用了自己的静态变量，实际读到的是系统加载器版本的值，且可能已被其他模块改写过。
初始化时机受调用链严格控制
静态变量是否隔离，不取决于你“new 了多少个 ClassLoader”，而取决于谁、在什么上下文中、第一次访问了哪个类。
常见陷阱：
- 通过反射调用 Class.forName("com.example.Config", true, loader)：第二个参数 true 表示触发初始化，必须确保 loader 是目标插件专属加载器；
- 直接 new 实例或访问静态字段（如 Config.VERSION）：JVM 自动触发该类初始化，但使用的 ClassLoader 是发起调用方所在类的加载器，不是你期望的那个；
- 线程上下文类加载器（TCCL）未正确设置：比如在 Servlet 容器中，Filter 调用插件服务前未执行 Thread.currentThread().setContextClassLoader(pluginLoader)，则插件内部对静态变量的访问仍走 WebAppClassLoader。
验证隔离是否生效的三步实操检查
不能只看 clazzA != clazzB，要确认运行时行为真正分域：
- 查 Class 对象身份：打印 clazzA.getClassLoader() == clazzB.getClassLoader()，应为 false；再打印 clazzA == clazzB，也必须为 false；
- 测静态字段独立性：在模块 A 中执行 Config.counter++，随后在模块 B 中读取 Config.counter，结果应仍是初始值（如 0），而非 1；
- 抓初始化堆栈：在 Config 类静态代码块中加 System.out.println("init by: " + ClassLoader.getSystemClassLoader())，观察输出的加载器是否为你创建的那个实例——这是最直接的证据。
避免“伪隔离”的关键编码习惯
很多问题源于开发时无意识破坏了隔离前提：
- 不用 new URLClassLoader(urls) 默认构造——它父加载器是 AppClassLoader，90% 场景需显式传 null 或自定义 parent；
- 每个插件/脚本/租户必须持有唯一 ClassLoader 实例，禁止全局 static 缓存或池化复用；
- 禁止跨加载器传递含静态变量的类实例（如 UserContext），哪怕只是日志打印其 toString()，也可能触发意外类加载；
- 依赖类（如 slf4j-api、json-lib）若被多个插件各自打包进 JAR，必须统一剥离，由宿主提供——否则它们的静态状态（如 LoggerFactory 内部注册表）会在各加载器中重复初始化，引发冲突。
