1. 先说清楚堆、栈、方法区到底管什么做Java开发的人迟早要面对一次内存相关的线上事故。我印象最深的一次是一个定时任务系统在凌晨三点批量跑数据时突然卡死日志里刷了一堆OutOfMemoryError: Java heap space。当时第一反应是加内存直接把-Xmx从4G调到8G结果第二天又挂了这次变成了GC overhead limit exceeded。后来才意识到单纯加大堆内存解决不了问题得先把堆、栈、方法区这些区域的责任边界搞清楚才知道该动哪个参数。JVM运行时数据区大致可以分成这么几块堆、虚拟机栈、本地方法栈、方法区在JDK 8以后叫元空间、程序计数器。大部分人调内存时只盯着堆但栈溢出、元空间溢出、直接内存泄漏这些坑光调堆根本摸不到。这篇文章我会从每个区域的核心职责讲起再给出实际的参数配置方法和排查思路帮你在遇到内存问题时有章可循。这篇文章适合谁看如果你被线上OOM折磨过或者刚接触JVM调优不知道从哪下手再或者面试时被问到“栈大小怎么配、方法区怎么配”只能答个大概那这篇应该能给你一个完整的操作框架。我会尽量像平时在工位上跟同事讲的那样把每个参数的来龙去脉说透。提示本文讨论的是HotSpot虚拟机默认实现不同虚拟机比如OpenJ9的参数和行为会有差异但思路是通用的。2. 设置内存前必须搞懂的运行时数据区2.1 堆是主角但栈和方法区各有各的命堆是Java对象的主要栖息地。你用new创建出来的对象、数组绝大多数都放在堆里。堆是所有线程共享的所以它天然是垃圾回收的重点区域。堆内部又分成新生代和老年代新生代里还有Eden区和两个Survivor区。调堆大小的核心逻辑就是让对象在新生代多活几轮减少进入老年代的次数同时保证老年代有足够空间容纳长生命周期的对象。虚拟机栈是线程私有的每个线程在自己的栈里维护一个个栈帧。一个方法调用就是一个栈帧栈帧里存了局部变量表、操作数栈、方法返回地址这些信息。每个线程的栈大小是固定的默认值因平台而异通常是1MB如果方法调用层级太深——最常见的就是没有终止条件的递归——栈帧就会把栈空间耗尽抛出StackOverflowError。方法区在JDK 8之前叫永久代JDK 8之后换成了元空间。这里存的是类的元信息、方法字节码、常量池、静态变量这些类级别的东西。元空间的最大特点是它使用本地内存不属于堆所以JVM的堆参数管不到它。但是这不意味着它可以无限增长如果加载的类太多或者反复创建动态代理类元空间同样会撑爆。还有个容易忽略的区域是直接内存它不在JVM管理范围内由NIO的ByteBuffer.allocateDirect()这类操作使用受-XX:MaxDirectMemorySize参数控制。它不像堆那样频繁GC如果程序里大量使用直接内存又不及时释放很容易出现操作系统层面内存被打满但JVM堆统计看起来一切正常的情况。2.2 为什么不能只盯堆大小我见过有人在8G内存的机器上把-Xmx配置成7G结果系统直接卡死。因为JVM可不止堆这一块在占用内存。并发GC时多个GC线程需要额外空间如果再开JIT编译器、JMX监控、远程调试这些功能进程外部还有一堆开销。真实的经验是给JVM的总预算是物理内存的一半到三分之二剩下的留给操作系统和进程内外部的其他内存消耗。举个具体例子一台4C8G的机器上部署一个Spring Boot应用常见配置是java -Xms2g -Xmx2g -Xss512k -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -jar app.jar这里把堆的初始值-Xms和最大值-Xmx设成一样的2G是因为生产环境里堆容量频繁伸缩反而影响性能干脆一次到位。元空间给到512M的上限防止某些加载类比较多的框架把本地内存吃光。线程栈控制在512K对一个线程数可能上千的服务端应用来说能省出不少内存。所以你看真正完整的内存规划是堆、栈、元空间、直接内存、GC开销加起来的总账。下面我会分区域把每个参数的设置逻辑讲清楚。3. 核心参数详解与设置逻辑3.1 堆大小-Xms、-Xmx、-Xmn怎么配合堆的三大参数是-Xms最小堆、-Xmx最大堆、-Xmn新生代大小。-Xms和-Xmx建议直接设成相同值避免堆自动扩容缩容带来的性能抖动。这个抖动最直观的影响是GC变得不规律线上杀个进程或者重启后堆从初始值慢慢爬升到峰值过程中Full GC 频率忽高忽低排查问题难度会加倍。新生代大小-Xmn则要结合YGC发生频率来定。一个合适的起点是堆的1/3到1/2然后根据监控数据调整。比如一个订单处理服务大量请求进来都会创建一批短命对象DTO、临时集合这些对象应该尽量在新生代被回收掉。如果-Xmn太小短命对象还没熬到GC就被晋升到老年代老年代压力变大Full GC频率升高停顿时间变长。还有几个跟堆细分区域相关的参数也别忽略-XX:SurvivorRatio默认8即Eden区是一个Survivor区的8倍。如果YGC后存活对象较多Survivor区装不下多出来的会直接晋升老年代这时候可以适当调大Survivor区比如设成6或4。-XX:MaxTenuringThreshold默认15控制对象熬过多少次YGC后晋升老年代。如果老年代频繁Full GC可以适当降低这个值让对象更早进入老年代以减少YGC的复制成本。不过这里有个权衡晋升越快老年代占用越多。-XX:NewRatio老年代和新生代的比值默认2意味着老年代是新生代的2倍。如果你习惯用这个参数而不是-Xmn二者不要混用以免造成理解混乱。参数配置有先后逻辑吗我自己习惯先从总量出发倒推各个区域的比例先确定物理内存和JVM总预算通常不超过物理内存的70%。设定-Xmx然后在不超过这个上限的前提下设定-Xms生产环境两者相等。再根据对象生命周期分布设定-Xmn配合-XX:SurvivorRatio微调Eden和Survivor的比例。通过GC日志验证效果而不是凭感觉改数值。3.2 栈大小-Xss设置与线程数量权衡-Xss设置的是每个线程的虚拟机栈大小默认在x86平台上是1MB部分平台可能不同。这个参数最典型的应用场景是控制递归深度。假设一个方法每次调用消耗约2KB的栈帧1MB栈大概允许500次左右的递归调用。如果递归深度不够要么优化代码逻辑要么适度调大-Xss比如改成2MB。但是调大-Xss有一个容易被忽略的代价线程栈是线程私有的每个线程都会占据独立的内存块。如果系统创建大量线程比如一个并发较高的网关应用同时开了数千个线程栈大小从512K提升到2MB单是线程栈就可能吃掉几个G的内存。所以当你的应用是“多线程”型而不是“深递归”型参数方向要反过来——把栈调小保证线程数量能撑起来。另外-Xss下面的局部变量表容量并不是定死的它有一个动态扩展机制但这个扩展发生在达到最大异常判断之前本质上还是一个固定上限的竞争。所以遇到StackOverflowError不要急着马上加栈先判断是代码问题还是配置问题。我遇到过的案例里约70%的栈溢出来自递归没有正确退出真正需要调栈大小的反而是少数。部分JDK还提供-XX:ThreadStackSize功能和-Xss类似不同平台单位不同实际开发中用-Xss就把这件事办了不需要两个参数同时设置。3.3 方法区JDK 8后的元空间设置要点方法区在JDK 8之后彻底告别“永久代”的称呼改名为元空间Metaspace。两个最大的变化一是从堆里搬到了本地内存堆参数管不到它了二是默认不再有上限默认只会受操作系统本地可用内存的约束。默认无上限听起来是好事但真实的线上环境里这恰恰是个隐患。动态代理、CGlib增强、Groovy脚本编译甚至是频繁的热部署都会增加元空间的类元数据。如果某个环节有类加载器泄漏元空间会以肉眼可见的速度增长直到操作系统内存耗尽这个过程甚至不一定触发JVM异常可能是直接整机卡死。所以我的建议是除非你有充分理由否则必须设置-XX:MaxMetaspaceSize这是给失控场景兜底用的。常见的初始配置场景初始MetaspaceSizeMaxMetaspaceSize简单Spring Boot应用256m512m微服务框架 CGLib动态代理512m1g大量热部署/脚本引擎1g2g-XX:MetaspaceSize这个参数容易被人误解。它其实不是设置了元空间初始分配大小的下限而是触发Full GC的阈值。当元空间使用量超过这个值JVM会对类元数据作一次清理。你会发现如果这个值设得太低日志里的Full GC频率会异常升高而元空间本身并没有被耗尽。所以调元空间参数除非明确看到OutOfMemoryError: Metaspace否则不需要频繁调整这两个值。3.4 直接内存与堆外内存容易被忽视的第四个区域堆外内存这块我想多提醒一句。NIO、Netty、Kafka这些高性能组件非常依赖直接内存。-XX:MaxDirectMemorySize默认等于堆大小-Xmx如果你没主动设置默认直接内存上限会等于堆最大值。在一些堆内内存比较紧张的场景直接内存却实际上已经超过了合理范围系统整体内存吃紧但你从JVM堆的角度看一切正常。怎么判断直接内存是否异常我的排查经验是看操作系统的进程内存占比和swap使用情况如果物理内存或swap持续走高而GC日志和堆使用都很健康那大概率是直接内存或者JNI地址空间的问题。直接内存的回收依赖Cleaner机制它关联到堆上的Cleaner对象。如果创建DirectBuffer的代码不在合适的时机释放引用垃圾收集器无法触发清理直接内存就会泄漏。Netty这类框架自己做了池化好一些但如果你的代码里手动allocateDirect比较多务必用try-with-resources或者统一的工具类管理生命周期。4. 实操一套典型业务系统的完整配置过程4.1 场景需求回顾假设一个典型的订单处理微服务部署在4核8G的物理机上并发量不算极端但存在明显的峰值早中晚三个饭点时段流量是平日的5倍以上。服务使用Spring Boot MySQL Redis内部有定时任务做对账和报表生成同时引入了一个规则引擎会动态加载一些规则类。参考运行时的现状是高峰期YGC大约每秒5到8次Full GC每天出现几次单次Full GC停顿时间在600到1200ms之间。日志里偶发StackOverflowError来自一个深度递归计算订单折扣树的工具类。整体内存占用在7G左右操作系统已经没有太多富余。目标是让高峰期Full GC消失YGC停顿控制在50ms以内线程栈足够支撑现有的折扣树递归同时给操作系统留出足够的安全余量。4.2 估算每个区域该给多少首先看总量。8G物理内存系统本身和监控Agent至少占1G到1.5G数据库连接池、消息队列客户端、Redis连接在进程外还要消耗一部分这部分再算1G这样留给JVM的合理预算大概在5G到5.5G之间。相比原来的配置主要问题就是堆给了太多旧配置-Xmx5g留给线程栈、元空间和直接内存的空间不足。接下来拆解。堆给3G。从历史监控来看活跃对象峰值在1.8G左右3G堆意味着有一定冗余但不会过多。-Xms3g -Xmx3g避免扩容缩容。新生代通过-Xmn1.5g设定占堆的50%希望更多的短命对象在YGC阶段清理掉。老年代剩1.5G需要监控Full GC情况随时调整。栈原配置-Xss1m递归溢出的原因需要知道折扣树最深约300层每层栈帧估计8KB到12KB1M栈大约是80到120层。这样推算栈不够用的是确定的。把-Xss提到2M可以覆盖400到600层递归同时配合代码层做缓存优化避免未来深度继续增长。元空间规则引擎动态加载类起步给-XX:MetaspaceSize512m上限-XX:MaxMetaspaceSize1g。512m的初始阈值是为了让元空间在成为瓶颈前能顺利扩展1g是为了在泄漏时控制住失控。直接内存业务本身没有重度使用NIORedis和MySQL连接用的都是底层Netty或BIO直接内存压力不算大。显式设置-XX:MaxDirectMemorySize512m顺手把默认上限制住防止意外膨胀。完整参数java -Xms3g -Xmx3g -Xmn1.5g -Xss2m \ -XX:MetaspaceSize512m -XX:MaxMetaspaceSize1g \ -XX:MaxDirectMemorySize512m \ -XX:UseG1GC -XX:MaxGCPauseMillis100 \ -jar order-service.jar4.3 调整后的监控与验证改完参数先别急着上线压测我在实际工作中会跑一轮中低峰期的预热再跑一轮高峰期流量回放。验证重点是三块第一GC日志。启动时加-Xlog:gc*:file/data/logs/gc.log:time,uptime,level:filecount10,filesize50mJDK 11以上观察YGC和Full GC变化。实测下来YGC频率从每秒5到8次降到每秒2到3次单次停顿从20到40ms降到了10到20msFull GC基本消失元空间增长曲线平缓。第二线程栈和递归。写一个轻量级的探针统计折扣树的递归深度和栈余量。调整后最深层级的递归调用不再报StackOverflowError。但要说明一点调用深度这个问题光靠调栈参数是治标不治本长期做法还是把递归改成显式栈迭代。我在这次优化中同时改了代码把深度超过100的路径做了缓存递归深度直接降到了50以下栈压力大幅降低。第三操作系统内存换页情况。用top和vmstat观察调整前高峰期的swap使用在持续增长调整后残余内存从原来的不到1G恢复到约2Gswap不再明显增长。实践中调整内存参数我从来不一次性改完所有值。一次只动一个区域观察至少一个完整的业务日周期。比如这轮先调好堆和元空间稳定两天后再动栈。有些修改表面看似独立实际会造成连锁反应比如新生代变小会让老年代压力变大老年代变大又会让Full GC变慢改一个就得重新审视其他区域的均衡性。5. 常见报错与排查实录5.1 那些天天见的OutOfMemoryError把常见的JVM内存报错整理一下遇到它们的时候心里就有底了报错信息含义首次排查动作Java heap space堆内存耗尽确认-Xmx与实际对象大小dump堆分析GC overhead limit exceededGC回收效果极差98%的时间在GC而回收不到2%的堆优先dump堆判断是否内存泄漏而不是马上加大堆Metaspace元空间耗尽看类加载器数量检查动态生成类的地方StackOverflowError线程栈深度超限查递归和循环调用Direct buffer memory直接内存耗尽查看NIO、Netty的DirectBuffer使用考虑池化特别提醒GC overhead limit exceeded的真正背景是JVM保护机制生效触发条件是GC花费了大量时间但回收效果极差。很多人第一反应是加大堆但如果是泄漏加大堆只是延后了崩溃时间且堆越大Full GC成本越高问题反而更糟。正确动作是配合-XX:HeapDumpOnOutOfMemoryError保留现场再分析泄漏源。5.2 一个元空间泄漏的真实排查过程某次线上服务进程内存持续上涨但堆空间和GC都正常最后发现是元空间在涨。通过jstat -gcmetaspace pid能看到Metaspace usage一路爬升加载的类数量也在异常增长。排查思路如下先查类加载器数量jcmd pid VM.metaspace能看到每个类加载器的元空间使用分布。找到疑似泄漏的类加载器配合jcmd pid GC.class_histogram查看堆中的Class对象数量。用-XX:TraceClassLoading -XX:TraceClassUnloading开启类加载追踪输出大量动态代理类或脚本编译类。定位根源是框架每次创建新的类加载器但未回收还是某个组件不停地生成新动态代理类。这次案例的根源是一个规则引擎在更新规则时创建新的类加载器但旧的类加载器被代码持有引用未释放。优化方案是把规则变更从“重建类加载器”改成“复用类加载器配置热更新”元空间曲线立刻平缓。元空间这块我的真实心得是没有监控就不要改参数。至少先部署一套GC和JVM指标监控Prometheus配合JMX Exporter或者直接上Arthas那类诊断工具再谈调整。否则线上OOM了你还在猜是哪个区域的问题。5.3 栈大小调整的两条边限栈参数的边限比较微妙。太小了递归容易爆太大了线程多了吃不消。以-Xss2m为例2000个线程就是4G内存还没算堆和其他部分8G机器直接就别玩了。所以多线程服务端应用我通常建议-Xss256k到-Xss512k而深递归业务才考虑调到1M以上。线上常见的另一个坑是参数被覆盖。有些应用通过启动脚本传参但又被容器平台或配置中心注入了JVM_OPTS最终生效的可能是某个默认值。这种情况下参数配对了却没有效果排查方式是用启动日志确认CommandLine项或者直接用jcmd pid VM.flags查看运行时生效的值。jcmd pid VM.flags是排查这类问题的有力工具能直接看到所有与默认值不同的标志位。我每次调完参数上线后第一件事就是用它核对一遍实际生效值避免脚本和实际进程两张皮。6. 不同部署环境下的参数策略6.1 容器化部署与物理机部署的差异容器环境里调JVM内存参数有一个特别提醒的点JDK 8u191之后的版本支持-XX:UseContainerSupport部分发行版默认开启能够识别容器设置的内存限制。但如果你的容器没开这个支持JVM按物理机内存来算默认值可能出现容器限制4G、JVM默认堆却按物理机总内存的1/4算出来的情况导致进程被杀。在容器里我推荐的实践是显式设置参数不依赖JVM默认值。比如容器限4G堆给2G元空间给512M栈给512K直接内存给512M算上GC和线程开销总共大概3.3G留出一部分余量给操作系统和监控组件。物理机部署时则可以稍微激进一点。机器独占时JVM预算可以放到物理内存的60%到70%剩下的留给操作系统和运维工具。但如果是混部环境多个应用在同一台机器上跑不要每个应用都把内存预算打满要看整体水位。混部场景建议以容器或cgroup限流为基础再分别设定JVM参数不然一到高峰就是一场资源争抢的灾难。6.2 不同规模应用的基础配置模板整理了几套常见的起步配置覆盖小型工具、中等服务、大内存应用三类场景。这类模板的价值在于给你一个安全起点实际数值要根据监控调整小型工具类应用单个Jar包低并发1G以下内存java -Xms256m -Xmx512m -Xss256k \ -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m \ -XX:MaxDirectMemorySize128m -jar tool.jar中等服务类应用Spring Boot微服务4C8G机器java -Xms3g -Xmx3g -Xmn1.5g -Xss512k \ -XX:MetaspaceSize512m -XX:MaxMetaspaceSize1g \ -XX:MaxDirectMemorySize512m \ -XX:UseG1GC -XX:MaxGCPauseMillis100 \ -jar service.jar大内存处理应用数据计算、OLAP类16G以上堆java -Xms8g -Xmx8g -Xmn4g -Xss1m \ -XX:MetaspaceSize1g -XX:MaxMetaspaceSize2g \ -XX:MaxDirectMemorySize1g \ -XX:UseG1GC -XX:MaxGCPauseMillis200 \ -XX:SurvivorRatio6 -jar bigdata-task.jar第三套配置里把-Xmn提到了4G是考虑到数据分析任务会频繁创建中间结果对象而且对象存活周期偏长足够大的新生代有助于提升YGC效率。SurvivorRatio6是为了给存活对象更多的缓冲空间减少早期晋升到老年代的量。7. 最后说几句调参的体会做了这么多年的JVM调优我的真实感受是内存参数设置这件事看起来是“改几个数字”实际考验的是你对业务模型的理解。线上应用的核心问题不是“内存参数越大越好”而是“每个区域各司其职谁都不该成为短板”。一次只改一个参数改完了留足观察期是这套方法论里最重要的一条铁律。有些人喜欢一次性把堆、栈、元空间全改了结果出了性能回退根本说不清是哪个参数引起的。我自己踩过这个坑后养成了习惯调整任何参数前先用jcmd或启动日志记录当前生效值调整后至少观察一个完整的业务周期高低峰都经历一遍再下结论。如果你刚接触JVM内存配置我建议从这一步开始把你现有服务上关于内存的启动参数列成表格然后对照今天的监控数据逐项检查。哪个区域频繁报警就先解决哪个区不要为了调优而调优。技术资料的文档到处都是但什么时候该调、调到多少不再变了这才是真正值钱的判断力。另外一个实用的小技巧所有和内存相关的异常日志尽量让进程自动保留现场。启动参数里固定带上-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath/data/dumps。这样下次线上出问题至少有现场材料可查不用等到重启后再拍脑袋猜原因。很多OOM问题之所以解决不了不是因为问题复杂而是因为现场没了一切都无从谈起。