OSGi热插拔通过BundleClassLoader隔离、声明式依赖（Import/Export-Package）、状态驱动类加载（RESOLVED→ACTIVE→UNINSTALLED）及服务注册中心解耦协作实现，而非字节码替换或类重载。
OSGi 的热插拔能力不是靠“替换字节码”或“重载类”实现的，而是通过一套严格隔离、按需协作的类加载体系，让模块（Bundle）能独立安装、启动、停止、更新和卸载，且不破坏运行中其他模块的稳定性。
每个 Bundle 拥有独立的 ClassLoader
OSGi 容器（如 Equinox、Felix）不会用单个 ClassLoader 加载所有类。相反，每个 Bundle 在安装时都会被分配一个专属的 BundleClassLoader（通常是 BundleWiring.getClassLoader() 返回的对象）。这个类加载器：
- 只可见自己 Bundle 内的类（
Bundle-ClassPath中声明的 JAR/目录） - 不继承自父 ClassLoader（打破双亲委派的默认链），但会按 OSGi 规范显式委托：先查导入包（Import-Package）、再查所需服务、最后才尝试本地加载
- 导出（Export-Package）的类对其他 Bundle 可见，但仅当对方明确声明导入且版本匹配时才可解析成功
类可见性由元数据驱动，而非路径或顺序
Java 默认类加载依赖 classpath 顺序和双亲委派，容易冲突；OSGi 则把依赖关系写进 META-INF/MANIFEST.MF：
-
Import-Package：声明“我要用哪些外部 API”，例如
Import-Package: org.slf4j; version="[1.7,2.0)"—— 运行时由框架匹配已导出该包且版本兼容的 Bundle -
Export-Package：声明“我提供哪些能力”，可带版本、私有包标记（
x-internal:=true） - DynamicImport-Package（慎用）：支持运行时按需加载未预声明的包，用于反射场景，但破坏模块确定性
这种声明式依赖让类解析在模块启动阶段就完成验证，避免运行时 NoClassDefFoundError，也为热替换提供安全边界。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
模块生命周期与类加载状态强绑定
OSGi Bundle 有明确定义的状态（INSTALLED → RESOLVED → STARTING → ACTIVE → STOPPING → UNINSTALLED），而类加载行为严格跟随状态变化：
- 处于 RESOLVED 状态时，Bundle 的类尚未加载，但其导入/导出关系已被解析，依赖满足性已校验
- 调用
start()进入 ACTIVE 后，BundleClassLoader 才真正激活，首次访问类时触发加载（懒加载） - 调用
stop()进入 STOPPING 时，框架会释放该 Bundle 的 ClassLoader 实例（前提是无活跃引用），其加载的所有类可被 GC 回收 -
update()本质是“卸载旧 Bundle + 安装新 Bundle”，新 Bundle 使用全新 ClassLoader，旧类彻底失效，无静态字段残留风险
服务注册中心解耦运行时协作
模块间不直接 new 对象或静态调用，而是通过 OSGi Service Registry 发布/获取服务接口：
- 服务发布者（Bundle A）调用
bundleContext.registerService(MyService.class, impl, props)，注册的是接口类型 + 实例，不暴露实现类名 - 服务使用者（Bundle B）通过
bundleContext.getServiceReference(MyService.class)获取服务，拿到的是代理或直连实例，与 A 的类加载器无关 - 当 A 被 stop 或 update，其服务自动注销，B 收到
ServiceEvent.UNREGISTERING，可及时切换备用实现或降级
这种基于接口契约的松耦合，配合服务事件监听，使得功能模块即使完全替换实现类，只要接口不变，上层逻辑无需重启即可继续运行。
OSGi 的热插拔不是魔法，它是靠类加载器隔离、声明式依赖、状态驱动生命周期和服务化交互四者协同达成的——类不共享，依赖可验，加载可控，协作抽象。一旦违反这些约束（比如在 Bundle 中使用 Class.forName("xxx") 加载未导入的类，或缓存跨 Bundle 的类对象），热插拔就会失效甚至引发类加载死锁。
