SpringBoot2应用在Docker中异常停止(Exited 139)并提示libawt.so错误，该如何解决？

springboot2 应用部署至 docker 容器后异常停止的排查

本文针对 SpringBoot2 应用在 Docker 容器中运行时出现异常停止的问题进行分析和解答。该问题主要体现在容器日志中显示 Exited (139) 状态码，并伴随 libawt.so 相关的错误信息。

问题描述中，开发人员使用 Docker 19.03.13 版本，Docker Compose 部署两个相同的 SpringBoot 应用实例（pod1 和 pod2），均分配 9G 内存。应用使用了 hutool 图形验证码，并基于 openjdk:8-jdk-alpine 镜像构建了自定义镜像。pod2 容器运行一段时间后异常停止，pod1 容器则由于设置了 restart: always 而自动重启。

容器日志显示 Java 运行时环境检测到致命错误 SIGILL (0x4)，并在 libawt.so 库中出现问题。 ldd libjawt.so 命令的输出表明缺少 libawt_xawt.so 库，这导致 libjawt.so 库无法正确加载。

虽然系统内存充足，但 libawt.so 相关的错误提示强烈暗示问题并非内存不足，而是缺少必要的依赖库。 openjdk:8-jdk-alpine 镜像是一个精简版的 Java 运行时环境，默认不包含 AWT（抽象窗口工具包）相关的库，而 AWT 库是 hutool 图形验证码功能所依赖的。因此，仅仅安装 ttf-dejavu 和 fontconfig 还不够，因为这些库只是字体相关的，而 AWT 还需要更多图形相关的库文件。

建议尝试以下解决方案：

1. 安装缺失的依赖库: 在 Dockerfile 中，除了 ttf-dejavu 和 fontconfig 之外，还需要安装 xorg-x11-utils (或者其在其他发行版中的等效包)。这将提供 AWT 运行所需的必要环境。 请注意，这会显著增加镜像大小。
2. 更换基础镜像: 考虑使用一个包含完整 AWT 支持的基础镜像，例如一个包含图形化环境的 openjdk 镜像，而不是 openjdk:8-jdk-alpine。 这能避免复杂的依赖安装过程，并使镜像更加轻量级。
3. 检查 hs_err_pid1.log: 提供完整的 hs_err_pid1.log 文件，该文件包含了 Java 虚拟机崩溃的详细堆栈信息，可以帮助更准确地定位问题。

通过以上步骤，可以尝试解决 SpringBoot 应用在 Docker 容器中因缺少图形化依赖而导致异常停止的问题。

以上就是SpringBoot2应用在Docker中异常停止(Exited 139)并提示libawt.so错误，该如何解决？的详细内容，更多请关注php中文网其它相关文章！