java中static变量被类加载器隔离的本质是“多份独立副本”，因类唯一性由全限定名+加载器实例共同决定，同名类在不同加载器下视为不同类，各自拥有独立方法区和static变量空间。
Java 中静态变量在类加载器隔离下不是“重复加载”，而是形成多个完全独立的副本——每个类加载器加载同名类时，都会创建一份专属的 static 变量空间，彼此互不可见、互不干扰。
为什么 static 变量会被隔离
静态变量属于类，而类在 JVM 中的唯一性由“全限定类名 + 类加载器实例”共同决定。哪怕两个加载器加载的是同一份字节码，只要加载器不同，JVM 就视其为两个不同的类，各自拥有独立的方法区空间和静态变量存储区。
- 启动类加载器（Bootstrap）加载的
java.lang.String和应用类加载器（AppClassLoader）加载的自定义String（如果能绕过保护）是两个类，static 字段不共享 - 插件 A 的
PluginClassLoader@123加载Config.class，插件 B 的PluginClassLoader@456也加载它 → 产生两份Config.timeout，值可完全不同 - Web 应用中，每个 WAR 包通常有自己的
WebAppClassLoader，即使类名、包名、代码一致，static 变量也不跨 WAR 共享
如何确认是否真发生了隔离
不能只看类名或代码逻辑，必须验证运行时行为：
- 在目标类静态块中加诊断输出：
System.err.println("[INIT] " + YourClass.class.getClassLoader()); - 启动时加
-verbose:class，比对日志中[Loaded com.example.Config from ...]的路径与上述打印的加载器是否匹配 - 跨模块修改并读取：模块 A 执行
Config.setPort(9001)，模块 B 调用Config.getPort()—— 若仍返回默认值，说明隔离生效；若返回 9001，则大概率是加载器复用或 TCCL 未切换
哪些写法容易破坏隔离预期
看似合理，实则隐含风险：
- 在 Servlet Filter 中直接访问
Config.VERSION，但没提前设置Thread.currentThread().setContextClassLoader(pluginLoader)→ 实际走的是 WebAppClassLoader - 自定义类加载器重写了
loadClass却没调用super.loadClass，导致核心类（如javax.servlet.http.HttpServletRequest）被重复加载 - 用
Class.forName("com.example.Config", false, cl)—— 第二个参数为false不触发初始化，后续首次访问时可能由意外的加载器触发 - 把含 static 缓存的工具类实例（如
new CacheManager()）从插件 A 传给插件 B 使用 → 表面隔离，实际共享了底层 static 状态
需要共享时该怎么办
static 变量天生不适合跨加载器共享。真有全局状态需求，应主动脱离类加载器层级：
- 用 JVM 进程级资源：如
java.util.concurrent.ConcurrentHashMap配合类名作 key，但需确保所有模块都访问同一个实例（例如通过 ServiceLoader 或单例 Holder） - 外移至外部存储：配置中心（Nacos/Apollo）、数据库、Redis，各加载器下的类统一读写同一外部源
- 用上下文类加载器（TCCL）作为协调枢纽：统一由
Thread.currentThread().getContextClassLoader()加载并管理共享类，要求所有模块严格遵循该约定 - 对只读元数据，优先用
public static final String VERSION = "2.3"—— 编译期内联，天然隔离且无加载时机争议
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
