osgi模块隔离由类加载器行为与manifest.mf元数据共同决定：每个bundle拥有独立classloader，不遵循双亲委派，按“本地导出→导入依赖→系统包”顺序加载类；jvm以“类名+classloader”判定类型同一性，确保多版本共存与热插拔。
OSGi 中的模块隔离不是靠配置或开关实现的，而是由类加载器行为与元数据声明共同决定的。每个 Bundle 拥有专属 ClassLoader，它不走传统双亲委派，而是按明确顺序查找类，并严格依据 MANIFEST.MF 中的声明控制可见性。
每个 Bundle 配备独立 ClassLoader
OSGi 把应用拆成多个 Bundle，每个 Bundle 对应一个 BundleClassLoader 实例。这个加载器和其它 Bundle 的加载器之间没有父子关系，彼此隔离。JVM 判定两个类是否相同，依据是“类名 + 加载它的 ClassLoader 实例”。因此，即使 Bundle A 和 Bundle B 都包含 org.slf4j.Logger，只要它们由不同加载器加载，JVM 就认为这是两个完全无关的类——类型不兼容、不能赋值、instanceof 失败。
类查找走“本地→依赖→系统”三步策略
BundleClassLoader 加载类时不向上委托，而是按固定优先级执行：
- 先查本 Bundle 的 Export-Package 列表：只加载自己明确导出的包里的类（如 com.example.api）
- 再查 Import-Package 声明：若类属于已导入的包（如 org.json;version="[2.0,3.0)"），则定位到实际导出该版本的 Bundle，交由其加载器加载
- 最后才对 java.* 等核心包委派给 Bootstrap 加载器；其余未声明依赖的类直接抛 NoClassDefFoundError
MANIFEST.MF 是隔离的契约文件
隔离效果不是运行时猜测出来的，而是由清单文件静态定义的：
- Export-Package：声明本 Bundle 向外提供哪些包，可带精确版本号（如 com.example.service;version="1.2.0"）
- Import-Package：声明需要哪些外部包及允许的版本范围（如 com.example.service;version="[1.0,2.0)"）
- 未出现在 Export-Package 中的类，哪怕物理存在，也无法被其他 Bundle 访问
- 框架在启动阶段就做依赖解析（Resolution），不满足版本约束的 Bundle 不会被激活
隔离支撑热插拔与多版本共存
因为类加载器与 Bundle 生命周期绑定，卸载 Bundle 时会销毁其 ClassLoader，连带回收所有由它加载的 Class 对象和实例：
- Bundle A 导入 slf4j 1.7，Bundle B 导入 slf4j 2.0 → 它们看到的是不同 Bundle 提供的同名包，互不影响
- 若某 Bundle 缓存了另一个 Bundle 的服务实例（如静态字段持有），卸载时该引用会阻止类回收，造成泄漏
- 模块间通信必须通过接口解耦：接口定义在独立 API Bundle 中，双方都 Import-Package；实现方注册服务，消费方动态获取，避免硬编码 new 或静态调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
