多阶段Java构建arm64镜像时Docker buildx在jar解压步骤挂死如何调试

基础兼容性排查 #

• 先在宿主机原生环境直接执行jar -xf your-app.jar，确认jar包本身无损坏、解压逻辑正常，排除应用打包导致的问题
• 临时修改Dockerfile中解压命令，替换为unzip工具验证：jar包本质是zip格式，先安装unzip再执行解压，命令如下：

  RUN apk add --no-cache unzip && mkdir -p unpacked && unzip ../*.jar -d unpacked
  

  若替换后arm64构建可以正常执行，说明是qemu模拟arm64环境下openjdk自带的jar工具存在兼容性问题
• 更换openjdk基础镜像版本测试：不用alpine版本，切换为debian系的openjdk:8-jdk-slim，排除alpine的musl libc和qemu的兼容冲突

qemu模拟层问题排查 #

• 升级本地qemu-user-static到最新版本，老旧版本存在大量Java类程序arm64模拟的已知bug，升级后重新执行构建验证
• 关闭多平台并行构建，单独构建arm64平台镜像，命令如下：

  docker buildx build --platform linux/arm64 -t mytag .
  

  排除多任务并行资源抢占导致的qemu异常
• 新增strace跟踪系统调用定位挂死点：修改RUN命令，安装strace后执行解压并输出调用日志：

  RUN apk add --no-cache strace && mkdir -p unpacked && (cd unpacked; strace -o /tmp/jar_strace.log jar -xf ../*.jar)
  

  进程挂死后可通过docker cp将容器内的/tmp/jar_strace.log拷贝到宿主机，查看最后执行的系统调用，确认是qemu模拟缺陷还是jar工具本身逻辑问题

规避方案（无需排查根因可直接解决问题） #

• 最优方案：指定build阶段使用宿主机原生架构执行，无需qemu模拟。build阶段仅做jar包解压，产物和平台无关，修改Dockerfile第一行即可：

  FROM --platform=$BUILDPLATFORM openjdk:8-jdk-alpine as build
  

  该方案下build阶段用原生x86架构运行，解压速度远快于qemu模拟，从根源避免兼容问题
• 提前在宿主机解压jar包，直接将解压后的文件COPY到build镜像中，完全跳过容器内解压步骤
• 改用Spring Boot官方分层构建插件，打包时直接生成分层目录，不需要容器内解压操作

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