搜索结果: "jvm"

title: JVM 容器 OOM 排障指南 — 堆外内存视角

sources: [raw/articles/JVM-堆只用了-70--容器却天天-OOMKilled--你看到的内存不是真实的内存.md]

# JVM 容器 OOM 排障指南 — 堆外内存视角

> JVM 堆只用了 70%，容器却被 OOMKilled？核心原因是**容器（cgroup）看到的是进程所有 RSS**，而监控面板通常只展示 JVM 堆内存。堆外内存（DirectByteBuffer、Metaspace、线程栈等）悄悄吃满额度才是元凶。

Java 服务在容器中频繁 OOMKilled，但 JVM 堆内存利用率仅 70% 左右、看似充裕，这是最常见的「容器 OOM 但堆没问题」故障模型。

tags: [kubernetes, java, jvm, memory, performance, troubleshooting, architecture]

sources: [raw/articles/容器里的-JVM-不只是--Xmx-Kubernetes-下-Java-内存调优的原理-架构与生产实战.md]

> K8s 下的 JVM 调优不是参数微调，而是一套跨越 Linux cgroup、JVM 内存模型、Spring Boot/Netty 工程实现、K8s 编排与发布策略的系统工程。先做预算再配参数，先收敛并发再谈 GC，先让系统稳定再追求极限吞吐。

2. **OOM 的触发条件不是「堆满」，而是「cgroup 无法再满足内存分配」** — JVM 堆只到 60% 容器仍可能 OOMKilled

## 容器里 JVM 的完整内存版图

- 说明：Linux 全栈调优案例（CPU/内存/磁盘/网络/JVM/Docker），USE 方法论，P50 280ms→45ms / P99 520ms→80ms

## [2026-05-19] update | SCHEMA.md — 注册 java/jvm 标签

- 新增标签: java (Java 应用层排障), jvm (JVM 调优与 GC 分析)

| 2026-05-29 11:17 | create | jvm-container-oom-offheap-troubleshooting | tags: kubernetes,java,troubleshooting,memory,container,performance | source: 蹦跶的小羊 2026-05-21 | P2 auto-publish, 6 cross-refs |

| 2026-05-29 13:54 | create | k8s-java-memory-tuning-production-guide | tags: kubernetes,java,jvm,memory,performance,troubleshooting,architecture | source: 小随小看 2026-05-25 | P2 auto-publish, 5 cross-refs |

value: "-Xmx512m -Xms256m" # 明确 JVM 堆内存

memory: "768Mi" # 覆盖 JVM heap + overhead

**JVM 和容器内存配合：** `-Xmx` 应等于或略小于容器 memory limit，

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi

tags: [linux, java, performance, troubleshooting, case-study, jvm]

- `VM Thread` → JVM 自身操作

expr: rate(jvm_gc_pause_count_total{type="full"}[1m]) > 1

- [[fullstack-performance-troubleshooting]] — 全栈性能排查（含 JVM GC 深度分析）

- JVM `-Xmx` 设为容器的 75%，避免超出 cgroup limit

**JVM 参数优化：**

容器内 JVM 正确识别 cgroup 限制（`-XX:+UseContainerSupport`，Java 10+ 默认开启）。

| [[jvm-container-oom-offheap-troubleshooting]] | JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi |

# JVM 堆内存 + native/direct buffer/mmap 等堆外内存之和 ≤ 容器 memory limit

# 建议 JVM -Xmx 设置为容器 limit 的 75-80%

| [[jvm-container-oom-offheap-troubleshooting]] | JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi |

**Java 特殊注意：** JVM 内存 ≠ -Xmx。包含堆 + 元空间 + 直接内存 + Native。用 `jcmd VM.native_memory`。

- Java：合理设置 `-Xmx` / `-Xms`，避免 JVM 吃光内存

| [[jvm-container-oom-offheap-troubleshooting]] | JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi |

| 16 | JVM 内存结构？ | 堆(年轻代/老年代) + 方法区 + 栈 + PC + 本地方法栈 | — |

| 17 | JVM 性能优化？ | 堆大小 + GC 选择 + GC 参数 + 内存泄漏 + 对象池 + 代码优化 | — |

详见 [[jvm-container-oom-offheap-troubleshooting]]。

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 容器 OOM 排障（堆外内存）

| JVM 预热 | 刚启动时响应极慢，需要预热过程 |

| [[k8s-resource-limits-configuration]] | 资源限制与 JVM 预热配合 |

- Java: JVM `-Xmx` 设为容器 limit 的 75-80%

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi

# Java：查看 JVM 内存（堆+元空间+Native）

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKilled 的排障指南

- [[linux-api-performance-tuning-case-study]] — Linux 系统调优实战：接口 500ms→100ms 全复盘（CPU/内存/磁盘/网络/JVM/Docker）

- jvm: JVM 调优与 GC 分析

`/healthz` 在 Spring Boot Actuator 中默认只要 JVM 启动就返回 200，**不代表业务就绪**。

| [[linux-api-performance-tuning-case-study]] | Linux 系统调优实战案例（CPU→JVM→网络全栈） |

**根因：** JVM heap 配置 8GB，GC 扫描区域过大。