java类加载器隔离的本质是主动绕过双亲委派机制，通过重写loadclass()方法对特定包名直接调用defineclass()实现；osgi通过符号解析与显式依赖声明强化隔离；spring boot热部署失效常因旧类引用残留；手写classloader需同步处理资源加载、线程上下文和jni库绑定。
Java类加载器隔离的本质是打破双亲委派
类加载器隔离不是靠配置开关实现的，而是主动绕过 ClassLoader.loadClass() 的默认委派链。JVM 默认要求子加载器先委托父加载器尝试加载，一旦父加载器（比如 AppClassLoader）加载过某个类，子加载器就再也无法定义同名类——这是隔离失败的根源。
真正起作用的做法是：自定义 ClassLoader，重写 loadClass(String name, boolean resolve)，对特定包名（如 "com.example.moduleA"）直接调用 defineClass()，跳过 super.loadClass()；其余类再走委派。否则哪怕用了不同加载器，String、ArrayList 这些基础类仍会从 BootstrapClassLoader 加载，导致类型不兼容异常。
- 必须重写
loadClass()，不能只重写findClass() - 避免在
static块或初始化时触发跨模块类引用，否则会提前触发委派 -
defineClass()返回的Class对象与其它加载器加载的同名类不等价，instanceof会失败
OSGi 的 Bundle ClassLoader 是隔离的“标准解”
OSGi 不是魔法，它只是把类加载器隔离封装成可管理的生命周期模型。每个 Bundle 拥有独立的 BundleClassLoader，通过 Import-Package 和 Export-Package 显式声明依赖边界，运行时由框架控制哪些类能被 resolve。
关键点在于：OSGi 在类加载前做了一层符号解析（Symbolic Resolution），而不是等到 Class.forName() 才抛错。这意味着版本冲突、缺失导出包等问题会在启动阶段暴露，而非运行时随机 NoClassDefFoundError。
立即学习“Java免费学习笔记（深入）”；
-
Import-Package: com.example.api;version="[1.0,2.0)"表示只接受该范围内的导出版本 - 两个 Bundle 同时导出
com.example.util，但未声明DynamicImport-Package，彼此不可见 - 使用
BundleContext.getBundle().loadClass()才走本 Bundle 的类加载路径，直接用Class.forName()会走当前线程上下文类加载器（通常是AppClassLoader）
Spring Boot 多模块热部署为何常失效
热部署失败往往不是因为代码没重编译，而是类加载器没被正确替换或旧实例残留。Spring Boot DevTools 默认启用两个类加载器：base 类加载器（加载 spring-boot、tomcat 等不变依赖），restart 类加载器（加载应用代码）。但这个机制只对 classpath:/ 下的类生效，对 META-INF/MANIFEST.MF 或外部 JAR 里的类无效。
更隐蔽的问题是：静态字段、单例 Bean、线程局部变量（ThreadLocal）、JDBC 连接池中的回调对象，都可能持有旧类的引用，导致新类加载后老对象仍在运行，最终出现 IllegalAccessError 或内存泄漏。
- 确保模块 JAR 不放在
lib/目录下，否则会被 base 类加载器加载 - 禁用
spring.devtools.restart.exclude中误排除了的资源路径（如**/config/**） - 在
@PreDestroy或SmartLifecycle.stop()中显式清理ThreadLocal和缓存
自己写 ClassLoader 隔离时最容易漏掉的三件事
手写隔离加载器看似简单，但线上踩坑多集中在资源加载、线程上下文、以及 native 库绑定上。这三块不处理，即使类能加载，运行时也会在奇怪的地方崩。
- 重写
getResourceAsStream(String name)，否则logback.xml、application.properties读不到——默认委派会去父加载器路径找 - 启动线程前必须设置
Thread.currentThread().setContextClassLoader()，否则JDBC DriverManager、JAX-WS等依赖上下文加载器的设施会加载错类 - 若模块含 JNI，
System.loadLibrary()必须在目标类加载器的URLClassLoader路径中存在对应.so/.dll，且不能重复加载同名库（JVM 层面拒绝）
类加载器隔离不是“换个加载器就行”，它把类、资源、线程上下文、本地库、甚至安全管理器策略全绑在一起。少动一环，就可能在用户点击按钮五秒后才报一个 ClassNotFoundException，而堆栈里连你的模块名都没有。
