alpine linux 的 openjdk 镜像因基于 musl libc 而非 glibc，易导致 native 依赖报错、诊断工具缺失、时区/字符集异常、jvm 内存配置失效及高并发下偶发超时，建议优先选用 debian 基础镜像或严格验证兼容性。
Alpine Linux 上的 OpenJDK 版本不等于标准 JDK
Alpine 默认用的是 openjdk:alpine 镜像，但它底层用的是 musl libc 而非 glibc。很多 Java 库（尤其是带 native 依赖的，比如 netty-tcnative、grpc-java 或某些 JDBC 驱动）在 musl 下会直接报 UnsatisfiedLinkError 或启动失败。
- 优先查你用的依赖是否明确支持 Alpine —— 看项目 README 是否写了 “musl” 或 “Alpine compatible”
- 如果用了 Spring Boot 2.7+，默认打包的
spring-boot-loader在 Alpine 上可能因 classloader 行为差异出问题，建议加-Djarmode=layertools并用java -Djarmode=layertools -jar app.jar extract解压后运行 - 实在绕不开 native 依赖？别硬扛，换
eclipse-temurin:17-jre-jammy（Debian base，小且兼容）比修 musl 问题更省时间
FROM openjdk:17-jre-alpine 的隐患
这个镜像看似轻量（~80MB），但实际隐含两个风险：JRE 缺少 jstack/jmap 等诊断工具，且 Alpine 的 apk 包管理器和 Java 运行时存在时区、字符集等默认配置偏差。
- 运行时若需堆 dump 或线程分析，得手动
apk add openjdk17-jdk—— 但这样镜像体积翻倍，还引入未验证的包组合 -
Locale.getDefault()在 Alpine 上常返回POSIX，导致SimpleDateFormat解析失败或日志乱码；必须显式加 JVM 参数：-Duser.language=en -Duser.country=US -Dfile.encoding=UTF-8 - 时区默认是 UTC，
new Date()输出不匹配业务预期；要么挂载/etc/localtime，要么启动时加-Duser.timezone=Asia/Shanghai
多阶段构建中 COPY target/*.jar 的陷阱
Spring Boot Maven 插件打的 fat jar 在 Alpine 上可能因路径解析或权限问题无法执行，尤其当 MANIFEST.MF 里 Class-Path 含空格或特殊符号时。
- 确认 jar 是可执行的：
java -Djava.security.egd=file:/dev/./urandom -jar app.jar --help在本地 Alpine 容器里先跑通 - 避免用
COPY ./target/*.jar app.jar—— shell 展开顺序不可控，万一生成多个 jar 会覆盖错；改用精确路径：COPY target/myapp-1.0.0.jar app.jar - Alpine 的
sh不支持[[，所以别在 entrypoint.sh 里写[[ -f app.jar ]]做校验，用[ -f app.jar ]
JVM 参数在容器里必须调低堆内存
Docker 容器的 cgroup 内存限制对 JVM 不透明，OpenJDK 8u191+ 和 10+ 虽支持 +UseContainerSupport，但 Alpine 上的旧版 JRE（如 8u212-alpine）默认不开启，会导致 OOMKilled。
立即学习“Java免费学习笔记（深入）”；
- 强制启用容器感知：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0（别用MaxRAM，它已被废弃） - Alpine 的
free命令输出格式和 procfs 不一致，MaxRAMPercentage计算可能不准；稳妥起见，直接设-Xmx512m这类固定值 - 别信 “Alpine 更省内存” —— musl 的 malloc 实现对 Java 大对象分配并不友好，GC 暂停时间可能反而比 glibc 长 10%~20%
最麻烦的不是镜像大小，是 musl 和 glibc 对系统调用的语义差异——它们不会报错，只会让应用在高并发下偶发超时或连接复用失效。上线前务必用真实流量压测。
