Java 8u131之前版本在Docker中OOM的主因是JVM忽略cgroup内存限制，直接读取宿主机/proc/meminfo计算堆大小（如64GB主机默认堆约16GB），而容器仅分配512MB，导致超限被OOM Killer终止。
Java 8u131 之前版本在 Docker 容器中无法正确识别内存限制，根本原因是 JVM 完全忽略 cgroup 配置，直接读取宿主机的 /proc/meminfo。比如宿主机有 64GB 内存，JVM 就按 1/4 算出默认堆上限约 16GB；而容器实际只分配了 512MB —— 结果就是进程启动不久就被 Linux OOM Killer 强制终止。
为什么旧版 JVM 看不见容器内存限制
容器与宿主机共享 /proc 文件系统，且以只读方式挂载。因此 cat /proc/meminfo 在容器内显示的仍是宿主机总内存（MemTotal），而非 cgroup 的 memory.limit_in_bytes。JVM 启动时依赖该值估算堆大小，不查 cgroup、不校验容器边界。
- JDK 8u131 之前没有内置 cgroup 检测逻辑
-
Runtime.getRuntime().availableProcessors()同样返回宿主机 CPU 核数，导致 GC 线程数严重超标 - 所有资源推导都基于“物理机视角”，和容器 runtime 完全脱节
典型表现与故障现象
这类问题在 Kubernetes 中尤为明显：Pod 设置 resources.limits.memory: 256Mi，但 Java 进程持续申请远超此值的内存，反复触发 OOMKilled。日志里看不到 java.lang.OutOfMemoryError，而是直接被内核杀掉（Exit Code 137），且 kubectl describe pod 显示 OOMKilled 状态。
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 容器频繁重启，健康检查不断失败又拉起
-
docker stats显示内存使用瞬间冲顶后归零 - jstat 或 JMX 无法采集到堆信息——进程已不存在
临时缓解方案（适用于无法升级 JDK 的场景）
必须显式控制堆上限，且预留足够非堆空间（Metaspace、线程栈、直接内存等）。建议堆设为容器内存限制的 40%～60%，避免踩到硬限。
立即学习“Java免费学习笔记（深入）”；
- 启动命令加
-Xmx128m -Xms64m（对应-m 256M容器） - 禁用自动内存推导：
-XX:-UseAdaptiveSizePolicy - 限制 Metaspace：
-XX:MaxMetaspaceSize=128m - 避免使用
-XX:+UseContainerSupport（该参数在 8u131 前不存在）
根本解决路径
升级 JDK 是最稳妥的方式。8u131 起引入 -XX:+UseCGroupMemoryLimitForHeap（需配合 -XX:+UnlockExperimentalVMOptions），Java 10+ 默认开启 -XX:+UseContainerSupport，可自动从 cgroup 读取内存上限并按比例分配堆。
- 确认基础镜像版本：优先选用
eclipse-temurin:11-jre-focal或amazoncorretto:17-alpine-jdk - 启动参数精简为：
-Xmx1g -XX:+UseContainerSupport（容器-m 2g） - 验证是否生效：启动时加
-XshowSettings:vm，检查输出中Max. Heap Size是否接近预期值
