unsatisfiedlinkerror若由abi不匹配导致，典型表现为跨系统（如ubuntu 22.04→centos 7.9/alpine）运行时直接报libstdc++.so.6或libz.so.1缺失，且ldd显示依赖符号版本不满足；alpine必须装gcompat，否则glibc编译的so必挂；jdk 17+应使用-xlog:library=info确认jvm是否真实加载so。
OpenJDK应用启动时报UnsatisfiedLinkError怎么快速定位是镜像ABI不匹配？
不是代码写错了，也不是System.loadLibrary()路径不对——而是你用的OpenJDK镜像和宿主系统glibc/musl版本不兼容，导致JNI库根本加载失败。典型现象是：同一份libxxx.so在Ubuntu 22.04上正常，在CentOS 7.9或Alpine 3.19上直接抛java.lang.UnsatisfiedLinkError: no xxx in java.library.path，甚至error while loading shared libraries: libstdc++.so.6: cannot open shared object file这种底层报错。
验证方法很简单，不进Java层，直查系统级依赖：
- 用
ldd your-native-lib.so检查该so依赖哪些系统库（重点关注libstdc++.so.6、libz.so.1、libc.so） - 对比宿主系统实际提供的版本：
find /usr/lib* -name 'libstdc++.so*' 2>/dev/null，再用strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX看符号版本是否覆盖so所需最低版本 - 若用Alpine，必须确认是否装了
gcompat：没它，glibc编译的so在musl上必挂，apk add gcompat不是可选，是刚需
如何用-Xlog:library确认JNI库是否真的被JVM加载？
JDK 17+已移除ClassLoader.loadedLibraryNames等反射访问方式，传统排查手段失效。真正能信的，是JVM原生日志。
加参数启动即可看到真实加载行为：
java -Xlog:library=info -jar app.jar
关键输出含义：
-
Loaded library libxxx.so, handle 0x...→ 成功加载，但不保证JNI_OnLoad执行成功 -
Failed to find _JNI_OnLoad_xxx→ so文件存在，但入口函数缺失或符号名不匹配（常见于C++编译未加extern "C"） - 完全没日志 → JVM压根没找到该so，说明
java.library.path配置错误，或so权限/架构不匹配（如x86_64 so跑在aarch64容器里）
Docker镜像中JNI库兼容性三步自查清单
别只盯着Java版本，JNI是跨语言、跨ABI的链路，每个环节都可能断：
- 基础镜像用
alpine还是ubuntu？Alpine必须配gcompat，否则任何glibc-linked的JNI库都会SIGSEGV（exit code 139） - 本地库编译时用的GCC版本和目标镜像的
libstdc++版本是否对齐？例如在Ubuntu 22.04（glibc 2.35）上编译的so，在CentOS 7（glibc 2.17）上运行会因符号缺失失败 - 容器内是否缺失
libz.so.1、libpng16.so.16等间接依赖？用ldd -r your-lib.so看所有未解析符号，再逐个apk search或apt list确认安装
国产OS（UOS/麒麟/openEuler）上JNI模块签名与jmod冲突怎么办？
OpenJDK 25+在麒麟V10、UOS V20等系统上默认启用更严格的模块签名验证，而很多JNI库（尤其自研或老版本第三方）没带jmod签名，会导致ModuleFormatError或JNI_OnLoad静默跳过。
临时绕过方案（仅限调试）：
- 启动时加
--add-opens java.base/java.lang=ALL-UNNAMED放开反射限制（部分JNI初始化依赖） - 禁用jmod签名验签：
--illegal-access=permit -Djdk.module.sealed=false（注意：生产环境慎用） - 更稳妥的做法是用
jlink构建定制运行时镜像时，显式排除有冲突的模块，并用--bind-services确保JNI所需服务提供者被正确绑定
真正要稳，得让JNI库本身支持模块化打包并签名——但这往往意味着重编译、重发布，不是改几个JVM参数能解决的。
