osgi实现热插拔的核心在于独立bundleclassloader与显式版本化依赖契约：每个bundle拥有隔离类加载器，打破双亲委派，按manifest.mf声明的import/export版本范围精确解析依赖，卸载时销毁加载器以回收类和实例，从而支持模块级动态启停与多版本共存。
OSGi 实现热插拔架构的核心，不在于“替换代码”，而在于用独立的类加载器 + 显式依赖契约，把模块真正隔开。每个 Bundle 拥有自己的 BundleClassLoader，它不走双亲委派的老路，而是按需、可控、可销毁地加载类——这才是版本隔离和热部署能落地的根本。
Bundle 类加载器打破双亲委派
标准 Java 的类加载靠“先问爹，再问爷”，最终落到 Bootstrap 加载器。OSGi 反其道而行之：每个 Bundle 的类加载器优先查自己、再查显式导入的包、最后才考虑父加载器（且仅限系统类如 java.*）。这种“先本地，后依赖，慎委托”策略，让两个 Bundle 即使都用 log4j 1.2 和 2.17，也能互不干扰。
- Bundle A 导入
org.slf4j;version="[1.7,2.0)"→ 只能拿到提供该范围版本的 Bundle 所导出的类 - Bundle B 导入
org.slf4j;version="[2.0,3.0)"→ 它看到的是另一个 Bundle 提供的 slf4j，与 A 完全无关 - 两者加载的
org.slf4j.Logger是两个不同的Class对象，内存地址不同，类型不兼容
版本共存靠 MANIFEST.MF 精确控制
OSGi 不靠文件名或路径区分版本，而是靠元数据驱动。每个 Bundle 在 MANIFEST.MF 中声明自己的身份、依赖和能力：
-
Bundle-SymbolicName: com.example.report—— 模块唯一标识 -
Bundle-Version: 2.1.0—— 版本号参与解析与匹配 -
Import-Package: com.example.data;version="[1.0,2.0)"—— 声明需要哪个范围的接口 -
Export-Package: com.example.report.api;version="2.1.0"—— 明确对外暴露什么，带版本
框架在启动时做依赖解析（Resolution），只把满足版本约束的 Exporter 绑定给 Importer。一个包多个版本可同时存在，只要没 Bundle 同时导入冲突范围，就不会出错。
热插拔依赖于类加载器的生命周期解耦
传统应用里，类一旦被加载就很难卸载——因为 Class 对象被静态引用、线程持有、JVM 缓存。OSGi 把这个过程交还给 Bundle 生命周期：
- 当 Bundle 进入 UNINSTALLED 状态，它的
BundleClassLoader被显式丢弃 - 该加载器加载的所有类不再可达，对应的
Class对象可被 GC 回收 - 所有由该 Bundle 创建的实例（如服务对象）若无外部强引用，也会一并释放
- 新版本 Bundle 安装后，用新加载器重新加载类，从头开始初始化，干净利落
隔离不是默认结果，而是设计选择
OSGi 的隔离不是“自动生效”的魔法，它依赖开发者主动约定：
- 不导出内部实现包（如
com.example.report.internal），只导出稳定 API - 导入包时写清版本范围，避免用
*或宽松范围导致意外绑定 - 服务通信走
ServiceRegistry，而非直接 new 其他 Bundle 的类——绕过类加载耦合 - 资源访问也通过 BundleContext 获取，不依赖 classpath 相对路径
