容器里的 JVM：内核按整个进程记账，JVM 只管得住堆。所以先让 JVM 读到限额，再给堆外每一块留出余量、设上限

不懂精华时的典型误用：Pod 被 OOMKilled，就把 -Xmx 调大，或者把 limit 和 -Xmx 一起调大。前者让堆外更没地方，被杀得更勤；后者只是把同一个比例放大，堆外一涨还是过线。病根不是“内存不够”，是“没给堆外留账”。

选择规则：用 JDK 8u191 以上（cgroup v2 要 8u372 / 11.0.16 / 15+），让 JVM 自己读限额；堆用百分比；直接内存、元空间各设上限；CPU 给 ≥ 2 核，或用 ActiveProcessorCount 明说。本页学的是第三行加这套封顶规则，以及它背后 JVM 和内核各自做了什么。

④-1 限额写在 cgroup 的文件里，JVM 启动时去读

④-2 读到以后：堆、GC、线程数全按它定

HotSpot 有一套“按机器定默认值”的规则，叫 ergonomics。容器支持做的事很简单：把它眼里的“机器”换成 cgroup。下表全部是本机实测（JDK 17.0.20，-XX:+PrintFlagsFinal），公式来自 JDK 17 源码。

框架也跟着 Runtime.availableProcessors() 走：Netty 默认开 2 × CPU 个 EventLoop，并行流和 CompletableFuture 默认用 commonPool。CPU 数读错，整串线程数一起错。

④-3 内核怎么执行：内存到线就杀，CPU 用完配额就停

④-4 为什么这样设计：JVM 只对堆负责，堆外靠封顶

决定胜负的约束：内核按整个进程记账、到线直接 SIGKILL，而 JVM 能收放自如的只有堆。所以 JVM 不去追整个进程，而是把“不够用”尽量挪进它自己能报错的地方。默认只拿 25%，也是这个约束逼出来的：JVM 不知道你的堆外有多大，只好往保守了猜。

CPU 为什么只认 limits，不认 requests：cpu.weight（v1 叫 cpu.shares）是抢不过来时的相对权重，机器空闲时一个 requests 0.5 核的 Pod 可以用满 16 核；把权重折算成“几个核”只是 Docker 早年的约定（1024 份 = 1 核），算出来的数经常偏小。JDK-8281181 在 19 里改掉了，并移植到 17.0.5 和 11.0.17；JDK 8 至今仍按 shares 折算。

最少的参数

# 先看 JVM 看到了什么
java -XshowSettings:system -version            # 打印 cgroup 版本、CPU 配额、内存上限
java -Xlog:os+container=trace -version         # 逐个读了哪些文件
# 堆：按比例
-XX:MaxRAMPercentage=70
# 堆外：逐块封顶
-XX:MaxDirectMemorySize=256m -XX:MaxMetaspaceSize=256m -XX:ReservedCodeCacheSize=128m
# CPU：和配额对不上时明说
-XX:ActiveProcessorCount=2
# 出事时留证据、体面退出
-XX:NativeMemoryTracking=summary -XX:+ExitOnOutOfMemoryError

第 1 步：JVM 看到了什么

Runtime rt = Runtime.getRuntime();
print(cg("memory.max"));       // /sys/fs/cgroup/<自己>/memory.max
print(cg("cpu.max"));
print(rt.availableProcessors());
print(rt.maxMemory() / MB);    // 最大堆
print(ForkJoinPool.commonPool().getParallelism());
for (GarbageCollectorMXBean gc : ManagementFactory.getGarbageCollectorMXBeans())
    print(gc.getName());

$ sudo systemd-run --scope -q -p MemoryMax=512M -p CPUQuota=50% \
    java -cp target/classes labs.jvm.jvm_container.WhatJvmSees
cgroup memory.max      = 536870912
cgroup cpu.max         = 50000 100000
availableProcessors    = 1
maxMemory (heap)       = 123 MB     # 128 MB 减一个 Survivor
commonPool parallelism = 1
GC                     = Copy / MarkSweepCompact   # SerialGC

$ … -p MemoryMax=2G -p CPUQuota=200% …
availableProcessors = 2 · maxMemory = 512 MB · GC = G1

$ … -p MemoryMax=2G … java -XX:-UseContainerSupport …
maxMemory (heap)       = 2984 MB    # 宿主 12 GB 的 25%，比容器还大

$ sudo systemd-run --scope -q -p MemoryMax=512M -p CPUQuota=50% java -Xlog:os+container=trace -version
[os,container] Detected cgroups v2 unified hierarchy
[os,container] Path to /cpu.max is /sys/fs/cgroup/system.slice/run-r56d….scope/cpu.max
[os,container] CPU Quota count based on quota/period: 1
[os,container] Path to /memory.max is /sys/fs/cgroup/system.slice/run-r56d….scope/memory.max
[os,container] Memory Limit is: 536870912

第 2 步：堆外越长越多，被内核杀掉

// 堆里先放 200 MB 活对象，每块都写过
for (int i = 0; i < 200; i++) heap.add(new byte[MB]);
// 每 200 ms 申请 16 MB 直接内存（像 Netty 缓冲越积越多）
try {
    for (int i = 1; ; i++) {
        direct.add(ByteBuffer.allocateDirect(16 * MB));
        System.out.printf("direct %4d MB, RSS=%s%n", i * 16, rss());
        Thread.sleep(200);
    }
} catch (OutOfMemoryError e) {
    System.out.println("JVM 自己报错了：" + e);
    System.exit(3);
}

$ sudo systemd-run --scope -q -p MemoryMax=512M -p MemorySwapMax=0 \
    java -Xmx450m -cp target/classes labs.jvm.jvm_container.OffHeapCreep; echo $?
heap ballast 200 MB, -Xmx=435 MB, RSS=242300 kB
direct   16 MB, RSS=259424 kB
…
direct  272 MB, RSS=522324 kB
direct  288 MB, RSS=539324 kB
Killed
137
$ sudo dmesg | grep 'Killed process'
Memory cgroup out of memory: Killed process 2005783 (java)
  total-vm:3186920kB, anon-rss:522496kB, file-rss:19848kB

看三处：直接内存要到 435 MB（= 最大堆）才会被 JVM 拦住，进程在 288 MB 时就没了；程序里的 catch (OutOfMemoryError) 一次都没执行；dmesg 里被记账的是 anon-rss 约 510 MB，VmRSS 还多算了不进 cgroup 账的共享文件页。

第 3 步：给直接内存封顶，“不够用”回到 JVM 里

$ sudo systemd-run --scope -q -p MemoryMax=512M -p MemorySwapMax=0 \
    java -Xmx450m -XX:MaxDirectMemorySize=64m -cp target/classes labs.jvm.jvm_container.OffHeapCreep; echo $?
direct   48 MB, RSS=292724 kB
JVM 自己报错了：java.lang.OutOfMemoryError: Cannot reserve 16777216 bytes of direct buffer memory (allocated: 50339840, limit: 67108864)
3

到这里已经能交差了。会看 JVM 读到的限额（-XshowSettings:system），能复现并认出 OOMKilled（137 + dmesg），知道用封顶把它换成能被捕获、能记日志的 OutOfMemoryError。

已知还没处理的细节：堆该切多少、堆外各块怎么封顶（⑥ 第二圈）；不设 -Xmx 时被悄悄选成 SerialGC（⑥ 坑 3）；CPU 配额让延迟一阵阵抖（⑥ 坑 5）；JDK 版本太老时读不到 cgroup v2（⑥ 坑 4）。

堆的默认值、GC 和线程数的推法和 ④-2 表里的实测一致（同样的规则在 node 里跑过）。堆外几项是估算：代码缓存按 48 MB、线程栈按每个实际用到 0.5 MB、GC 和 JVM 自身按 40 MB + 堆的 1%（Serial）或 4%（G1）。真实服务用 NMT 实测替换。试试把 D 的 MaxDirectMemorySize 拖到 256：业务还是要 300 MB，结果从“稳”变成 JVM 自己报错，比被杀好查得多。

出处：bugs.openjdk.org 上各 bug 的 fixVersion 和移植记录、8u191 发行说明。8u 的版本号指 OpenJDK 8u 线，Oracle JDK 8 另算。17u、11u 的 JDK-8281181 移植改了默认行为，另加了一个默认关的 -XX:+UseContainerCpuShares 用来恢复旧算法；19 起这两个相关开关都标为废弃。

默认堆的完整规则：为什么 300 MB 和 400 MB 的容器，堆都是 126 MB

JDK 17 Arguments::set_heap_size：只在没设 -Xmx 时走这一段。先算 max = 限额 × 25%、min = 限额 × 50%；如果 min 比 MaxHeapSize 的初值（96 MB × 13/10 ≈ 126 MB）还小，就用 min，否则取 max 和 126 MB 里大的那个。所以限额小于约 250 MB 时堆是一半，250～500 MB 之间卡在 126 MB，500 MB 以上才是 25%。本机实测 200 / 240 / 300 / 400 / 512 MB 分别得到 100 / 120 / 126 / 126 / 128 MB。名字里的 Min 容易误会：它不是“最小堆”，而是“小内存机器上用的比例”。

要不要把 -Xms 设成和最大堆一样

物理机上省着用、按需扩堆是对的；容器里这份内存反正已经划给你了，别人用不了。初始堆设满（-XX:InitialRAMPercentage 和 Max 一样），可以免掉启动后一轮轮扩堆引发的 GC。再加 -XX:+AlwaysPreTouch，JVM 启动时就把堆的每一页都写一遍，记到 cgroup 账上：预算算错了，Pod 在启动时就被杀，而不是半夜高峰时。代价是启动慢一些（大堆几秒）。

堆外的账怎么拍：NMT

-XX:NativeMemoryTracking=summary 启动，jcmd <pid> VM.native_memory summary 按类别列出 JVM 自己申请的本地内存：Java Heap、Class（元空间）、Thread（线程栈）、Code（代码缓存）、GC、Compiler、Internal、Other（直接内存在这里）。每项有 reserved 和 committed，和 cgroup 记账对得上的是 committed。先 VM.native_memory baseline，过一阵子再 summary.diff，涨的那一类就是嫌疑人。NMT 看不到 JNI 库自己 malloc 的内存：committed 总和明显小于容器的 memory.current 时，差额就在那里（glibc 的 malloc arena 碎片也算在内）。

下一圈

• glibc malloc arena 和 MALLOC_ARENA_MAX：NMT 之外的那部分 RSS 是怎么长出来的
• Kubernetes QoS（Guaranteed / Burstable / BestEffort）和 oom_score_adj：节点内存紧张时先杀谁
• CPU 节流的观测和治理：cpu.stat、CFS burst、要不要设 CPU limit 的争论
• 容器里的启动速度：AppCDS、CRaC、Leyden（地图 J14“Java 在容器里”那一项）
• 让 GC 按内存压力自动定堆：OpenJDK 有相关讨论和提案，本页没有核对进展