OSGi通过独立BundleClassLoader和显式Import/Export契约实现类隔离，类唯一性由加载器实例+全限定名决定，支持多版本共存与服务动态注册。
OSGi 实现模块间类隔离，核心是用独立的类加载器 + 显式依赖契约，把每个 Bundle（模块）真正隔开。不是靠“不让加载”，而是让 JVM 从根源上认为：不同 Bundle 加载的同名类，就是两个完全不同的类型。
每个 Bundle 拥有专属的 BundleClassLoader
OSGi 不复用传统的双亲委派链，而是为每个已解析（Resolved）的 Bundle 分配一个独立的类加载器实例。这个加载器只负责本 Bundle 的 Bundle-ClassPath（如 classes/ 和 lib/ 下的 jar），不自动向上委托。哪怕两个 Bundle 都含 org.slf4j.Logger，只要来自不同 Bundle，JVM 就视其为两个类——这是隔离的底层基础。
- 类的唯一标识 = 类加载器实例 + 全限定类名，不是仅看类名
- 卸载 Bundle 时，该加载器被丢弃，其所加载的类可被 GC 回收
- 不会出现“AppClassLoader 已加载过 A 版本，导致 B Bundle 无法加载同名类”的问题
依赖必须显式声明：Import-Package 与 Export-Package
类能不能跨模块使用，不由路径或 classpath 决定，而由 MANIFEST.MF 中的元数据控制。一个 Bundle 若想用 com.example.service.UserService，必须写：
Import-Package: com.example.service;version="[1.0,2.0)"
而提供该接口的 Bundle，则需明确导出：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
Export-Package: com.example.service;version="1.5.0"
- 未在 Import 列表里的包，即使物理存在也无法访问（编译期和运行期均受限）
- 版本范围匹配失败（如请求 [1.0,2.0)，但只有 2.1.0 可用），Bundle 状态卡在 Resolved，无法启动
- 支持多版本共存：Bundle X 导出 service v1.3，Bundle Y 导出 v1.8，其他 Bundle 可按需各自导入对应版本
类查找走“注册表驱动”的网状路径，而非父子委托
当 Bundle A 加载 com.example.service.UserService 时，它的类加载器执行三步查找：
- 先查自身 Bundle-ClassPath 是否含该类
- 若无，查 Import-Package 声明，定位到导出该包的 Bundle B
- 再调用 Bundle B 的类加载器去加载（协作关系，非继承关系）
整个过程依赖 OSGi 框架维护的内部包注册表（Package Registry），而不是递归调用 parent.loadClass()。多个 Bundle 同时导出同一包时，框架按版本、符号名等规则选一个主提供者，其余被忽略——避免歧义。
服务注册机制进一步解耦实现与引用
接口与实现分离，靠 服务注册中心 绑定：
- Bundle A 实现
UserServiceImpl，通过BundleContext.registerService()发布为UserService接口的服务 - Bundle B 通过
BundleContext.getServiceReference(UserService.class)动态获取，不直接 new 或 import 实现类 - 服务可按属性筛选（如
osgi.remote.configuration.type=rest），支持运行时替换实现
这样连“导入实现类”这一步都省了，彻底规避类可见性冲突。
