我的 Java 容器上线后总是莫名其妙被杀、日志没有任何异常就直接退出 137,我对着 OOMKilled 和容器内存限制排查了大半天的复盘

那是我们把一个跑得好好的 Java 服务容器化、扔上 Kubernetes 后的第一个星期。服务时不时就"无声无息"地重启一次:应用日志里没有任何异常堆栈、没有 OOM 报错、没有任何征兆,进程就那么直接没了,然后被拉起来。一开始我以为是代码有 bug,翻遍日志一无所获。直到我 kubectl describe pod,看到那行 Last State: Terminated, Reason: OOMKilled, Exit Code: 137,才意识到:不是我的程序崩了,是它被外面的"什么东西"给杀了。我对着这个 137 退出码和"容器内存限制"排查了大半天,最后才搞懂:问题出在 JVM 根本不知道自己活在一个有内存上限的容器里。这篇就把这场"容器 OOMKilled"的事故,从头复盘一遍。

故障现场:没有异常日志,只有一个 137

先看现场。应用日志干干净净,但容器状态和退出码出卖了真相:

# 1. 应用日志: 啥异常都没有, 最后一行很正常, 然后就没了
2026-06-02 14:23:01 INFO  处理请求 orderId=88231 完成
2026-06-02 14:23:01 INFO  处理请求 orderId=88232 完成
# ... (然后进程直接消失, 没有任何 ERROR / Exception / OOM 字样)

# 2. kubectl 看 Pod 状态: 重启了好几次
$ kubectl get pod my-app-xxx
NAME          READY   STATUS    RESTARTS   AGE
my-app-xxx    1/1     Running   7          3h        # ← 重启了 7 次!

# 3. kubectl describe: 真相大白 —— OOMKilled, 退出码 137
$ kubectl describe pod my-app-xxx
    Last State:     Terminated
      Reason:       OOMKilled      # ← 被 OOM Killer 杀了
      Exit Code:    137            # ← 128 + 9(SIGKILL), 被强制杀死
    Restart Count:  7

# 4. 这个容器的内存限制 (Pod 的 resources.limits):
$ kubectl get pod my-app-xxx -o yaml | grep -A2 limits
    limits:
      memory: "1Gi"    # ← 容器内存上限 1G

# 5. 但是! 进 容器里看 JVM 自己认为的最大堆:
$ kubectl exec -it my-app-xxx -- java -XX:+PrintFlagsFinal -version | grep MaxHeapSize
   size_t MaxHeapSize  = 8589934592    # ← 8G !!! JVM 以为自己能用 8G

# 现象拼图:
#   - 容器限制内存 1G, 超了就被宿主机 OOM Killer 用 SIGKILL 杀死(137)。
#   - 但老版本 JVM 不识别容器(cgroup)内存限制, 它看到的是"宿主机物理内存"
#   - 宿主机有 32G 物理内存, JVM 默认堆 = 物理内存的 1/4 = 8G。
#   - 于是 JVM 放心大胆地申请堆内存往 8G 涨, 一旦实际用量超过 1G,
#     容器就被 OOMKilled。JVM 自己还没来得及抛 OutOfMemoryError 就被杀了,
#     所以日志里干干净净 —— 它是被"从外面"强杀的, 不是自己 OOM。

看到 JVM 自报的 MaxHeapSize = 8G、而容器限制只有 1Gi 时,我彻底明白了这出"无声死亡"的剧本:容器把内存卡在 1G,可 JVM 却以为自己有 8G 可用,于是堆内存一路往上涨,刚冲过 1G,就被宿主机的 OOM Killer 一个 SIGKILL(信号 9)秒杀。退出码 137 = 128 + 9,正是"被 SIGKILL 杀死"的标志。而日志之所以干净,是因为JVM 是被"从外面强杀"的,它自己根本没机会抛 OutOfMemoryError——这跟应用代码内部的 OOM 是两码事。

第一件事:搞懂 JVM 为什么"看不见"容器的内存限制

要解决它,得先搞懂为什么 JVM 会对容器的内存限制"视而不见"。

JVM 与容器内存限制的"认知错位"

# 容器是怎么限制内存的?
#   - 容器(Docker/K8s)靠 Linux 的 cgroup 机制限制资源。
#   - memory limit 写在 cgroup 里(如 /sys/fs/cgroup/memory/...)。
#   - 超过 limit → 内核的 OOM Killer 用 SIGKILL 杀掉容器内进程。

# JVM 默认怎么决定堆大小?
#   - 不指定 -Xmx 时, JVM 用"人体工学(ergonomics)"自动算默认值。
#   - 默认最大堆 ≈ 物理内存的 1/4。
#   - 关键问题: 老 JVM 读的"物理内存", 是"宿主机的", 不是"容器限制的"!
#     它通过 /proc/meminfo 看到的是整台宿主机的内存(如 32G)。

# 于是认知错位:
#   宿主机物理内存 32G → JVM 默认堆 = 32/4 = 8G
#   但容器只给 1G → JVM 以为有 8G, 拼命涨, 超过 1G 就被杀。

# 为什么老 JVM 不识别 cgroup?
#   - JDK 8 早期版本(8u131 之前)完全不感知 cgroup。
#   - JVM 设计时, 容器还不普及, 它默认"我能用整台机器的资源"。

# 修复历程:
#   - JDK 8u131+ : 加了 -XX:+UseCGroupMemoryLimitForHeap(实验性, 需手动开)
#   - JDK 8u191+ / JDK 10+ : 默认支持容器感知(UseContainerSupport, 默认开)
#     JVM 会自动读 cgroup 的 limit 来算堆, 不再用宿主机物理内存。

# 核心: 老 JVM 按"宿主机物理内存"算默认堆, 看不见容器(cgroup)的内存限制,
#   于是堆涨到远超容器 limit, 被 OOM Killer(SIGKILL/137)强杀。

原来这场事故的根,是一个深刻的"认知错位"。容器靠 Linux 的 cgroup 机制限制内存(超了就被内核 OOM Killer 用 SIGKILL 杀掉);而 JVM 不指定 -Xmx 时,会用"人体工学"自动算默认堆 ≈ 物理内存的 1/4。问题就在这"物理内存"上:老版本的 JVM,通过 /proc/meminfo 读到的是"整台宿主机"的内存(比如 32G),而不是"容器被限制的"内存(1G)。于是认知彻底错位:宿主机 32G → JVM 默认堆 8G;但容器只给 1G → JVM 以为有 8G、拼命涨、一超过 1G 就被杀。根本原因是历史的:JVM 早期设计时容器还不普及,它默认"我能用整台机器的资源",完全不感知 cgroup。好在 JVM 后来修复了这个问题:JDK 8u191+ / JDK 10+ 默认开启了容器感知(UseContainerSupport),会自动读 cgroup 的 limit 来算堆。搞懂了这层,正解的方向就有了:要么升级 JVM 让它感知容器,要么手动告诉它"你只有这么多内存"。

第二件事:正解——让 JVM 感知容器,并留足堆外内存

搞懂了原理,正解就清晰了:升级 JVM 或显式设堆,让它的内存认知与容器 limit 对齐;并且 limit 要留足堆外内存余量。

# ====== 正解一(推荐): 升级 JDK + 用比例参数让 JVM 感知容器 ======
# JDK 8u191+ / JDK 10+ 默认开启容器感知(UseContainerSupport)。
# 用 MaxRAMPercentage 让堆按"容器 limit 的百分比"自动算:
java -XX:MaxRAMPercentage=75.0 -jar app.jar
#   → JVM 读 cgroup limit(1G), 堆 = 1G * 75% = 768M, 不会超容器限制。
#   (别用老的 -Xmx 写死, 用百分比能自适应不同 limit 的环境)

# ====== 正解二(老 JDK 兜底): 显式设 -Xmx, 且小于容器 limit ======
# 若没法升级 JDK, 必须手动指定堆上限, 并明确小于容器 limit:
java -Xmx640m -jar app.jar      # 容器 limit=1G, 堆给 640m, 留 ~360m 余量

# ====== 正解三(关键!): 容器 limit 要 > 堆 + 堆外内存 ======
# 大坑: JVM 进程总内存 ≠ 堆! 还有一大堆"堆外内存":
#   总内存 ≈ 堆(Heap)
#          + Metaspace(类元数据, 默认无上限!)
#          + 线程栈(每线程 ~1M, 线程多很可观)
#          + 直接内存(DirectByteBuffer, NIO/Netty 用)
#          + JIT 代码缓存 + GC 结构 + ...
# 所以: 容器 limit 必须 > 最大堆 + 预估的堆外内存, 否则堆没满、
#   堆外涨上来照样把容器撑爆 OOMKilled。
#   经验: 堆设为 limit 的 50%~75%, 给堆外留 25%~50%。

# ====== 正解四: 给 Metaspace 也设上限(防它无限涨)======
java -XX:MaxMetaspaceSize=256m -jar app.jar   # 别让类元数据无限制增长

# ====== 正解五: K8s 里 requests 和 limits 都要设 ======
# resources:
#   requests: { memory: "1Gi" }   # 调度依据
#   limits:   { memory: "1Gi" }   # 超了被杀; 建议 requests=limits(稳定)

# ====== 验证: 进容器确认 JVM 认对了内存 ======
java -XX:+PrintFlagsFinal -version | grep -E "MaxHeapSize|MaxRAMPercentage"
#   → 确认 MaxHeapSize 是按容器 limit 算的, 不是宿主机的 1/4。

# 核心: 升级 JDK + MaxRAMPercentage 让 JVM 感知容器; 容器 limit 必须
#   大于"堆+堆外内存"; 给 Metaspace 设上限; 上线后 PrintFlagsFinal 验证。

修复的方向,是"消除 JVM 与容器之间的内存认知错位,并为堆外内存留足空间"。正解一(推荐):升级 JDK + 用 MaxRAMPercentage——JDK 8u191+/10+ 默认感知容器,用 -XX:MaxRAMPercentage=75.0 让堆按容器 limit 的百分比自动算(自适应不同环境,比写死 -Xmx 好)。正解二(老 JDK 兜底):显式设 -Xmx 且明确小于容器 limit。而最容易被忽略、也最关键的是:正解三:容器 limit 必须大于"堆 + 堆外内存"——JVM 进程的总内存远不止堆,还有 Metaspace(类元数据,默认无上限)、线程栈、直接内存(Netty/NIO)、JIT 缓存 等一大堆堆外内存;所以哪怕堆没满,堆外涨上来照样撑爆容器(经验:堆设为 limit 的 50%~75%,给堆外留 25%~50%)。正解四:给 MaxMetaspaceSize 设上限(防它无限涨);正解五:K8s 里 requests 和 limits 都设,且建议相等。最后别忘了用 PrintFlagsFinal 验证 JVM 真的认对了内存。归根结底:升级 JDK + MaxRAMPercentage 让 JVM 感知容器;limit 必须大于堆+堆外;Metaspace 设上限;上线后验证。

第三件事:退出码 137/143 与 OOMKilled 的识别

这次踩坑后,我把容器"异常退出"的几个关键退出码和 OOM 类型系统梳理了一遍,以后一看退出码就知道大概发生了什么。

容器退出码 & OOM 类型速查

# === 退出码(Exit Code)===
# 退出码 = 128 + 信号编号(被信号杀死时)
#   137 = 128 + 9 (SIGKILL)   → 被强杀。最常见: OOMKilled(超内存被杀)
#                                 也可能是 kill -9 / 存活探针失败被杀
#   143 = 128 + 15 (SIGTERM)  → 收到优雅终止信号(正常关闭/滚动更新)
#   139 = 128 + 11 (SIGSEGV)  → 段错误(常见于 native 代码崩溃)
#   1   → 应用自己以非0退出(代码里 System.exit(1) 或未捕获异常)
#   0   → 正常退出

# === 怎么确认是不是 OOMKilled ===
$ kubectl describe pod xxx          # 看 Last State.Reason: OOMKilled
$ dmesg | grep -i "killed process"  # 宿主机内核日志: OOM Killer 记录
#   "Out of memory: Killed process 1234 (java) ..."

# === 两种"OOM", 别搞混 ===
# 1. 容器 OOMKilled(本文): 进程总内存超过 容器 cgroup limit,
#    被内核 OOM Killer 用 SIGKILL 强杀。日志干净, 退出码 137。
#    → 调容器 limit / JVM 堆 / 堆外内存。
#
# 2. JVM 内部 OutOfMemoryError: 堆(或Metaspace等)用满, JVM 自己抛异常。
#    日志里有 "java.lang.OutOfMemoryError: Java heap space"。
#    → 是应用内存泄漏 / 堆设太小, 要分析 heap dump 找泄漏。

# 区别: 137 OOMKilled 是"被外面杀"(看 describe);
#       OutOfMemoryError 是"自己喊疼"(看应用日志)。处理方向完全不同。

# 核心: 137=被SIGKILL(常是OOMKilled超容器内存)、143=SIGTERM(优雅终止)；
#   OOMKilled(外部强杀,日志干净) 与 OutOfMemoryError(JVM自抛,日志有栈) 要分清。

原来容器的"异常退出",光看退出码就能读出大半故事。退出码 = 128 + 信号编号:137 = 128+9(SIGKILL),最常见就是 OOMKilled(超内存被强杀),也可能是存活探针失败被杀;143 = 128+15(SIGTERM),是优雅终止(正常滚动更新);139 是段错误;1 是应用自己非 0 退出。确认是不是 OOMKilled,靠 kubectl describe pod 看 Last State.Reason,或 dmesg 看宿主机内核的 OOM Killer 记录。而最该分清的,是两种完全不同的"OOM":容器 OOMKilled(本文)是进程总内存超过 cgroup limit、被内核从外面 SIGKILL 强杀,日志干净、退出码 137,要调 limit/堆/堆外;而 JVM 内部的 OutOfMemoryError 是堆用满、JVM 自己抛异常,日志里有明确堆栈,通常是应用内存泄漏,要分析 heap dump。一句话区分:137 OOMKilled 是"被外面杀"(看 describe),OutOfMemoryError 是"自己喊疼"(看应用日志),处理方向完全不同。下面这张图,是这次容器 OOMKilled 的成因与解法:

第四件事:JVM 进程内存构成速查

这次踩坑最大的认知升级,是搞懂了"JVM 进程吃的内存,远不止堆"。我把它的内存构成整理成一张表,设置容器 limit 时对照着算。

这张表,把"JVM 到底吃多少内存"这件事彻底讲清了。核心认知是:JVM 进程的总内存 = 堆 + 一大堆堆外内存(Metaspace、线程栈、直接内存、JIT 缓存、GC 结构……);而我们设 -Xmx 时,管的只有堆这一块。最阴险的几个:Metaspace 默认无上限会一直涨、线程栈在高并发多线程时总量可观、直接内存被 Netty/NIO 大量使用——它们全在堆外,-Xmx 管不着。它给我的启发是:设置容器内存 limit,绝不能只盯着堆——必须把堆外内存也算进去,并留足余量(这正是"堆设为 limit 的 50%~75%"这条经验的由来)。更深一层,这让我意识到:理解一个系统的资源消耗,不能只看那个"最显眼的部分"(堆之于 JVM),那些"看不见的、零散的部分"加起来,往往同样可观、甚至致命;做容量规划时,要有"总量视角",把所有部分都纳入计算,而不是用一个局部去估算整体。

第五件事:容器化部署的内存配置清单

这次事故后,我整理了一份"Java 应用容器化"的内存配置检查清单,上线前逐项核对。

这张清单,是我用一次 OOMKilled 换来的"上线前必检项"。它把容器化 Java 应用最容易出问题的几个点都列了出来:用感知容器的 JDK 版本、显式用百分比设堆、给堆外留足空间(堆只占 limit 的 50%~75%)、限制 Metaspace、K8s 的 requests/limits 都设好、上线后用 PrintFlagsFinal 验证。它给我的最大启发,其实超出了内存本身:把"踩过的坑"沉淀成"检查清单",是工程师最高效的成长方式之一。一次故障的价值,不在于"这次修好了",而在于"下次(以及团队里所有人)再也不会犯同样的错";而清单,正是把"个人的、一次性的踩坑经验",转化为"团队的、可复用的、不依赖记忆的"防线的最好载体。比起"靠脑子记住别犯错",一份写下来、上线前逐项核对的清单,要可靠一百倍——因为人会忘、会疏忽,但清单不会。

第六件事:容器频繁重启,我现在的排查路径

现在再遇到容器莫名重启,我不再翻应用日志大海捞针,而是按这张图先定位"是谁、为什么杀了它":

这张图的精髓,是"先用 kubectl describe 看退出码和原因,确定死因,再对症下药"。第一步永远是 describe 看 Last State(而不是一头扎进应用日志)。然后按退出码分流:OOMKilled/137 且日志干净 → 容器 OOMKilled(总内存超 limit),查 JVM 堆是否按宿主机算、升级 JDK + MaxRAMPercentage + 留足堆外;137 但其实是探针 → 存活探针失败被杀,查探针配置;Error/1 → 应用自己崩,看异常栈;日志里有 OutOfMemoryError → JVM 内部 OOM,是内存泄漏,分析 heap dump。最后一定复测验证(describe 确认不再 OOMKilled)。这套路径,让我面对"容器莫名重启"时,从"翻日志翻到崩溃"变成了"看退出码精准定位"——核心始终是:容器异常退出,退出码和 describe 的 Reason 才是第一手死因证据,先验尸、再断案。

我立下的几条规矩

这场"容器 OOMKilled"的事故,换来了我做容器化部署时,刻进骨子里的几条铁律:

1. 用感知容器的 JDK。JDK 8u191+ / 11+ / 17+,默认开 UseContainerSupport,堆按 cgroup limit 算。
2. 显式用 MaxRAMPercentage 设堆。别靠默认(按宿主机物理内存算),用百分比自适应不同 limit。
3. 容器 limit 必须大于"堆 + 堆外内存"。堆只占 limit 的 50%~75%,给 Metaspace/线程栈/直接内存留空间。
4. 给 Metaspace 设上限。它默认无上限,会悄悄涨到把容器撑爆。
5. 容器异常先 describe 看退出码。137=被强杀(常是OOMKilled)、143=优雅终止;别一上来翻应用日志。
6. 分清 OOMKilled 与 OutOfMemoryError。前者被外部强杀(日志干净),后者 JVM 自抛(有栈),处理方向相反。
7. 把踩坑沉淀成上线检查清单。逐项核对,让团队不再犯同样的错——人会忘,清单不会。

附:一份容器感知的 JVM 启动配置 + Dockerfile

口说无凭。下面给一份我现在用的、容器感知的 Java 应用 Dockerfile 和 K8s 内存配置,直接抄走改改就能用:

# ====== Dockerfile: 用感知容器的 JDK + 百分比堆参数 ======
FROM eclipse-temurin:17-jre   # ← 用 JDK 17(默认感知容器), 别用老 JDK8

WORKDIR /app
COPY app.jar app.jar

# 关键: 用 MaxRAMPercentage 让堆按"容器limit的百分比"算(自适应)
# 堆给 75%, 留 25% 给堆外内存(Metaspace/线程栈/直接内存)
ENV JAVA_OPTS="-XX:MaxRAMPercentage=75.0 \
    -XX:MaxMetaspaceSize=256m \
    -XX:+HeapDumpOnOutOfMemoryError \
    -XX:HeapDumpPath=/dump \
    -XX:+PrintFlagsFinal"

# 用 exec 形式, 让 java 成为 PID 1, 能正确收到 SIGTERM(优雅停机)
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

# --- 对应的 K8s 部署内存配置(deployment.yaml 片段)---
# spec.containers[].resources:
#   requests:
#     memory: "1Gi"      # 调度依据
#   limits:
#     memory: "1Gi"      # 上限; requests=limits 更稳定, 不会被驱逐
# 算账: limit 1Gi → 堆 = 1Gi*75% = 768M, 堆外 ~256M, 刚好。

# --- 上线后进容器验证(必做!)---
# kubectl exec -it POD -- java -XX:+PrintFlagsFinal -version \
#   | grep -E "MaxHeapSize|MaxRAMPercentage"
# 期望: MaxHeapSize ≈ 768M(按limit算), 不是宿主机的 8G。

# 核心: 用感知容器的JDK + MaxRAMPercentage(堆75%)+ 限制Metaspace
#   + limit留足堆外 + exec形式收SIGTERM + 上线PrintFlagsFinal验证。

这份配置,把这篇文章所有的经验,落成了可以直接落地的代码。几个关键点再强调一遍:基础镜像用 eclipse-temurin:17-jre(JDK 17 默认感知容器,别用老 JDK 8);用 -XX:MaxRAMPercentage=75.0 让堆按 limit 的百分比自适应(留 25% 给堆外);用 -XX:MaxMetaspaceSize 限制 Metaspace;加 HeapDumpOnOutOfMemoryError 方便事后分析。还有两个容易忽略的细节:用 exec 形式的 ENTRYPOINT,让 java 成为 PID 1,才能正确收到 SIGTERM 实现优雅停机;K8s 里 requests=limits 更稳定(不会被驱逐)。最后那条上线后进容器 PrintFlagsFinal 验证 MaxHeapSize 真的按 limit 算了,是我现在雷打不动的步骤。这,正是我想用这份配置,留给每个容器化 Java 应用的人的最后一课:"设置了参数" ≠ "参数生效了"——配置类的东西,最怕"自以为设对了",而实际因为版本、环境、优先级等原因没生效;所以,凡是重要的配置,都要有一个"验证它确实生效"的动作兜底。从"写配置"到"验证配置",这一步之差,正是"看起来配好了"和"真的配好了"之间,那道最关键的鸿沟。

延伸:不止内存,CPU 核数也有同样的"容器盲区"

解决完内存问题,我后知后觉地意识到一件更可怕的事:这个"容器内的程序看到的是宿主机资源、而非容器限制"的坑,绝不止内存一处——CPU 核数,有着一模一样的问题。很多框架和库,会按"CPU 核数"来决定默认的线程池大小、并发度、GC 线程数:比如 Runtime.getRuntime().availableProcessors()、Java 的 ForkJoinPool.commonPool()、各种连接池/线程池的默认大小、Netty 的 worker 线程数……它们都默认拿"可用 CPU 核数"去乘一个系数。而老版本的 JVM(以及很多语言运行时),在容器里调 availableProcessors() 时,返回的是"宿主机的核数"(比如 64 核),而不是"容器被 cgroup 限制的核数"(比如 limit 只给了 2 核)。后果是什么?一个只分到 2 核的容器,里面的程序却以为有 64 核,于是创建了 64 倍于实际算力的线程——线程数远超 CPU 能并行的数量,导致大量线程上下文切换、CPU 时间片被疯狂争抢、性能不升反降,甚至线程多到再次撑爆内存。好在解法和内存如出一辙:JDK 8u191+/10+ 同样让 availableProcessors() 感知 cgroup 的 CPU limit(也可用 -XX:ActiveProcessorCount=N 手动指定)。这件事让我把那条领悟又夯实了一遍:容器化的本质,是"用 cgroup 给程序划定资源边界";而程序能否正确感知这些边界(内存、CPU、IO……),决定了它在容器里是"守规矩的好公民"还是"横冲直撞被反复教训的莽汉"。所以,每当我要把一个程序放进容器,我都会多问一句:它,真的知道自己被关进了多大的笼子吗?——内存知道吗?CPU 核数知道吗?把这个问题问全、并逐一验证,才算真正完成了"容器化"这件事。

写在最后

回头看,这场由"JVM 看不见容器内存限制"引发的、无声无息的重启事故,真正教给我的,远不止那几个 JVM 参数。它让我深刻地意识到:当我们把一个程序"装进容器"时,我们其实是给它套上了一层它未必能感知到的"边界";而"程序以为的自己"和"它实际所处的环境",一旦发生错位,就会酿成最隐蔽的故障。我的 JVM,以为自己住在一台 32G 的大房子里,于是大手大脚地用内存;它不知道自己其实被关进了一个 1G 的小房间,一伸手就撞墙(被杀)。这种"主体对自身所处环境的认知错误",是容器化时代一类非常典型的坑——不只内存,CPU 核数(线程池大小常按 CPU 数算)、文件系统、网络,都存在类似的"容器内的程序,看到的可能是宿主机的、而非容器限制的"问题。这让我领悟到一个朴素却深刻的道理:用好任何"隔离/虚拟化"技术(容器、虚拟机、沙箱)的前提,是确保里面的程序,能正确感知到它被施加的边界;否则,边界是外部强加的(硬),而程序的行为是按"无边界"来的(软),两者一冲突,就是 SIGKILL。而具体到排查,这次还给了我一条铁律:容器异常退出,先看退出码——它是死因最直接的证据。这,是我用一次"容器无声重启"的事故,换来的、关于容器化、也关于"环境感知"的、最朴素也最深刻的领悟。如果这篇复盘,能让你在下次容器化 Java 应用时,顺手加上 -XX:MaxRAMPercentage 并确认 limit 留足了堆外空间,那我对着那个 137 熬的这大半天,就值了。

—— 别看了 · 2026