从AdoptOpenJDK Alpine迁至Temurin Alpine触发UnsatisfiedLinkError

这个问题的核心原因有两点：

1. 你之前用的AdoptOpenJDK Alpine镜像默认内置了glibc兼容层，不是纯musl libc环境；而官方Eclipse Temurin Alpine镜像是纯musl libc构建的，没有带额外的glibc兼容逻辑。
2. 两个C库的动态链接器行为存在本质区别：
   • glibc的动态链接器没有严格遵循POSIX标准，所有已经加载到进程内存的共享库，不管加载时有没有指定全局可见标志，都会被放进全局依赖查找范围。哪怕你是通过绝对路径调用System.load()（底层对应dlopen系统调用）加载的自定义so，后续加载其他依赖它的so时，不需要再去磁盘路径搜索，直接就能从内存里找到已经加载好的库实例。
   • musl的动态链接器是严格按POSIX规范实现的：只有加载时指定了RTLD_GLOBAL标志的共享库，才会进入全局符号、依赖查找表。而JVM调用System.load()的时候，底层dlopen默认传的是RTLD_LAZY | RTLD_LOCAL标志，用这个方式加载的自定义so不会被musl识别为全局可用库。后续加载其他so的时候，动态链接器只会去默认系统库路径、LD_LIBRARY_PATH指定的路径、so自身编译时写入的RPATH路径里搜磁盘上的依赖文件，根本不会检查内存里已经加载过的so，所以哪怕你前一行刚加载过依赖的库，照样会报找不到文件的错误。

你贴的报错信息刚好能对应这个逻辑：加载second.so时，动态链接器检查到已经加载的first.so依赖second.so，但按照musl的查找规则找不到磁盘上的second.so，就直接抛出了UnsatisfiedLinkError。

问题复现代码如下：

System.load("/path/first.so");
System.load("/path/second.so"); // UnsatisifiedLinkError: /path/first.so: Error loading shared library second.so: No such file or directory (needed by /path/first.so)

按改造成本从低到高排序：

• 调整库加载顺序：梳理清楚所有自定义so的依赖关系，先加载被其他库依赖的基础库，最后加载依赖其他库的上层库。比如如果first.so依赖second.so，就把System.load("/path/second.so")放在前面，再加载first.so，避免依赖查找时找不到对应库。
• 配置库搜索路径：把所有自定义共享库所在的目录加到LD_LIBRARY_PATH环境变量里，比如so都放在/path/目录下，JVM启动前执行export LD_LIBRARY_PATH=/path:$LD_LIBRARY_PATH，让musl动态链接器可以直接在对应路径下搜到依赖的so文件，不需要改代码或者编译参数，是成本最低的适配方案。
• 编译时指定RPATH：如果自定义so是你自己编译的，可以在链接so的时候加参数-Wl,-rpath,<库存放的绝对路径>，把依赖搜索路径直接写进so文件的ELF头里，动态链接器加载so的时候会优先搜这个路径下的依赖文件，不依赖环境变量配置。
• 安装glibc兼容层：如果不想改现有代码和配置，可以在Temurin Alpine镜像里装glibc兼容包，还原和旧AdoptOpenJDK镜像一致的glibc环境，但是这种方式会增大镜像体积，还可能出现musl/glibc混用的兼容问题，非必要不推荐。

注意：这个问题不是JVM的bug，不需要靠调整JVM启动参数解决，本质是不同C库实现的动态链接规则差异导致的。

内容的提问来源于stack exchange，提问作者MiketheCalamity