Spring Boot 2 应用在 Docker 容器中异常退出(Exited(139))，如何排查并解决？

本文针对Spring Boot 2应用在Docker容器中异常退出（Exited(139)）问题，提供详细的排查和解决方法。 CentOS 8.5系统上，一个Spring Boot应用在Docker容器中启动后立即异常停止，日志指向libawt.so缺失。经排查发现，问题源于基于openjdk:8-jdk-alpine镜像构建的Dockerfile缺少X Window System相关库，导致依赖libawt_xawt.so缺失。解决方法包括在Dockerfile中安装xorg-x11-utils等库，或更换为包含完整图形环境的OpenJDK基础镜像。本文还强调了分析hs_err_pid1.log文件的重要性，以便更精准地定位问题。

Spring Boot 2 应用在 Docker 容器中异常退出的排查与解决

本文分析并解决Spring Boot 2应用在Docker容器中异常停止（Exited(139)）的问题。

问题描述:

在CentOS 8.5系统上，使用Docker 19.03.13和Docker Compose部署了两个Spring Boot 2应用实例（pod1和pod2），均使用相同的Dockerfile和9G JVM内存配置。pod2容器启动后立即异常停止，状态显示为Exited(139)。容器日志显示最终错误指向libawt.so，疑似缺少依赖。服务器内存充足，GC日志未显示内存溢出。

Dockerfile分析:

Dockerfile基于openjdk:8-jdk-alpine-with-font镜像，采用多阶段构建，最终镜像包含应用jar包及其依赖。Dockerfile已安装字体库ttf-dejavu和fontconfig，暗示应用可能使用了图形验证码库（例如hutool）。

排查步骤:

已执行以下排查步骤：

1. 查看Docker日志，错误信息指向libawt.so。
2. 检查/usr/lib/jvm/java-1.8-openjdk/lib/amd64目录下的libjawt.so文件，发现其依赖库libawt_xawt.so缺失。
3. 确认系统内存充足。
4. 检查pod2容器的GC日志，未发现内存溢出。
5. 进入pod1容器，查看Java版本信息。
6. 对比本地和容器内Java版本，发现版本差异。
7. 对比本地和服务器Docker版本，差异较小，可能性较低。
8. 查看/var/lib/messages系统日志，寻找更多线索。

问题分析与解决方案:

问题根源在于libawt.so及其依赖库缺失。libawt.so是Java AWT库的一部分，依赖X Window System提供图形界面支持。openjdk:8-jdk-alpine镜像精简，默认不包含X Window System相关库。虽然安装了ttf-dejavu和fontconfig，但仅支持字体渲染，不足以满足AWT的图形化需求。libawt_xawt.so缺失正是因为缺少X Window System环境。

解决方法:

1. 安装X Window System相关库: 在Dockerfile中，除了ttf-dejavu和fontconfig，还需安装xorg-x11-utils（或其他发行版的等效包），提供AWT所需的图形环境。这会增加镜像大小。
2. 更换基础镜像: 使用包含完整图形环境的OpenJDK镜像，例如基于Debian或CentOS的镜像，避免繁琐的依赖安装。
3. 分析hs_err_pid1.log: 该文件包含JVM崩溃的详细信息，有助于精确定位问题。

通过以上方法，可解决Spring Boot应用因缺少图形化依赖导致的异常停止问题。 如果问题仍然存在，请提供完整的hs_err_pid1.log文件以便进一步分析。

以上就是《Spring Boot 2 应用在 Docker 容器中异常退出(Exited(139))，如何排查并解决？》的详细内容，更多关于的资料请关注golang学习网公众号！