classloader 通过隔离类而非变量实现变量隔离，因类的唯一性由全名与加载器共同决定；不同加载器加载的同名类互不相通，静态变量、类型转换、方法调用均独立。
ClassLoader 实现变量隔离，本质不是隔离“变量”，而是隔离“类”——因为 Java 中一个类的唯一身份由类全名 + 加载它的 ClassLoader 实例共同决定。同一份字节码，被不同 ClassLoader 加载后，在 JVM 中就是两个完全无关的类，它们的静态变量、类型转换、方法调用互不相通。所谓“不同层级的变量隔离”，实际是通过类加载器层次结构与加载策略，间接达成运行时状态的分域管理。
层级隔离：靠双亲委派打破共享前提
Java 默认三层 ClassLoader（Bootstrap → Extension → App）天然形成加载范围隔离：
- Bootstrap 加载
java.lang.String等核心类，其静态变量（如String.CASE_INSENSITIVE_ORDER）对所有应用可见且唯一； - Extension 加载
$JAVA_HOME/lib/ext下的类，其静态变量仅对该层级及子层级（如 AppClassLoader）可见，但 Bootstrap 不会访问它； - AppClassLoader 加载 classpath 类，它的静态变量只在本应用上下文中有效，不会污染 Extension 或 Bootstrap 的命名空间。
关键点在于：双亲委派模型确保了父加载器优先加载，子加载器不重复定义系统类，从而避免了同名类在不同层级被重复加载导致的静态变量覆盖或冲突。
插件/模块隔离：每个插件配独立 ClassLoader
当需要多个插件共存且互不干扰（如 Tomcat 的每个 WebApp、IDE 的每个插件），必须为每个插件创建专属 ClassLoader（如 WebAppClassLoader 或自定义 PluginClassLoader）：
- 每个插件的
WEB-INF/classes和WEB-INF/lib/*.jar由各自 ClassLoader 加载； - 插件 A 中的
com.example.Config和插件 B 中同名类，因加载器不同，JVM 视为两个类，各自持有独立的静态变量； - 即使插件 A 调用插件 B 的某个服务，也必须通过接口+反射+上下文类加载器切换，不能直接强引用对方类。
版本隔离：自定义 ClassLoader + null parent
要同时运行 mysql-connector-java:5.1.49 和 8.0.33，需切断双亲委派链，防止高版本类被低版本 ClassLoader 委托给 AppClassLoader 加载：
- 新建
URLClassLoader(new URL[]{jarUrl}, null)，显式传入null作为 parent； - 重写
loadClass(String, boolean)，跳过super.loadClass()，直接调用findClass()； - 这样该 ClassLoader 加载的所有类（含其依赖的
java.sql.*衍生类）都与系统类加载器完全隔离，各自静态变量互不影响。
线程上下文类加载器（TCCL）：动态绑定执行域
某些框架（如 JNDI、JAXB、SLF4J）在运行时需感知当前业务模块的类路径，这时会使用 Thread.currentThread().getContextClassLoader()：
- Web 容器在分发请求前，会把当前 WebApp 的 ClassLoader 设为 TCCL；
- 框架内部通过 TCCL 加载资源或类，自动落入对应插件的类空间，间接实现“按请求隔离静态配置”；
- 手动设置 TCCL 是跨 ClassLoader 边界安全调用的关键桥梁，但需注意及时恢复，避免泄漏。
