前言：一次线上排查引发的血案
凌晨三点，告警响了。线上服务 CPU 飙到 100%，你 docker exec 进容器准备用 jstack 抓线程快照——
$ docker exec my-app jstack 11: Unable to get pid of LinuxThreads manager thread
一行报错，排查直接卡死。你试了 jmap、jcmd，全部失败。这不是你代码的 Bug，而是 Alpine Linux + JDK 8 的经典兼容性问题——musl libc 不支持 HotSpot 的 Attach API。
这个坑，从 2016 年就有人在 GitHub 上报了（docker-library/openjdk#76），到 2026 年的今天，仍然有大量团队在踩。
本文将从底层原理讲起，覆盖 JDK 8/11/17/21/25 五个版本在 Alpine 上的兼容性差异，给出明确的选型建议和生产级解决方案。
一、Alpine Linux 为什么这么受欢迎？
在讲问题之前，先理解为什么大家要用 Alpine。
1.1 Docker 镜像大小对比
| 基础镜像 | 大小 | 包管理器 | C 库 |
|---|---|---|---|
ubuntu:22.04 | ~77 MB | apt | glibc |
debian:bookworm-slim | ~74 MB | apt | glibc |
alpine:3.21 | ~7 MB | apk | musl |
Alpine 只有 7MB，是 Ubuntu 的 十分之一。加上 JDK 后：
| Docker 镜像 | 压缩大小 | 磁盘大小 |
|---|---|---|
eclipse-temurin:21-jdk-jammy（Ubuntu） | ~200 MB | ~400 MB |
eclipse-temurin:21-jdk-alpine | ~110 MB | ~220 MB |
镜像小意味着：拉取速度快、启动时间短、CI/CD 流水线快、存储成本低。在 Kubernetes 集群里动辄跑几百个 Pod 的场景下，镜像大小直接影响钱包。
1.2 Alpine 的核心差异：musl vs glibc
Alpine 之所以小，核心原因是它用了 musl libc 替代传统的 glibc（GNU C Library）。
| 维度 | glibc | musl |
|---|---|---|
| 设计理念 | 功能全面，兼容性优先 |
