先把结论放在最前面JVM 内存模型这玩意儿说难不难说简单也不简单。市面上讲它的文章一抓一大把但大部分都停留在“堆存对象、栈存引用、方法区存类信息”这种背答案的层面。我这些年排查线上事故、处理面试问题、优化服务GC回头再看这块知识发现真正值钱的不是记住三个区域的名字而是搞清楚它们为什么这么划分、相互之间怎么协作、出问题的时候怎么根据现象反推原因。这篇文章我不想给你念PPT就按我实际理解和实战排查的顺序来聊。不管你是刚接触Java的新手还是写了几年业务代码但没深入看过内存的家伙又或者是被OOM逼得睡不着的运维和开发照着这篇文章的思路走一遍你至少能建立起一套自己的内存分析框架。下次再有人问你“堆、栈、方法区有什么区别”你不光能答上来还能顺手讲明白一个对象从创建到回收的完整一生。1. 先说结论JVM内存模型到底在解决什么问题1.1 内存模型不是“八股文”它决定了你的程序死法很多人觉得内存模型就是面试八股背完就忘。但我这些年处理过太多生产事故几乎每一个Java进程的“死法”都能追溯到内存模型的某个区域上。举个例子你线上服务突然卡死GC日志里全是Full GCCPU飙到100%那问题八成出在堆上——要么对象太多回收不过来要么有对象一直被人引用着清不掉。再比如你写了个递归没有出口程序直接抛出StackOverflowError这是栈出了问题。又比如你用CGLIB疯狂生成代理类结果抛了OutOfMemoryError: Metaspace那罪魁祸首就是方法区准确说是元空间。所以我一直有个观点内存模型是JVM所有运行时行为的底层逻辑你看到的每一个“诡异报错”背后都对应着某个区域的容量耗尽或协作失衡。那JVM为什么要划分这么多区域很简单因为不同的数据有不同的生命周期。有的数据是全局的比如类的元信息程序跑多久它就活多久有的数据是临时的比如方法里的局部变量方法一结束就没什么用了有的数据是共享的比如创建出来的对象多个线程都要访问有的数据是线程私有的比如调用栈别的线程碰都不能碰。把这些不同生命周期的数据全塞在一个大数组里不是不能跑但回收效率、并发控制、权限隔离都会变得一塌糊涂。JVM按照“共享与私有”和“生命周期长短”这两个维度把内存切成了不同的区域每个区域用不同的策略管理这才是内存模型存在的真正意义。1.2 三个区域一句话说清再逐步深入堆Heap所有线程共享的一块大内存用来存放new出来的对象实例。它是GC垃圾回收的主战场也是OOM出现频率最高的地方。栈Stack准确说是Java虚拟机栈线程私有的内存空间每个方法调用都会创建一个“栈帧”里面存放局部变量、中间计算结果、方法调用信息。栈的生命周期跟随线程线程结束栈就释放。方法区Method Area也是所有线程共享的用来存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存。在JDK 8之后它的实现换成了“元空间Metaspace”。一句话概括就是对象在堆里出生方法在栈里执行类信息在方法区里常住。听起来挺清晰但实际运行时的协作远比这复杂下面我分别展开。2. 堆Heap对象的老家也是OOM的重灾区2.1 堆的分代设计新生代、老年代到底怎么分堆并不只是一块单纯的大内存JVM默认把它分成新生代Young Generation和老年代Old Generation两个部分比例大约是1:2。新生代里面又细分为Eden区、From Survivor区S0、To Survivor区S1默认比例是8:1:1。为什么要搞这么复杂因为绝大多数对象都是“朝生夕死”的。比如你在一个方法里new了一个临时对象用于拼接字符串方法一结束这个对象就没用了。如果JVM每次回收都要扫描整个堆那效率会低到没法看。所以JVM对新生代采用复制算法回收的时候只处理Eden和一块Survivor把存活的对象复制到另一块Survivor一次性清空剩下的区域。这种设计让Minor GC新生代GC非常快STWStop The World暂停所有工作线程时间通常在几毫秒到几十毫秒。老年代则相反里面放的是经历过多次GC仍然存活的对象这类对象生命周期长一般不会轻易被回收。JVM对老年代采用标记-整理算法或者CMS/G1的标记-清除/混合回收策略避免频繁移动大对象带来的性能损耗。老年代的GCMajor GC / Full GC往往耗时较长触发时通常会伴随全局STW这也是为什么Full GC是性能杀手。我见过不少同学一上来就想调堆大小其实不了解分代结构调参就是瞎调。举个例子你把-Xmx调得很大但新生代太小导致大量短命对象直接晋升到老年代老年代很快被打满频繁Full GC反而更慢。所以看堆内存问题先看分代比例是否合理再谈总大小。2.2 对象分配与晋升机制从Eden到老年代的一生一个普通对象的“人生轨迹”大致是这样的对象创建时优先分配在新生代的Eden区。如果Eden区空间不足JVM会触发一次Minor GC。Minor GC之后存活下来的对象会被复制到To Survivor区同时对象年龄加1对象头里有年龄字段。每熬过一次Minor GC对象年龄加1。当年龄达到阈值默认15就会晋升到老年代。如果To Survivor区放不下存活对象多出来的对象会通过分配担保Handle Promotion机制直接进入老年代不排队等待年龄累积。大对象比如很大的数组、字符串会直接进入老年代。JVM有个参数-XX:PretenureSizeThreshold超过这个大小的对象直接在老年代分配避免在新生代反复复制。这里有个非常容易踩的坑Survivor区被填满后对象会被“提前晋升”。如果非正常晋升的对象太多老年代压力就会变大GC频率上升。排查时可以用jstat -gcutil pid看FGCFull GC次数和老年代占比如果FGC频繁且老年代居高不下先别急着加内存用jmap -histo:live pid看看究竟是哪些对象占据了空间。另外我记得在一次性能压测里发现大量byte[]被频繁创建又释放Eden区被打满Survivor根本接不住最终全都提前晋升到老年代老年代GC一次要停顿四五秒。后来通过调整Survivor空间比例、优化代码里大数组的复用逻辑才把性能拉回来。这种事靠“加堆内存”是解决不了的。2.3 堆参数配置与“堆调到8000还是OOM”的排查思路很多人一看到OutOfMemoryError: Java heap space第一反应就是把-Xmx调大。这个思路不能说错但很片面。我说句实话热搜词里那个“进程堆大小调整为8000还是报错java.lang.OutOfMemoryError”的情况我至少遇到过十几次。原因嘛基本逃不出这几类堆外内存耗尽NIO、Netty这类框架大量使用堆外内存直接内存堆设得再大也没用直接内存被打满了同样OOM。元空间溢出动态生成类CGLIB、反射、热部署导致Metaspace爆炸报错信息里会写Metaspace而不是Java heap space。线程创建过多每个线程默认占用1MB左右的栈内存线程数一多进程地址空间被吃光即使堆没满也可能报OOM。IDEA编译时OOM注意热词里提到“idea 编译时”和“编译器的堆空间不足”这其实是IDEA构建进程Gradle/Maven编译进程的堆内存不足跟运行时的JVM堆是两码事。要在IDEA的Build Tools设置里把Shared build process heap size调大或者改gradle.properties里的org.gradle.jvmargs。Swap空间不足物理内存不够操作系统开始疯狂换页JVM本身没报堆错误但进程响应极慢极容易被误判为OOM。所以正确的排查姿势是这样的先看异常信息到底报的是哪块空间是Java heap space、Metaspace还是Direct buffer memory。用jstat -gcutil观察GC频率和各代占比判断是内存泄漏还是内存不足。用jmap -dump:formatb,fileheap.hprof导出堆快照用MAT或JProfiler分析大对象和引用链。结合top命令看进程实际内存占用如果比-Xmx大出很多恭喜你大概率有堆外内存参与。说个我自己的经验有次线上服务报OOM-Xmx已经调到6G还是隔三差五挂一次。后来通过top发现进程实际占用内存高达9G远超堆大小。再借助pmap看了一下地址空间分布定位到是项目里一个MQ客户端设置了过大的DirectByteBuffer缓冲。把堆外内存上限用-XX:MaxDirectMemorySize限制住同时调低缓冲大小问题才彻底消失。3. 栈Stack线程的私人空间函数的快递柜3.1 栈帧结构局部变量表、操作数栈、动态链接栈这东西很多人理解成“方法执行的地方”没什么大毛病。但要深入一点你就得知道每个方法在执行时都会在栈里创建一个“栈帧Stack Frame”里面装了以下几样东西局部变量表Local Variables存放方法参数和内部定义的局部变量。注意它存的是基本类型的值和引用类型的引用指针对象本身还是躺在堆里。操作数栈Operand Stack临时存放计算过程中的中间结果。比如执行a b就是把a和b压入操作数栈计算完再弹出结果。动态链接Dynamic Linking指向运行时常量池中该方法的引用用来支持方法调用时的动态解析。方法出口Return Address方法正常返回或异常抛出后需要回到调用方的哪个位置继续执行。我常用一个生活中的类比来解释栈帧栈就像一摞快递托盘每个方法调用就是往里放一个托盘托盘里放着你这个方法的“工作便签”。这个托盘一用完立刻撤走空间立刻释放不需要垃圾回收器操心。这也是为什么栈比堆高效得多——它只需要移动一个指针就能完成分配和释放。每个线程都有自己的栈栈的大小可以用-Xss参数设置默认一般是1MB左右不同平台有差异。栈不需要像堆那样做GC因为栈帧出栈即释放。3.2 压栈与退栈函数调用生命周期从main到最深递归我们来实际走一遍函数调用的栈变化过程。假设有这样一个简单的代码public class StackDemo { public static void main(String[] args) { int sum add(3, 5); System.out.println(sum); } private static int add(int a, int b) { int result a b; return result; } }执行过程是这样的JVM启动后创建main线程为main栈帧分配空间把args引用、后续要用的局部变量表、操作数栈都准备好。main方法执行到add(3, 5)这句时JVM为add方法创建一个新的栈帧压入栈顶。此时栈中有两个栈帧main栈帧在底部add栈帧在顶部。add方法的栈帧里局部变量表存放a3、b5操作数栈执行a b结果result8。add方法执行完毕返回值被复制到main栈帧的操作数栈中add栈帧整体出栈销毁。main继续执行System.out.println(sum)利用栈帧中的局部变量sum完成调用。如果add方法里又调用了另一个方法那这个新的栈帧又会压到栈顶。越是后调用的方法栈帧位置越靠上执行完越先出栈。这就是“后进先出”的由来。理解了压栈和退栈你就很容易理解StackOverflowError是怎么来的方法调用层数太多栈帧一层套一层把栈空间占满了。最常见的原因就是递归没有出口比如public void foo() { foo(); }这个调用会无限往栈里压栈帧直到栈容量耗尽JVM抛出java.lang.StackOverflowError。3.3 栈常见问题StackOverflowError与-Xss调优关于-Xss参数我得泼盆冷水不要轻易把它调大尤其不要为了“以防万一”调到8MB甚至更高。原因很简单栈是线程私有的每个线程都要单独占一份。你调大了单线程栈大小意味着相同内存下能创建的线程数就变少了。线程数不足在高并发场景下会产生大量线程切换等待服务吞吐量反而下降。我之前遇到过一个真实案例某网关服务并发一高就报java.lang.OutOfMemoryError: unable to create new native thread。运维说内存明明还很充裕啊怎么创建不了线程后来一查这个服务的-Xss被调到了8MB1000个线程就吃掉近8GB的虚拟内存而进程的地址空间和物理内存都撑不住了。把-Xss调回1MB同时压住业务线程池的线程数上限问题直接解决。那什么时候才需要调栈大小如果你的业务确实需要极深的递归调用比如深度优先搜索算法可以适度把-Xss调到2MB~4MB试试。但更推荐的做法是把递归改成迭代从根上避免栈溢出。栈存在的意义是支撑函数调用而不是让你无限递归。设计代码的时候心里要有这根弦方法调用深度大了栈是会被填满的。顺带提一嘴“backtrace栈回溯”这个词。线上排查栈溢出、死锁、线程卡死时常用的命令就是jstack pid导出线程快照看线程的栈帧回溯信息。它能告诉你每个线程当前执行到哪一行代码、在等待什么锁。配合栈的知识你能快速定位到“哪个方法调了哪个方法卡在哪个同步块”。4. 方法区Method Area类信息的档案馆与它的变身记4.1 从永久代到元空间方法区的演进原因方法区这个概念比较绕因为不同JDK版本下的实现完全不一样。JDK 7及以前方法区的实现叫永久代PermGenJDK 8开始永久代被移除方法区的实现改成了元空间Metaspace。为什么要做这个改变根本原因是永久代把方法区限制在了JVM堆内存内部有大小上限默认几十MB到一百多MB而且还经常被调优误伤——很多人把堆调大了却忘了永久代也会溢出结果动态加载大量类时直接OutOfMemoryError: PermGen space。元空间最大的变化是它不再使用JVM堆内存而是直接使用本地内存Native Memory。理论上只要操作系统物理内存够大元空间就能一直增长不再受-XX:MaxPermSize限制。JDK 8里你再也见不到PermGen space报错了堆是堆元空间是元空间两者不共用空间。方法区里到底放什么东西简单说就是类的元信息类名、访问修饰符、字段描述、方法描述、运行时常量池、静态变量、即时编译器编译后的代码缓存CodeCache。你用CGLIB生成代理类、用反射解析类、用Spring加载Bean定义都会往元空间里塞数据。4.2 运行时常量池与字符串常量池类加载后发生了什么方法区/元空间里有个重要结构叫运行时常量池Runtime Constant Pool。每个类在被加载时class文件里的常量池字面量、符号引用会被解析到这个区域。举个最常见的例子字符串常量池String Table在JDK 7之后就移到了堆里但字符串字面量最初的解析和驻留机制仍然和运行时常量池密切相关。当你写String s hello;JVM会先在字符串常量池里找有没有“hello”这个字符串对象有就直接复用没有就在堆里创建并放入常量池。而你写new String(hello)时JVM仍然会确保常量池里有“hello”但会在堆里额外创建一个新的对象。这个机制导致了一个经典面试陷阱hello new String(hello)返回false但hello.equals(new String(hello))返回true。原因就在于一个引用指向常量池对象另一个指向堆里的新对象。我见过不少线上内存泄漏的案例源头就是字符串被无脑intern。比如某些同学从网上抄了一段代码把每个UUID、每次日志拼接的结果都intern一下以为能省内存结果字符串常量池被塞得满满当当堆里的字符串对象数量爆表。字符串常量池本质上是一个HashTable驻留大量字符串会拖慢整个JVM的字符串操作。这玩意儿不是这么用的千万别瞎开。4.3 元空间配置与常见异常元空间虽然默认不限大小只受物理内存限制但生产环境一定要设置上限否则一旦发生类加载泄漏你连救的机会都没有。常用参数-XX:MetaspaceSize元空间初始大小触发扩容的阈值。-XX:MaxMetaspaceSize元空间最大大小超过它会报OutOfMemoryError: Metaspace。-XX:MaxDirectMemorySize堆外直接内存上限默认等于-Xmx。为什么说元空间OOM比堆OOM更麻烦因为类加载器泄漏很难排查。最常见的情景是应用频繁热部署、每次动态生成新的类加载器、但旧的类加载器没有被释放于是它们加载过的类元信息一直堆积在元空间里。普通的堆快照分析工具很难直接看出元空间被谁占了直到MaxMetaspaceSize触发服务挂掉。我踩过一次很深的坑项目用了某个老版本的基础框架里面每次调用都会动态生成一个代理类生产环境跑两三天Metaspace就被打满。最后是靠开启-XX:TraceClassLoading和-XX:TraceClassUnloading把类加载日志导出来才定位到具体的类生成点。所以我的建议是动态生成类的框架一定要加类加载日志别等服务挂了再盲猜。5. 三个区域怎么联动一次方法调用的完整内存旅程5.1 从javac编译到第一条字节码指令前面分了三个区域来讲但实际运行时它们是高度联动的。我以一段代码为例完整走一遍public class Demo { private static String TAG demo; public static void main(String[] args) { User user new User(); user.setName(张三); String tag TAG user.getName(); System.out.println(tag); } }类加载阶段JVM读取Demo.class文件把类元信息放入元空间方法区的实现TAG这个静态字符串变量也随类加载放入常量池/堆的字符串常量池区域。栈帧创建main线程启动创建main栈帧args引用存入局部变量表。对象分配执行new User()时JVM在堆的Eden区分配User对象内存栈帧局部变量表里的user引用指向这块堆内存。字符串拼接TAG user.getName()会创建一个新的StringBuilder对象也在堆里拼接完成后结果对象被放入堆栈帧局部变量表里的tag引用指向它。方法调用执行System.out.println(tag)时新栈帧压栈println方法的局部变量表接收到tag引用。退栈与GCmain方法执行完main栈帧出栈局部变量表里的引用消失。如果这个过程中触发了Minor GCEden区里那些没有外部引用的临时对象就会被回收user对象如果还活着可能移动到Survivor区继续熬年龄。这整个过程里栈负责“指挥”堆负责“存货”方法区负责“提供剧本类元信息”。三个区域缺一不可配合默契。5.2 堆外内存容易被忽略的“第四空间”堆外内存严格来说不属于前面的三个区域但它和JVM内存调优关系极其密切尤其是现在微服务架构下大量使用Netty、Kafka等NIO框架。堆外内存堆外直接内存是JVM通过DirectByteBuffer从操作系统直接分配的内存不走堆。这样做的好处是避免IO操作时数据在堆内和堆外之间来回拷贝读写性能更好。坏处是它不归GC管回收依赖Cleaner机制如果创建了太多DirectByteBuffer而不释放堆外内存就会悄悄打满然后报OutOfMemoryError: Direct buffer memory。排查堆外内存问题比堆内难得多因为常规的jmap导出堆快照根本看不到直接内存。我一般用这几种手段top看进程实际内存占用如果明显大于-Xmx优先怀疑堆外内存。pmap pid | grep anon看匿名内存映射找有没有异常大的内存块。用Java NMTNative Memory Tracking加上-XX:NativeMemoryTrackingsummary再通过jcmd pid VM.native_memory summary查看各区域内存占用明细。检查代码里所有ByteBuffer.allocateDirect的地方确认是否都正确释放了。我再强调一遍调优JVM内存不要只盯着堆。生产环境出OOM堆外内存导致的比例比我预想的高得多尤其是那些重度使用Netty、RocketMQ、Kafka的服务。6. 常见误区与调优经验清单6.1 必须避开的那些坑误区真实情况堆越大性能越好堆过大会导致GC时间变长不利于低延迟场景OOM就调大堆可能是元空间、堆外内存、线程栈、物理内存问题栈溢出就调大-Xss可能引发线程内存剧增高并发下更容易崩溃JDK 8里没有永久代就没有类溢出风险元空间同样可能溢出且更隐蔽方法区就是堆的一部分JDK 8后元空间使用本地内存与堆完全隔离字符串intern能省内存滥用intern会撑爆字符串常量池适得其反只要堆里对象没被引用就会被立刻回收对象要等GC触发才会被回收且分代不同回收时机不同这张表里的每一条都是我亲手踩过或者帮别人排查过的坑。尤其是“堆越大越好”这条我之前优化过一个小程序接口原本-Xmx4GFull GC一次要1.2秒接口时不时卡死。后来把堆降到2G换用G1垃圾回收器并显式设置-XX:MaxGCPauseMillis100Full GC基本消失了接口稳定返回。大堆并不等于好堆垃圾回收器的选择和分区比例往往更关键。6.2 一套实用的排查起点配置如果你要对一个Java服务做内存调优我建议从这套参数起步然后根据监控结果微调java -Xms2g -Xmx2g \ -XX:MetaspaceSize256m \ -XX:MaxMetaspaceSize512m \ -XX:MaxDirectMemorySize1g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/heapdump.hprof \ -Xloggc:/data/logs/gc.log \ -XX:PrintGCDetails我解释一下我的思路-Xms和-Xmx设成一样避免运行期频繁扩容和缩容带来的性能抖动元空间设上限防止类加载器泄漏拖垮整机HeapDumpOnOutOfMemoryError和gc.log是排查事故的“黑匣子”必须开别等到出事才后悔日志没打全。G1是目前JDK 8的主流选择它能比较平滑地控制GC停顿。6.3 最后分享一个我压箱底的经验我不敢说自己把JVM所有细节都吃透了但这些年下来有个体会内存模型的知识只有用在排查现场才算真正学会。只背概念记参数下一次遇到线上OOM你还是会慌。不如先从一个小程序开始故意写一段内存泄漏代码把堆dump出来玩一遍或者设置一个巨小的堆比如-Xmx64m跑Spring Boot应用亲眼看看它怎么一步步撑死、怎么报错。亲手复现几次问题之后你对堆、栈、方法区的理解会比看一百篇文章都深。如果你看完这篇文章只记住一句话我希望是这句内存模型不是一个静态的结构图而是一套动态的协作机制——对象在堆里出生栈帧随方法调用生灭类信息在元空间常驻任何一块区域失衡整个应用都会跟着遭殃。下次再遇到内存相关的毛病先定位区域再分析原因最后动参数。顺着这个节奏走大多数问题你都能稳稳接住。 
长河君 · 2026/10/8 9:32:25 · 阅读 1.2k 深入解析JVM内存模型：堆、栈、方法区实战调优
先把结论放在最前面JVM 内存模型这玩意儿说难不难说简单也不简单。市面上讲它的文章一抓一大把但大部分都停留在“堆存对象、栈存引用、方法区存类信息”这种背答案的层面。我这些年排查线上事故、处理面试问题、优化服务GC回头再看这块知识发现真正值钱的不是记住三个区域的名字而是搞清楚它们为什么这么划分、相互之间怎么协作、出问题的时候怎么根据现象反推原因。这篇文章我不想给你念PPT就按我实际理解和实战排查的顺序来聊。不管你是刚接触Java的新手还是写了几年业务代码但没深入看过内存的家伙又或者是被OOM逼得睡不着的运维和开发照着这篇文章的思路走一遍你至少能建立起一套自己的内存分析框架。下次再有人问你“堆、栈、方法区有什么区别”你不光能答上来还能顺手讲明白一个对象从创建到回收的完整一生。1. 先说结论JVM内存模型到底在解决什么问题1.1 内存模型不是“八股文”它决定了你的程序死法很多人觉得内存模型就是面试八股背完就忘。但我这些年处理过太多生产事故几乎每一个Java进程的“死法”都能追溯到内存模型的某个区域上。举个例子你线上服务突然卡死GC日志里全是Full GCCPU飙到100%那问题八成出在堆上——要么对象太多回收不过来要么有对象一直被人引用着清不掉。再比如你写了个递归没有出口程序直接抛出StackOverflowError这是栈出了问题。又比如你用CGLIB疯狂生成代理类结果抛了OutOfMemoryError: Metaspace那罪魁祸首就是方法区准确说是元空间。所以我一直有个观点内存模型是JVM所有运行时行为的底层逻辑你看到的每一个“诡异报错”背后都对应着某个区域的容量耗尽或协作失衡。那JVM为什么要划分这么多区域很简单因为不同的数据有不同的生命周期。有的数据是全局的比如类的元信息程序跑多久它就活多久有的数据是临时的比如方法里的局部变量方法一结束就没什么用了有的数据是共享的比如创建出来的对象多个线程都要访问有的数据是线程私有的比如调用栈别的线程碰都不能碰。把这些不同生命周期的数据全塞在一个大数组里不是不能跑但回收效率、并发控制、权限隔离都会变得一塌糊涂。JVM按照“共享与私有”和“生命周期长短”这两个维度把内存切成了不同的区域每个区域用不同的策略管理这才是内存模型存在的真正意义。1.2 三个区域一句话说清再逐步深入堆Heap所有线程共享的一块大内存用来存放new出来的对象实例。它是GC垃圾回收的主战场也是OOM出现频率最高的地方。栈Stack准确说是Java虚拟机栈线程私有的内存空间每个方法调用都会创建一个“栈帧”里面存放局部变量、中间计算结果、方法调用信息。栈的生命周期跟随线程线程结束栈就释放。方法区Method Area也是所有线程共享的用来存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存。在JDK 8之后它的实现换成了“元空间Metaspace”。一句话概括就是对象在堆里出生方法在栈里执行类信息在方法区里常住。听起来挺清晰但实际运行时的协作远比这复杂下面我分别展开。2. 堆Heap对象的老家也是OOM的重灾区2.1 堆的分代设计新生代、老年代到底怎么分堆并不只是一块单纯的大内存JVM默认把它分成新生代Young Generation和老年代Old Generation两个部分比例大约是1:2。新生代里面又细分为Eden区、From Survivor区S0、To Survivor区S1默认比例是8:1:1。为什么要搞这么复杂因为绝大多数对象都是“朝生夕死”的。比如你在一个方法里new了一个临时对象用于拼接字符串方法一结束这个对象就没用了。如果JVM每次回收都要扫描整个堆那效率会低到没法看。所以JVM对新生代采用复制算法回收的时候只处理Eden和一块Survivor把存活的对象复制到另一块Survivor一次性清空剩下的区域。这种设计让Minor GC新生代GC非常快STWStop The World暂停所有工作线程时间通常在几毫秒到几十毫秒。老年代则相反里面放的是经历过多次GC仍然存活的对象这类对象生命周期长一般不会轻易被回收。JVM对老年代采用标记-整理算法或者CMS/G1的标记-清除/混合回收策略避免频繁移动大对象带来的性能损耗。老年代的GCMajor GC / Full GC往往耗时较长触发时通常会伴随全局STW这也是为什么Full GC是性能杀手。我见过不少同学一上来就想调堆大小其实不了解分代结构调参就是瞎调。举个例子你把-Xmx调得很大但新生代太小导致大量短命对象直接晋升到老年代老年代很快被打满频繁Full GC反而更慢。所以看堆内存问题先看分代比例是否合理再谈总大小。2.2 对象分配与晋升机制从Eden到老年代的一生一个普通对象的“人生轨迹”大致是这样的对象创建时优先分配在新生代的Eden区。如果Eden区空间不足JVM会触发一次Minor GC。Minor GC之后存活下来的对象会被复制到To Survivor区同时对象年龄加1对象头里有年龄字段。每熬过一次Minor GC对象年龄加1。当年龄达到阈值默认15就会晋升到老年代。如果To Survivor区放不下存活对象多出来的对象会通过分配担保Handle Promotion机制直接进入老年代不排队等待年龄累积。大对象比如很大的数组、字符串会直接进入老年代。JVM有个参数-XX:PretenureSizeThreshold超过这个大小的对象直接在老年代分配避免在新生代反复复制。这里有个非常容易踩的坑Survivor区被填满后对象会被“提前晋升”。如果非正常晋升的对象太多老年代压力就会变大GC频率上升。排查时可以用jstat -gcutil pid看FGCFull GC次数和老年代占比如果FGC频繁且老年代居高不下先别急着加内存用jmap -histo:live pid看看究竟是哪些对象占据了空间。另外我记得在一次性能压测里发现大量byte[]被频繁创建又释放Eden区被打满Survivor根本接不住最终全都提前晋升到老年代老年代GC一次要停顿四五秒。后来通过调整Survivor空间比例、优化代码里大数组的复用逻辑才把性能拉回来。这种事靠“加堆内存”是解决不了的。2.3 堆参数配置与“堆调到8000还是OOM”的排查思路很多人一看到OutOfMemoryError: Java heap space第一反应就是把-Xmx调大。这个思路不能说错但很片面。我说句实话热搜词里那个“进程堆大小调整为8000还是报错java.lang.OutOfMemoryError”的情况我至少遇到过十几次。原因嘛基本逃不出这几类堆外内存耗尽NIO、Netty这类框架大量使用堆外内存直接内存堆设得再大也没用直接内存被打满了同样OOM。元空间溢出动态生成类CGLIB、反射、热部署导致Metaspace爆炸报错信息里会写Metaspace而不是Java heap space。线程创建过多每个线程默认占用1MB左右的栈内存线程数一多进程地址空间被吃光即使堆没满也可能报OOM。IDEA编译时OOM注意热词里提到“idea 编译时”和“编译器的堆空间不足”这其实是IDEA构建进程Gradle/Maven编译进程的堆内存不足跟运行时的JVM堆是两码事。要在IDEA的Build Tools设置里把Shared build process heap size调大或者改gradle.properties里的org.gradle.jvmargs。Swap空间不足物理内存不够操作系统开始疯狂换页JVM本身没报堆错误但进程响应极慢极容易被误判为OOM。所以正确的排查姿势是这样的先看异常信息到底报的是哪块空间是Java heap space、Metaspace还是Direct buffer memory。用jstat -gcutil观察GC频率和各代占比判断是内存泄漏还是内存不足。用jmap -dump:formatb,fileheap.hprof导出堆快照用MAT或JProfiler分析大对象和引用链。结合top命令看进程实际内存占用如果比-Xmx大出很多恭喜你大概率有堆外内存参与。说个我自己的经验有次线上服务报OOM-Xmx已经调到6G还是隔三差五挂一次。后来通过top发现进程实际占用内存高达9G远超堆大小。再借助pmap看了一下地址空间分布定位到是项目里一个MQ客户端设置了过大的DirectByteBuffer缓冲。把堆外内存上限用-XX:MaxDirectMemorySize限制住同时调低缓冲大小问题才彻底消失。3. 栈Stack线程的私人空间函数的快递柜3.1 栈帧结构局部变量表、操作数栈、动态链接栈这东西很多人理解成“方法执行的地方”没什么大毛病。但要深入一点你就得知道每个方法在执行时都会在栈里创建一个“栈帧Stack Frame”里面装了以下几样东西局部变量表Local Variables存放方法参数和内部定义的局部变量。注意它存的是基本类型的值和引用类型的引用指针对象本身还是躺在堆里。操作数栈Operand Stack临时存放计算过程中的中间结果。比如执行a b就是把a和b压入操作数栈计算完再弹出结果。动态链接Dynamic Linking指向运行时常量池中该方法的引用用来支持方法调用时的动态解析。方法出口Return Address方法正常返回或异常抛出后需要回到调用方的哪个位置继续执行。我常用一个生活中的类比来解释栈帧栈就像一摞快递托盘每个方法调用就是往里放一个托盘托盘里放着你这个方法的“工作便签”。这个托盘一用完立刻撤走空间立刻释放不需要垃圾回收器操心。这也是为什么栈比堆高效得多——它只需要移动一个指针就能完成分配和释放。每个线程都有自己的栈栈的大小可以用-Xss参数设置默认一般是1MB左右不同平台有差异。栈不需要像堆那样做GC因为栈帧出栈即释放。3.2 压栈与退栈函数调用生命周期从main到最深递归我们来实际走一遍函数调用的栈变化过程。假设有这样一个简单的代码public class StackDemo { public static void main(String[] args) { int sum add(3, 5); System.out.println(sum); } private static int add(int a, int b) { int result a b; return result; } }执行过程是这样的JVM启动后创建main线程为main栈帧分配空间把args引用、后续要用的局部变量表、操作数栈都准备好。main方法执行到add(3, 5)这句时JVM为add方法创建一个新的栈帧压入栈顶。此时栈中有两个栈帧main栈帧在底部add栈帧在顶部。add方法的栈帧里局部变量表存放a3、b5操作数栈执行a b结果result8。add方法执行完毕返回值被复制到main栈帧的操作数栈中add栈帧整体出栈销毁。main继续执行System.out.println(sum)利用栈帧中的局部变量sum完成调用。如果add方法里又调用了另一个方法那这个新的栈帧又会压到栈顶。越是后调用的方法栈帧位置越靠上执行完越先出栈。这就是“后进先出”的由来。理解了压栈和退栈你就很容易理解StackOverflowError是怎么来的方法调用层数太多栈帧一层套一层把栈空间占满了。最常见的原因就是递归没有出口比如public void foo() { foo(); }这个调用会无限往栈里压栈帧直到栈容量耗尽JVM抛出java.lang.StackOverflowError。3.3 栈常见问题StackOverflowError与-Xss调优关于-Xss参数我得泼盆冷水不要轻易把它调大尤其不要为了“以防万一”调到8MB甚至更高。原因很简单栈是线程私有的每个线程都要单独占一份。你调大了单线程栈大小意味着相同内存下能创建的线程数就变少了。线程数不足在高并发场景下会产生大量线程切换等待服务吞吐量反而下降。我之前遇到过一个真实案例某网关服务并发一高就报java.lang.OutOfMemoryError: unable to create new native thread。运维说内存明明还很充裕啊怎么创建不了线程后来一查这个服务的-Xss被调到了8MB1000个线程就吃掉近8GB的虚拟内存而进程的地址空间和物理内存都撑不住了。把-Xss调回1MB同时压住业务线程池的线程数上限问题直接解决。那什么时候才需要调栈大小如果你的业务确实需要极深的递归调用比如深度优先搜索算法可以适度把-Xss调到2MB~4MB试试。但更推荐的做法是把递归改成迭代从根上避免栈溢出。栈存在的意义是支撑函数调用而不是让你无限递归。设计代码的时候心里要有这根弦方法调用深度大了栈是会被填满的。顺带提一嘴“backtrace栈回溯”这个词。线上排查栈溢出、死锁、线程卡死时常用的命令就是jstack pid导出线程快照看线程的栈帧回溯信息。它能告诉你每个线程当前执行到哪一行代码、在等待什么锁。配合栈的知识你能快速定位到“哪个方法调了哪个方法卡在哪个同步块”。4. 方法区Method Area类信息的档案馆与它的变身记4.1 从永久代到元空间方法区的演进原因方法区这个概念比较绕因为不同JDK版本下的实现完全不一样。JDK 7及以前方法区的实现叫永久代PermGenJDK 8开始永久代被移除方法区的实现改成了元空间Metaspace。为什么要做这个改变根本原因是永久代把方法区限制在了JVM堆内存内部有大小上限默认几十MB到一百多MB而且还经常被调优误伤——很多人把堆调大了却忘了永久代也会溢出结果动态加载大量类时直接OutOfMemoryError: PermGen space。元空间最大的变化是它不再使用JVM堆内存而是直接使用本地内存Native Memory。理论上只要操作系统物理内存够大元空间就能一直增长不再受-XX:MaxPermSize限制。JDK 8里你再也见不到PermGen space报错了堆是堆元空间是元空间两者不共用空间。方法区里到底放什么东西简单说就是类的元信息类名、访问修饰符、字段描述、方法描述、运行时常量池、静态变量、即时编译器编译后的代码缓存CodeCache。你用CGLIB生成代理类、用反射解析类、用Spring加载Bean定义都会往元空间里塞数据。4.2 运行时常量池与字符串常量池类加载后发生了什么方法区/元空间里有个重要结构叫运行时常量池Runtime Constant Pool。每个类在被加载时class文件里的常量池字面量、符号引用会被解析到这个区域。举个最常见的例子字符串常量池String Table在JDK 7之后就移到了堆里但字符串字面量最初的解析和驻留机制仍然和运行时常量池密切相关。当你写String s hello;JVM会先在字符串常量池里找有没有“hello”这个字符串对象有就直接复用没有就在堆里创建并放入常量池。而你写new String(hello)时JVM仍然会确保常量池里有“hello”但会在堆里额外创建一个新的对象。这个机制导致了一个经典面试陷阱hello new String(hello)返回false但hello.equals(new String(hello))返回true。原因就在于一个引用指向常量池对象另一个指向堆里的新对象。我见过不少线上内存泄漏的案例源头就是字符串被无脑intern。比如某些同学从网上抄了一段代码把每个UUID、每次日志拼接的结果都intern一下以为能省内存结果字符串常量池被塞得满满当当堆里的字符串对象数量爆表。字符串常量池本质上是一个HashTable驻留大量字符串会拖慢整个JVM的字符串操作。这玩意儿不是这么用的千万别瞎开。4.3 元空间配置与常见异常元空间虽然默认不限大小只受物理内存限制但生产环境一定要设置上限否则一旦发生类加载泄漏你连救的机会都没有。常用参数-XX:MetaspaceSize元空间初始大小触发扩容的阈值。-XX:MaxMetaspaceSize元空间最大大小超过它会报OutOfMemoryError: Metaspace。-XX:MaxDirectMemorySize堆外直接内存上限默认等于-Xmx。为什么说元空间OOM比堆OOM更麻烦因为类加载器泄漏很难排查。最常见的情景是应用频繁热部署、每次动态生成新的类加载器、但旧的类加载器没有被释放于是它们加载过的类元信息一直堆积在元空间里。普通的堆快照分析工具很难直接看出元空间被谁占了直到MaxMetaspaceSize触发服务挂掉。我踩过一次很深的坑项目用了某个老版本的基础框架里面每次调用都会动态生成一个代理类生产环境跑两三天Metaspace就被打满。最后是靠开启-XX:TraceClassLoading和-XX:TraceClassUnloading把类加载日志导出来才定位到具体的类生成点。所以我的建议是动态生成类的框架一定要加类加载日志别等服务挂了再盲猜。5. 三个区域怎么联动一次方法调用的完整内存旅程5.1 从javac编译到第一条字节码指令前面分了三个区域来讲但实际运行时它们是高度联动的。我以一段代码为例完整走一遍public class Demo { private static String TAG demo; public static void main(String[] args) { User user new User(); user.setName(张三); String tag TAG user.getName(); System.out.println(tag); } }类加载阶段JVM读取Demo.class文件把类元信息放入元空间方法区的实现TAG这个静态字符串变量也随类加载放入常量池/堆的字符串常量池区域。栈帧创建main线程启动创建main栈帧args引用存入局部变量表。对象分配执行new User()时JVM在堆的Eden区分配User对象内存栈帧局部变量表里的user引用指向这块堆内存。字符串拼接TAG user.getName()会创建一个新的StringBuilder对象也在堆里拼接完成后结果对象被放入堆栈帧局部变量表里的tag引用指向它。方法调用执行System.out.println(tag)时新栈帧压栈println方法的局部变量表接收到tag引用。退栈与GCmain方法执行完main栈帧出栈局部变量表里的引用消失。如果这个过程中触发了Minor GCEden区里那些没有外部引用的临时对象就会被回收user对象如果还活着可能移动到Survivor区继续熬年龄。这整个过程里栈负责“指挥”堆负责“存货”方法区负责“提供剧本类元信息”。三个区域缺一不可配合默契。5.2 堆外内存容易被忽略的“第四空间”堆外内存严格来说不属于前面的三个区域但它和JVM内存调优关系极其密切尤其是现在微服务架构下大量使用Netty、Kafka等NIO框架。堆外内存堆外直接内存是JVM通过DirectByteBuffer从操作系统直接分配的内存不走堆。这样做的好处是避免IO操作时数据在堆内和堆外之间来回拷贝读写性能更好。坏处是它不归GC管回收依赖Cleaner机制如果创建了太多DirectByteBuffer而不释放堆外内存就会悄悄打满然后报OutOfMemoryError: Direct buffer memory。排查堆外内存问题比堆内难得多因为常规的jmap导出堆快照根本看不到直接内存。我一般用这几种手段top看进程实际内存占用如果明显大于-Xmx优先怀疑堆外内存。pmap pid | grep anon看匿名内存映射找有没有异常大的内存块。用Java NMTNative Memory Tracking加上-XX:NativeMemoryTrackingsummary再通过jcmd pid VM.native_memory summary查看各区域内存占用明细。检查代码里所有ByteBuffer.allocateDirect的地方确认是否都正确释放了。我再强调一遍调优JVM内存不要只盯着堆。生产环境出OOM堆外内存导致的比例比我预想的高得多尤其是那些重度使用Netty、RocketMQ、Kafka的服务。6. 常见误区与调优经验清单6.1 必须避开的那些坑误区真实情况堆越大性能越好堆过大会导致GC时间变长不利于低延迟场景OOM就调大堆可能是元空间、堆外内存、线程栈、物理内存问题栈溢出就调大-Xss可能引发线程内存剧增高并发下更容易崩溃JDK 8里没有永久代就没有类溢出风险元空间同样可能溢出且更隐蔽方法区就是堆的一部分JDK 8后元空间使用本地内存与堆完全隔离字符串intern能省内存滥用intern会撑爆字符串常量池适得其反只要堆里对象没被引用就会被立刻回收对象要等GC触发才会被回收且分代不同回收时机不同这张表里的每一条都是我亲手踩过或者帮别人排查过的坑。尤其是“堆越大越好”这条我之前优化过一个小程序接口原本-Xmx4GFull GC一次要1.2秒接口时不时卡死。后来把堆降到2G换用G1垃圾回收器并显式设置-XX:MaxGCPauseMillis100Full GC基本消失了接口稳定返回。大堆并不等于好堆垃圾回收器的选择和分区比例往往更关键。6.2 一套实用的排查起点配置如果你要对一个Java服务做内存调优我建议从这套参数起步然后根据监控结果微调java -Xms2g -Xmx2g \ -XX:MetaspaceSize256m \ -XX:MaxMetaspaceSize512m \ -XX:MaxDirectMemorySize1g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/heapdump.hprof \ -Xloggc:/data/logs/gc.log \ -XX:PrintGCDetails我解释一下我的思路-Xms和-Xmx设成一样避免运行期频繁扩容和缩容带来的性能抖动元空间设上限防止类加载器泄漏拖垮整机HeapDumpOnOutOfMemoryError和gc.log是排查事故的“黑匣子”必须开别等到出事才后悔日志没打全。G1是目前JDK 8的主流选择它能比较平滑地控制GC停顿。6.3 最后分享一个我压箱底的经验我不敢说自己把JVM所有细节都吃透了但这些年下来有个体会内存模型的知识只有用在排查现场才算真正学会。只背概念记参数下一次遇到线上OOM你还是会慌。不如先从一个小程序开始故意写一段内存泄漏代码把堆dump出来玩一遍或者设置一个巨小的堆比如-Xmx64m跑Spring Boot应用亲眼看看它怎么一步步撑死、怎么报错。亲手复现几次问题之后你对堆、栈、方法区的理解会比看一百篇文章都深。如果你看完这篇文章只记住一句话我希望是这句内存模型不是一个静态的结构图而是一套动态的协作机制——对象在堆里出生栈帧随方法调用生灭类信息在元空间常驻任何一块区域失衡整个应用都会跟着遭殃。下次再遇到内存相关的毛病先定位区域再分析原因最后动参数。顺着这个节奏走大多数问题你都能稳稳接住。