osgi中多次加载同一dll抛出unsatisfiedlinkerror的根本原因是模块隔离导致不同bundle的classloader重复加载同一本地库，jvm禁止该行为；应通过专用bundle统一加载、静态标志防护、扩展java.library.path至父加载器或封装为osgi服务来解决。
在 OSGI 环境中，System.load 多次加载同一个 DLL 会抛出 UnsatisfiedLinkError: Native Library xxx.dll is already loaded in another classloader 错误。根本原因是 OSGI 的模块隔离机制导致不同 Bundle 使用各自的 ClassLoader，而 JVM 不允许同一 DLL 被多个 ClassLoader 重复加载。
确保 DLL 只被加载一次
OSGI 中应避免在多个 Bundle 内各自调用 System.load。推荐将本地库加载逻辑集中到一个专用 Bundle（如“native-support-bundle”），该 Bundle 负责初始化并暴露 JNI 接口，其他 Bundle 通过服务或 API 调用，而非自行加载 DLL。
- 在 native Bundle 的
Activator.start()或服务激活时执行System.load(absolutePath) - 使用
System.getProperty("java.library.path")配合System.loadLibrary时需谨慎——它依赖路径查找，易受 ClassLoader 影响；优先用System.load指定绝对路径 - 加载前可用
System.mapLibraryName("xxx")获取平台适配的文件名（如xxx.dll或libxxx.so）
校验 DLL 是否已被加载
JVM 本身不提供公开 API 查询已加载的 native 库，但可通过异常捕获 + 标志位实现简单防护：
- 在 Bundle 激活类中定义静态布尔标志（如
private static volatile boolean loaded = false） - 加同步块判断并加载：
if (!loaded) { synchronized (NativeLoader.class) { if (!loaded) { System.load(...); loaded = true; } } } - 注意：该方式仅对同一 ClassLoader 有效；跨 Bundle 仍需靠架构约束（如前述统一加载 Bundle）
适配 OSGI 的 ClassLoader 行为
OSGI 的 Bundle ClassLoader 是层级结构，若必须由多个 Bundle 触发加载，可尝试将 DLL 路径注册到父 ClassLoader（如 Framework ClassLoader）：
- 在启动参数中添加
-Djava.library.path=/path/to/dlls，让所有 Bundle 共享该路径 - 或在 Framework 启动前，通过
System.setProperty("java.library.path", ...)扩展路径（需在 OSGI 启动前完成） - 再统一使用
System.loadLibrary("xxx")—— JVM 会按扩展后的java.library.path查找，且只加载一次
替代方案：使用 JNI 封装服务
更符合 OSGI 设计原则的做法是封装 JNI 调用为 OSGI 服务：
- Native Bundle 提供
NativeService接口及其实现类，内部完成一次加载和方法代理 - 通过
BundleContext.registerService发布该服务 - 其他 Bundle 通过
BundleContext.getServiceReference获取服务，完全屏蔽 native 加载细节 - 这样既解耦又安全，还能配合服务生命周期管理（如 Bundle 停止时释放资源）
不复杂但容易忽略：关键不在“怎么加载”，而在“谁来加载、何时加载、加载几次”。把 native 依赖当作共享基础设施来设计，而不是每个模块自行处理，问题自然化解。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
