模块化环境下JNI加载native库的核心难点是JPMS切断classpath与java.library.path隐式可见性，导致System.loadLibrary()无法定位库文件；须将库打包进JAR的META-INF/native/目录、用System.load()显式加载完整路径，或改用JNR-FFI等兼容JPMS方案。
模块化环境下（如 Java 9+ 的 JPMS）通过 JNI 加载 native 库的路径难点，核心在于 模块封装切断了传统 classpath 和 java.library.path 的隐式可见性，导致 System.loadLibrary() 无法自动定位库文件，即使路径设置正确也常报 UnsatisfiedLinkError。
明确 native 库归属模块
JPMS 要求 native 库必须与使用它的 Java 模块显式关联。不能仅靠 -Djava.library.path 把库“扔”进系统路径就完事。
- 推荐做法：将 native 库打包进模块对应的 JAR 中（例如放在
META-INF/native/linux-x86_64/下），并在module-info.java中声明本机资源依赖（虽 JPMS 不直接支持 native 声明，但这是构建工具识别的关键信号）； - 避免把 native 库放在
lib/目录下再靠外部路径加载——模块系统默认不扫描该路径，java.library.path对模块内代码无效； - 若用
opens或exports开放包给其他模块，也要确认 native 方法所在的类是否在被导出的包中，否则调用方模块无法访问 native 方法声明。
改用 System.load() 显式加载完整路径
在模块化项目中，System.loadLibrary() 的自动查找机制基本失效。更可靠的方式是跳过名称映射，直接加载已知位置的库文件：
- 先获取库文件的绝对路径（例如从 JAR 内提取到临时目录，或从模块资源流复制）；
- 调用
System.load("/full/path/to/libmylib.so")（Linux）或System.load("C:\path\to\mylib.dll")（Windows）； - 注意：路径必须是完整、可读、且无权限限制的；JVM 不会校验扩展名，但文件本身必须是合法的共享库。
确保运行时能解析库的依赖链
模块化不改变底层动态链接行为。若你的 native 库（如 librocksdbjni.so）依赖 libzstd.so 或 liblz4.so，仅设置 java.library.path 不够。
- Linux 上需同步配置
LD_LIBRARY_PATH，让系统链接器能找到这些间接依赖； - 可提前用
ldd libmylib.so检查缺失项； - 容器或受限环境建议将所有依赖库统一放入同一目录，并在启动脚本中一并加入
LD_LIBRARY_PATH和java.library.path。
优先考虑 JNR-FFI 等替代方案
对新项目，尤其是模块化设计明确的场景，可绕过 JNI 路径难题：
- JNR-FFI 不依赖
System.loadLibrary()，而是通过LibraryLoader自动探测平台和架构，从 classpath 或指定路径加载； - 它天然兼容 JPMS：只要 native 库在模块路径上（如作为自动模块或已声明为
requires），就能加载； - 无需手写
.h文件或管理符号命名，类型转换、内存生命周期均由框架处理。
