Java 应用明明配置了-Xmx4g容器限制也是 4 GiB为什么还是会被 Kubernetes 以 OOM Killed 结束老年代使用率一直很高要不要立刻扩大堆Full GC多了是垃圾回收器选错了还是应用确实留住了太多对象这些问题有一个共同的误区把 JVM 内存等同于 Java 堆。堆很重要但它只是进程内存的一部分。生产配置真正要解决的是三件事弄清内存花在哪里给各部分留出合理预算再用监控和现场数据验证预算。一、一个 Java 进程的内存花在哪里从 Java 虚拟机规范看运行时数据区包括堆、方法区、虚拟机栈、程序计数器和本地方法栈。到了 HotSpot 和操作系统这一层还要算上直接内存、代码缓存、GC 数据结构、线程本地存储以及 JNI 或第三方本地库申请的内存。咱们可以把进程内存粗略理解为进程内存RSS≈ Java 堆 元空间与压缩类空间 线程数 × 单线程栈及本地开销 直接内存 JIT 代码缓存 GC/JVM 内部结构 JNI、glibc 等本地分配1、Java 堆对象主要生活的地方绝大多数 Java 对象和数组分配在堆中堆由所有线程共享也是 GC 的主要工作区域。从对象生命周期看传统分代模型把堆分为年轻代和老年代。新对象通常先进入 Eden经历若干次年轻代回收后仍存活的对象会进入 Survivor 区最后晋升到老年代。长期缓存、单例持有的数据和大对象更容易留在老年代。常用参数-Xms 初始堆大小-Xmx 最大堆大小2、元空间类信息不在 Java 堆里方法区是 JVM 规范中的逻辑概念。HotSpot 从 JDK 8 开始用本地内存中的 Metaspace 实现它存放类元数据、运行时常量池等内容。JIT 编译后的机器码则主要进入 Code Cache二者不要混为一谈。元空间常见问题不是普通业务对象太多而是类或类加载器卸载不掉。例如频繁生成动态代理类、重复创建类加载器或者热部署后旧类加载器仍被线程、静态变量持有。常用参数-XX:MetaspaceSize128m-XX:MaxMetaspaceSize512m注意MetaspaceSize不是元空间的初始占用或上限它主要影响首次触发元数据 GC 的阈值。MaxMetaspaceSize才是上限。3、虚拟机栈线程多内存自然就上去了每个 Java 线程都有自己的栈栈帧保存局部变量、操作数栈、返回地址等数据。栈的上限通常由-Xss控制-Xss512k如果服务有 800 个线程按每个线程 1 MiB 的栈上限估算仅线程栈的虚拟内存预算就接近 800 MiB尚未计算线程相关的本地结构。线上 RSS 不一定一次性达到这个数但容器预算不能假装它不存在。减小-Xss能支持更多线程也会降低可容纳的调用深度。比如递归、复杂表达式解析可能会出现StackOverflowError。4、直接内存堆外也会 OOMNIO、Netty、压缩库和零拷贝场景会使用直接内存。它不计入 Java 堆使用量却计入进程 RSS 和容器内存。常用限制参数是-XX:MaxDirectMemorySize512m如果堆曲线平稳、GC 也正常但容器 RSS 持续上涨要重点排查直接内存和其他本地内存。5、程序计数器、本地方法栈与 JVM 自身开销程序计数器记录当前线程执行到哪条字节码体积小却是线程切换后继续执行的基础。本地方法栈服务于 JNI 等本地调用。除此之外JIT 编译后的代码、GC 的记忆集和卡表、符号表、线程本地分配缓冲区等都要占内存。特别注意当Xmx 【容器内存限制】产生危险的原因是Java 堆一旦吃满容器额度其他部分没有任何余地进程很可能先被操作系统杀掉来不及抛出 Java OOM更来不及生成堆转储。二、GC 到底在回收什么JVM 判断对象是否存活核心方法是可达性分析。它从一组 GC Roots 出发沿引用关系查找找不到路径的对象才有资格被回收。常见 GC Roots 包括线程栈中的局部变量、已加载类的静态字段、JNI 引用和 JVM 内部引用。有个容易被忽略的事实内存泄漏不等于对象“没人用了但没释放”。在 Java 中更常见的是业务已经不用某批对象程序却仍保留着一条到它们的强引用路径。无限增长的本地缓存、没有移除的监听器、ThreadLocal使用不当都是典型例子。GC 看不懂业务意图只知道这些对象仍然可达。年轻代回收、混合回收与 Full GCYoung GC 主要处理年轻对象通常频繁但停顿较短。G1 的 Mixed GC 会在处理年轻代的同时回收部分收益较高的老年代 Region。Full GC 往往意味着回收压力已经很大、并发周期跟不上或发生了显式 GC、分配失败等情况。它通常停顿更久但“出现一次 Full GC”不等于一定有泄漏启动、运维操作和特殊分配失败都可能触发它。判断GC是否健康不能只数次数。还应该关注暂停时间、GC后堆占用、对象分配速率、晋升速率、GC消耗的CPU、请求延迟是否同步恶化等三、收集器怎么选注可通过命令查询JDK所使用的收集器java -XX:PrintCommandLineFlags -version1、Serial GC简单、省资源但停顿明显Serial GC 使用单个 GC 线程执行回收。年轻代通常采用复制算法老年代执行标记、整理回收期间应用线程全部暂停。使用场景生命周期较短的任务、单核小容器堆只有几十到几百 MiB 的简单应用。不建议把Serial GC 用于大堆、高并发接口服务。2、CMSJDK1.8时代的低停顿方案CMS 主要负责老年代年轻代通常由 ParNew 回收。它把老年代的大部分标记和清理工作放到应用运行期间并发执行只在初始标记、重新标记等阶段暂停应用。在 JDK1.9被标记为废弃JDK14已经移除。3、Parallel GC批处理更关心单位时间产出Parallel GC是JDK1.8默认的收集器目标偏向吞吐量。批处理、离线计算等任务如果能够接受较长的 Stop-The-World 停顿反而是个不错的选择。4、G1大多数服务的稳妥起点在 JDK 17/21 的常见服务器配置中G1 是默认收集器。它兼顾吞吐与可预测停顿通常只需确定最大堆和暂停目标再让 JVM 自适应调整年轻代等细节。适用场景常规 Web 服务、微服务、中等到较大堆、既关心吞吐也关心尾延迟的应用。5、ZGC低延迟服务的候选项JDK 21 引入了分代 ZGCZGC 把大部分工作与应用线程并发执行适合大堆或对停顿极其敏感的服务。具体原理使用高版本JDK的同学可以详细了解一下。四、生产配置先做内存预算假设一个容器的内存限制为 4 GiB不要先拍脑袋写-Xmx4g。可以从下面这张预算表开始项目示例预算估算依据Java 堆2.5 GiB业务对象量、分配速率、GC 后存活集元空间与代码缓存350 MiB类数量、动态生成类、JIT 情况直接内存512 MiBNetty/NIO 缓冲池和并发连接数线程相关内存300 MiB线程上限、-Xss、本地线程结构JVM、GC、JNI 及安全余量434 MiBGC 结构、系统库、流量尖峰真正的预算应满足Xmx 可观测的非堆内存峰值 未完全可观测的本地内存 安全余量 容器Memory限制安全余量一般先留 10%20%再根据压测和生产高峰收紧。线程很多、使用 Netty、加载大量类或依赖 JNI 的服务需要留得更多。如何拿到自己的预算数据可以根据下面的命令去获取JVM的内存情况由于命令执行后可能涉及到的比较多的参数信息本章就不做详细分析。后续有时间了会出一期JVM命令参数详解# 查看 JVM 实际识别到的容器资源Linux 容器内执行java -XshowSettings:system -version# 查看运行进程实际参数jcmd -ljcmd pid VM.flagsjcmd pid VM.command_line# 查看堆概况与对象直方图jcmd pid GC.heap_infojcmd pid GC.class_histogram五、上线后要监控什么常见的JVM 内存看板至少应包含以下数据观察项需要关注的现象常见解释堆使用量GC 后基线持续抬升缓存增长、真实负载增长或堆泄漏老年代/长期存活集长时间逼近上限堆太小、并发标记启动太晚或对象留存过多GC 暂停与接口尾延迟同步抬升回收压力、系统调度或安全点问题分配速率短时间陡增大量临时对象、序列化或批量查询晋升速率大量对象过早进入老年代对象生命周期变长或回收跟不上元空间与已加载类数两者持续单调增长动态类或类加载器泄漏线程数持续上涨且不回落线程池失控、任务阻塞或线程泄漏直接内存/进程 RSS堆稳定但 RSS 上涨DirectBuffer、JNI 或本地库分配六、结语JVM 内存管理是没有一组通用的适配任何应用的参数配置但可复用的是参数配置方法先把 Java 堆和进程总内存分开按工作负载做预算再选一个符合延迟目标的收集器用尽量少的参数起步最后靠 GC 日志、JFR文件应用运行期间JFR 持续记录 JVM、Java 应用和操作系统发生的事件和业务指标验证。