Java 调 JNI 找不到库主因是路径或加载方式错误：System.load() 需绝对路径且带完整前缀后缀（如 libxxx.so 或 xxx.dll），System.loadLibrary("xxx") 则依赖 java.library.path 搜索匹配命名的库文件，启动需加 -Djava.library.path；函数名须严格按 JNI 规则拼接，参数返回值类型须用 JNI 类型并正确转换；崩溃多因 C 层非法内存访问，应避免缓存局部引用、注意 ABI 兼容性。
怎么让 Java 找到你的 libxxx.so 或 xxx.dll
Java 调 JNI 时找不到库，90% 是路径或加载方式错了。不是代码写得不对，是 JVM 根本没看见那个文件。
关键就两条：要么用 System.load() 给绝对路径；要么用 System.loadLibrary() 配合 java.library.path 让 JVM 自己找。别混着用。
-
System.load("/full/path/to/libhello.so")—— 路径必须完整，Linux/macOS 前缀lib和后缀.so（或.dylib）要写全；Windows 是hello.dll，不能带lib -
System.loadLibrary("hello")—— 这时 JVM 会在java.library.path列出的目录里找libhello.so（Linux）或hello.dll（Windows），名字不加前缀后缀，但必须匹配编译产出 - 启动时加
-Djava.library.path=/path/to/libs最可靠；IDE 里要改 Run Configuration 的 VM options，不是环境变量LD_LIBRARY_PATH（它对 JVM 无效）
为什么 UnsatisfiedLinkError: no xxx in java.library.path
这个错不是说库不存在，是说 JVM 按它当前的搜索规则，没在任何目录里找到符合命名约定的文件。
常见陷阱：你放了个 hello.so，但 loadLibrary("hello") 会去找 libhello.so；或者你在 macOS 编译出 libhello.jnilib，却用 Linux 的命名逻辑去试。
- Linux：必须是
lib{name}.so，比如libnetutils.so→loadLibrary("netutils") - Windows：必须是
{name}.dll，比如netutils.dll→loadLibrary("netutils") - macOS：旧版用
lib{name}.jnilib，新版（JDK 16+）支持lib{name}.dylib，但默认仍优先找.jnilib；建议统一用.dylib并确认 JDK 版本兼容性 - 用
ldd libxxx.so（Linux）或otool -L xxx.dylib（macOS）检查依赖是否齐全，缺 libc 或 OpenSSL 也会报这个错，但提示一模一样
C 函数签名怎么和 native 方法对上
函数名不是随便起的，JNI 有硬编码拼接规则。手写声明不匹配，UnsatisfiedLinkError 就来了，而且不会告诉你哪错了。
假设 Java 类是 com.example.NativeBridge，有个 public static native int doWork(int x);，那 C 端函数名必须是：
Java_com_example_NativeBridge_doWork
下划线转义、包名路径化、大小写敏感——少一个下划线或字母错了，JVM 就认不出来。
- 如果方法在 inner class 里，比如
NativeBridge$Helper，中间的$要写成_00024（JNI 规范定义的转义） - 参数类型要用 JNI 类型：如
jint对应int，jstring不是char*，得用GetStringUTFChars()转换 - 返回值类型也要一致：Java 的
void对应 C 的void，但String得返回jstring，不能直接 return 字符串字面量
为什么本地库一调就崩溃，连异常都不抛
JNI 崩溃通常不走 Java 异常机制，而是直接 SIGSEGV（Linux/macOS）或 ACCESS_VIOLATION（Windows），JVM 进程直接挂。这时候日志里只有“致命错误日志”（hs_err_pid*.log），没有堆栈。
根本原因是 C 层访问了非法内存，比如：jstring 没转就当 char* 用、释放了已经被 GC 回收的局部引用、多线程并发调用未加锁的静态资源。
- 开启 JVM 参数：
-XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -Xlog:gc*,jni=debug（JDK 10+）能暴露更多 JNI 调用上下文 - 用
valgrind --tool=memcheck java ...（Linux）或 AddressSanitizer 编译 C 库，能抓到越界读写 - 避免在 C 层缓存
jobject或jstring：它们只在当前 JNI 调用生命周期有效；要长期持有，必须用NewGlobalRef()，用完记得DeleteGlobalRef()
最麻烦的是跨平台 ABI 差异：比如在 CentOS 编译的 .so 直接扔到 Alpine（musl libc）跑，会静默失败。别图省事 copy 库，目标环境得重新编译。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
