专栏《Java后端工程师进阶之路》 | Day 4从 CRUD 到 AI 工程师的完整跃迁路径你有没有被这样的OOM折磨过凌晨两点运维电话打过来生产环境又挂了OOM了。你爬起来看日志发现是java.lang.OutOfMemoryError: Java heap space。于是你一拍脑门——堆不够大加内存呗把-Xmx从2G改成4G重启睡去。第二天凌晨三点电话又来了。问题不在堆的大小而在你根本没搞清楚这个对象到底生在哪块内存它该什么时候死谁在管它的生死今天这篇我用20年踩坑的血泪帮你把JVM运行时数据区一次讲透。堆、栈、方法区——不是三个干巴巴的概念而是三个各有管辖权、各有生死规则的行政区划。搞懂了这套地图你再也不怕OOM和内存泄漏。一、JVM运行时数据区五个行政区JVM在启动时会从操作系统申请一块大内存然后内部划分成五个区域每个区域各司其职区域线程共享存什么异常类型堆Heap所有线程共享对象实例、数组OutOfMemoryError: Java heap space方法区Method Area所有线程共享类元信息、常量池、静态变量OutOfMemoryError: MetaspaceJDK 8虚拟机栈VM Stack每线程独有一份局部变量表、操作数栈、动态链接StackOverflowError本地方法栈Native Method Stack每线程独有一份Native方法的调用信息StackOverflowError程序计数器PC Register每线程独有一份当前执行的字节码指令地址不会OOM记住一个关键原则线程私有区域栈、PC的内存大小在编译期就基本确定不会动态膨胀。所以栈只会StackOverflow不会OOM理论上可以OOM但极少见。而线程共享区域堆、方法区才会OOM——因为它们的大小是动态的你塞多少它就长多少直到撑爆。下面我们逐个拆解。二、堆对象的家也是OOM的重灾区堆是JVM管理的最大一块内存。所有对象实例和数组都在堆上分配JIT优化下的栈上分配是特例后面讲。现代JVM的堆被划分为-------------------------------------------------- | 堆Heap | ------------------------------------------------- | 新生代 | 老年代 | 元空间不在堆内| | Eden S0 S1| Old/Tenured | | -------------------------------------------------新生代Young GenerationEden区 两个Survivor区S0/S1新对象先在Eden出生经历Minor GC后存活的对象进入Survivor熬过一定次数晋升老年代老年代Old Generation长期存活的对象和大对象超过-XX:PretenureSizeThreshold直接进入对象在堆上的完整生命周期一个实战坑点很多人以为user null就能立即释放内存。大错特错null只是断开了栈上的引用堆上的对象还在直到GC来收割。如果GC迟迟不来比如老年代还有空间这些孤儿就会一直占着堆。老梁经验生产环境中不要依赖System.gc()——它只是建议JVM完全可以无视。真正的GC时机由JVM自己决定Eden区满触发Minor GC老年代满触发Full GC。三、虚拟机栈每个方法调用的工作台每个线程启动时JVM会为它分配一个虚拟机栈。栈由一个个**栈帧Stack Frame**组成每次方法调用就压入一个栈帧方法返回就弹出。一个栈帧包含------------------------ | 局部变量表 | ← 存方法参数和局部变量基本类型存值引用类型存指针 | 操作数栈 | ← 计算中间结果的工作区 | 动态链接 | ← 指向运行时常量池的方法引用 | 方法返回地址 | ← 方法正常/异常返回后回到哪 ------------------------局部变量表的容量在编译期就确定了——你写代码时声明了多少个局部变量表就多大运行时不会变。这也是为什么栈溢出是StackOverflowError而非OOM。// 代码2通过递归演示栈溢出直观感受栈帧的消耗 public class StackOverflowDemo { private static int callCount 0; // 每次递归调用都会在栈上压入一个新栈帧 // 局部变量表包含this引用(0号slot) int count参数(1号slot) public void recursiveCall(int count) { callCount; // 每个栈帧约占用1KB取决于局部变量数量和JVM实现 // 默认栈大小1MB的话约能压入1000个栈帧 recursiveCall(count 1); // ← 栈帧不断堆积 } public static void main(String[] args) { StackOverflowDemo demo new StackOverflowDemo(); try { demo.recursiveCall(1); } catch (StackOverflowError e) { // 打印实际栈帧深度 System.out.println(栈溢出递归深度: callCount); // 默认配置下通常在5000~10000次之间 // 可用 -Xss256k 降低栈大小来更快触发 } // 第二组实验对比不同-Xss参数的影响 System.out.println(\n--- 调整栈大小实验 ---); System.out.println(-Xss1M默认: 约10000次递归); System.out.println(-Xss256k: 约2000~3000次递归); System.out.println(-Xss4M: 约40000次递归); System.out.println(结论栈越大能容纳的栈帧越多但每个线程占用内存也越多); } }关键理解栈内存不需要回收——方法返回时栈帧自动弹出内存自然释放。这就是为什么栈永远不会内存泄漏只会溢出——你塞了太多栈帧进来。四、方法区类的户籍档案室方法区存放的是类的元信息类名、字段描述、方法描述、字节码指令、常量池、静态变量。这里有一个重大的历史变迁很多人至今还搞不清楚JDK版本方法区实现位置异常默认大小JDK 7及之前永久代PermGen堆内OutOfMemoryError: PermGen space82MB64位JVMJDK 8及之后元空间Metaspace堆外本地内存OutOfMemoryError: Metaspace无上限受物理内存限制为什么要从PermGen改到Metaspace三个原因PermGen大小固定很难预估——设小了容易OOM设大了浪费堆空间字符串常量池从PermGen移到了堆JDK 7开始PermGen越来越名不副实Metaspace使用本地内存大小自动扩展不抢占堆空间——类加载多时自动扩类卸载时自动缩常量池的三次搬家// 代码3验证常量池在不同JDK版本的行为差异 public class ConstantPoolEvolution { public static void main(String[] args) { // JDK 6字符串常量池在PermGen // JDK 7字符串常量池移到堆 // JDK 8类元信息在Metaspace字符串常量池仍在堆 // 实验1String.intern()的行为变化 // JDK 6: intern()把字符串拷贝到PermGen常量池返回PermGen引用 // JDK 7: intern()把字符串引用放到堆常量池可能只存引用不拷贝 String s1 new StringBuilder(ja).append(va).toString(); System.out.println(s1.intern() s1: (s1.intern() s1)); // JDK 6: falseintern拷贝到PermGen引用不同 // JDK 7: trueintern直接记录堆上引用不拷贝——但java是特殊字符串 // JDK启动时已经把java放入常量池了所以这里实际上是false // 实验2验证非特殊字符串 String s2 new StringBuilder(老梁).append(测试).toString(); System.out.println(s2.intern() s2: (s2.intern() s2)); // JDK 7: true首次intern堆上引用直接记录到常量池 // JDK 6: false拷贝到PermGen // 实验3Metaspace大小监控JDK 8 // 用jcmd查看Metaspace使用情况 System.out.println(\n请在终端运行以下命令观察Metaspace:); System.out.println(jcmd pid VM.metaspace); System.out.println(或设置 -XX:MaxMetaspaceSize256m 限制元空间上限); } }一个真实的生产坑我们曾遇到一个服务反复OOM: Metaspace。排查发现是动态代理类疯狂生成CGLIB代理每次创建新类类加载器又没卸载Metaspace被撑爆。解法限制代理类缓存 设置-XX:MaxMetaspaceSize。五、一个对象从创建到销毁的完整内存流转把上面四个区域串起来看一个对象的一生GC Roots是什么就是GC判断对象还活着吗的起点。四种GC Roots虚拟机栈中的引用——正在执行的方法的局部变量方法区中的静态变量引用——类的static字段方法区中的常量引用——常量池里的常量本地方法栈中的JNI引用——Native代码持有的引用对象只要跟任何一个GC Root有引用链相连就是活的。断开所有链就是死的——但不会立即被回收还要等GC来收割。六、实战建议三招搞定内存问题建议1学会读JVM内存地图——用jmap和jcmd# 查看堆内存分布新生代/老年代各用了多少 jmap -heap pid # 查看堆中对象统计哪种对象占了最多空间 jmap -histo pid | head -20 # JDK 8 推荐用jcmd替代jmap更安全不会触发Full GC jcmd pid GC.heap_info jcmd pid VM.metaspace # 导出堆转储OOM时自动导出-XX:HeapDumpOnOutOfMemoryError jcmd pid GC.heap_dump /tmp/heapdump.hprof建议2OOM时要看哪个区爆了不要无脑加内存异常信息爆的区正确动作Java heap space堆分析对象分布找泄漏点不是加XmxMetaspace方法区查动态代理/类加载泄漏设MaxMetaspaceSizePermGen spaceJDK 6/7永久代升JDK或调MaxPermSizeGC overhead limit exceeded堆GC花了98%时间只回收了2%内存——说明堆里全是垃圾查泄漏unable to create native thread不是JVM内存操作系统进程内存限制查线程数和-Xss建议3开发期就养成引用意识方法结束后不再需要的引用及时断开——特别是大对象List、Map、byte[]避免在静态变量中缓存不需要的数据——静态引用是GC Root永远不会被回收慎用ThreadLocal——线程池环境下线程不销毁ThreadLocal的值也不销毁容易泄漏大集合用完就清——list.clear()比等GC来回收更及时七、AI时代JVM的新考量如果你将来要做AI推理服务的部署比如用Java调用大模型API、运行本地推理JVM内存模型会有新挑战大模型API响应缓存几百KB的JSON响应频繁进出堆Eden区GC压力增大——考虑用堆外缓存DirectByteBuffer或Redis向量计算场景高维向量768~1536维的float数组大量分配在堆上——考虑使用ByteBuffer.allocateDirect()走本地内存减少堆GC负担Metaspace风险动态加载多种模型适配器类时类数量暴涨——监控Metaspace占用设上限这些在Day 7我们会深入讲GraalVM和向量计算这里先留个印象。金句内存不是仓库是城市——有规划、有分区、有城管GC。搞不懂规划图别进城。下篇预告Day 5《GC调优实战指南从看懂GC日志到解决Full GC频繁》堆的分区和对象流转搞清楚了下一篇我们就讲堆的城管——垃圾收集器。CMS、G1、ZGC该怎么选Full GC频繁怎么排查GC日志那堆数字到底什么意思老梁用生产案例逐行给你讲。我是「技术宅·老梁」用实战讲技术。关注我90天从CRUD到AI工程师。
Day4 JVM内存模型：一篇文章搞定堆栈方法区的关系
专栏《Java后端工程师进阶之路》 | Day 4从 CRUD 到 AI 工程师的完整跃迁路径你有没有被这样的OOM折磨过凌晨两点运维电话打过来生产环境又挂了OOM了。你爬起来看日志发现是java.lang.OutOfMemoryError: Java heap space。于是你一拍脑门——堆不够大加内存呗把-Xmx从2G改成4G重启睡去。第二天凌晨三点电话又来了。问题不在堆的大小而在你根本没搞清楚这个对象到底生在哪块内存它该什么时候死谁在管它的生死今天这篇我用20年踩坑的血泪帮你把JVM运行时数据区一次讲透。堆、栈、方法区——不是三个干巴巴的概念而是三个各有管辖权、各有生死规则的行政区划。搞懂了这套地图你再也不怕OOM和内存泄漏。一、JVM运行时数据区五个行政区JVM在启动时会从操作系统申请一块大内存然后内部划分成五个区域每个区域各司其职区域线程共享存什么异常类型堆Heap所有线程共享对象实例、数组OutOfMemoryError: Java heap space方法区Method Area所有线程共享类元信息、常量池、静态变量OutOfMemoryError: MetaspaceJDK 8虚拟机栈VM Stack每线程独有一份局部变量表、操作数栈、动态链接StackOverflowError本地方法栈Native Method Stack每线程独有一份Native方法的调用信息StackOverflowError程序计数器PC Register每线程独有一份当前执行的字节码指令地址不会OOM记住一个关键原则线程私有区域栈、PC的内存大小在编译期就基本确定不会动态膨胀。所以栈只会StackOverflow不会OOM理论上可以OOM但极少见。而线程共享区域堆、方法区才会OOM——因为它们的大小是动态的你塞多少它就长多少直到撑爆。下面我们逐个拆解。二、堆对象的家也是OOM的重灾区堆是JVM管理的最大一块内存。所有对象实例和数组都在堆上分配JIT优化下的栈上分配是特例后面讲。现代JVM的堆被划分为-------------------------------------------------- | 堆Heap | ------------------------------------------------- | 新生代 | 老年代 | 元空间不在堆内| | Eden S0 S1| Old/Tenured | | -------------------------------------------------新生代Young GenerationEden区 两个Survivor区S0/S1新对象先在Eden出生经历Minor GC后存活的对象进入Survivor熬过一定次数晋升老年代老年代Old Generation长期存活的对象和大对象超过-XX:PretenureSizeThreshold直接进入对象在堆上的完整生命周期一个实战坑点很多人以为user null就能立即释放内存。大错特错null只是断开了栈上的引用堆上的对象还在直到GC来收割。如果GC迟迟不来比如老年代还有空间这些孤儿就会一直占着堆。老梁经验生产环境中不要依赖System.gc()——它只是建议JVM完全可以无视。真正的GC时机由JVM自己决定Eden区满触发Minor GC老年代满触发Full GC。三、虚拟机栈每个方法调用的工作台每个线程启动时JVM会为它分配一个虚拟机栈。栈由一个个**栈帧Stack Frame**组成每次方法调用就压入一个栈帧方法返回就弹出。一个栈帧包含------------------------ | 局部变量表 | ← 存方法参数和局部变量基本类型存值引用类型存指针 | 操作数栈 | ← 计算中间结果的工作区 | 动态链接 | ← 指向运行时常量池的方法引用 | 方法返回地址 | ← 方法正常/异常返回后回到哪 ------------------------局部变量表的容量在编译期就确定了——你写代码时声明了多少个局部变量表就多大运行时不会变。这也是为什么栈溢出是StackOverflowError而非OOM。// 代码2通过递归演示栈溢出直观感受栈帧的消耗 public class StackOverflowDemo { private static int callCount 0; // 每次递归调用都会在栈上压入一个新栈帧 // 局部变量表包含this引用(0号slot) int count参数(1号slot) public void recursiveCall(int count) { callCount; // 每个栈帧约占用1KB取决于局部变量数量和JVM实现 // 默认栈大小1MB的话约能压入1000个栈帧 recursiveCall(count 1); // ← 栈帧不断堆积 } public static void main(String[] args) { StackOverflowDemo demo new StackOverflowDemo(); try { demo.recursiveCall(1); } catch (StackOverflowError e) { // 打印实际栈帧深度 System.out.println(栈溢出递归深度: callCount); // 默认配置下通常在5000~10000次之间 // 可用 -Xss256k 降低栈大小来更快触发 } // 第二组实验对比不同-Xss参数的影响 System.out.println(\n--- 调整栈大小实验 ---); System.out.println(-Xss1M默认: 约10000次递归); System.out.println(-Xss256k: 约2000~3000次递归); System.out.println(-Xss4M: 约40000次递归); System.out.println(结论栈越大能容纳的栈帧越多但每个线程占用内存也越多); } }关键理解栈内存不需要回收——方法返回时栈帧自动弹出内存自然释放。这就是为什么栈永远不会内存泄漏只会溢出——你塞了太多栈帧进来。四、方法区类的户籍档案室方法区存放的是类的元信息类名、字段描述、方法描述、字节码指令、常量池、静态变量。这里有一个重大的历史变迁很多人至今还搞不清楚JDK版本方法区实现位置异常默认大小JDK 7及之前永久代PermGen堆内OutOfMemoryError: PermGen space82MB64位JVMJDK 8及之后元空间Metaspace堆外本地内存OutOfMemoryError: Metaspace无上限受物理内存限制为什么要从PermGen改到Metaspace三个原因PermGen大小固定很难预估——设小了容易OOM设大了浪费堆空间字符串常量池从PermGen移到了堆JDK 7开始PermGen越来越名不副实Metaspace使用本地内存大小自动扩展不抢占堆空间——类加载多时自动扩类卸载时自动缩常量池的三次搬家// 代码3验证常量池在不同JDK版本的行为差异 public class ConstantPoolEvolution { public static void main(String[] args) { // JDK 6字符串常量池在PermGen // JDK 7字符串常量池移到堆 // JDK 8类元信息在Metaspace字符串常量池仍在堆 // 实验1String.intern()的行为变化 // JDK 6: intern()把字符串拷贝到PermGen常量池返回PermGen引用 // JDK 7: intern()把字符串引用放到堆常量池可能只存引用不拷贝 String s1 new StringBuilder(ja).append(va).toString(); System.out.println(s1.intern() s1: (s1.intern() s1)); // JDK 6: falseintern拷贝到PermGen引用不同 // JDK 7: trueintern直接记录堆上引用不拷贝——但java是特殊字符串 // JDK启动时已经把java放入常量池了所以这里实际上是false // 实验2验证非特殊字符串 String s2 new StringBuilder(老梁).append(测试).toString(); System.out.println(s2.intern() s2: (s2.intern() s2)); // JDK 7: true首次intern堆上引用直接记录到常量池 // JDK 6: false拷贝到PermGen // 实验3Metaspace大小监控JDK 8 // 用jcmd查看Metaspace使用情况 System.out.println(\n请在终端运行以下命令观察Metaspace:); System.out.println(jcmd pid VM.metaspace); System.out.println(或设置 -XX:MaxMetaspaceSize256m 限制元空间上限); } }一个真实的生产坑我们曾遇到一个服务反复OOM: Metaspace。排查发现是动态代理类疯狂生成CGLIB代理每次创建新类类加载器又没卸载Metaspace被撑爆。解法限制代理类缓存 设置-XX:MaxMetaspaceSize。五、一个对象从创建到销毁的完整内存流转把上面四个区域串起来看一个对象的一生GC Roots是什么就是GC判断对象还活着吗的起点。四种GC Roots虚拟机栈中的引用——正在执行的方法的局部变量方法区中的静态变量引用——类的static字段方法区中的常量引用——常量池里的常量本地方法栈中的JNI引用——Native代码持有的引用对象只要跟任何一个GC Root有引用链相连就是活的。断开所有链就是死的——但不会立即被回收还要等GC来收割。六、实战建议三招搞定内存问题建议1学会读JVM内存地图——用jmap和jcmd# 查看堆内存分布新生代/老年代各用了多少 jmap -heap pid # 查看堆中对象统计哪种对象占了最多空间 jmap -histo pid | head -20 # JDK 8 推荐用jcmd替代jmap更安全不会触发Full GC jcmd pid GC.heap_info jcmd pid VM.metaspace # 导出堆转储OOM时自动导出-XX:HeapDumpOnOutOfMemoryError jcmd pid GC.heap_dump /tmp/heapdump.hprof建议2OOM时要看哪个区爆了不要无脑加内存异常信息爆的区正确动作Java heap space堆分析对象分布找泄漏点不是加XmxMetaspace方法区查动态代理/类加载泄漏设MaxMetaspaceSizePermGen spaceJDK 6/7永久代升JDK或调MaxPermSizeGC overhead limit exceeded堆GC花了98%时间只回收了2%内存——说明堆里全是垃圾查泄漏unable to create native thread不是JVM内存操作系统进程内存限制查线程数和-Xss建议3开发期就养成引用意识方法结束后不再需要的引用及时断开——特别是大对象List、Map、byte[]避免在静态变量中缓存不需要的数据——静态引用是GC Root永远不会被回收慎用ThreadLocal——线程池环境下线程不销毁ThreadLocal的值也不销毁容易泄漏大集合用完就清——list.clear()比等GC来回收更及时七、AI时代JVM的新考量如果你将来要做AI推理服务的部署比如用Java调用大模型API、运行本地推理JVM内存模型会有新挑战大模型API响应缓存几百KB的JSON响应频繁进出堆Eden区GC压力增大——考虑用堆外缓存DirectByteBuffer或Redis向量计算场景高维向量768~1536维的float数组大量分配在堆上——考虑使用ByteBuffer.allocateDirect()走本地内存减少堆GC负担Metaspace风险动态加载多种模型适配器类时类数量暴涨——监控Metaspace占用设上限这些在Day 7我们会深入讲GraalVM和向量计算这里先留个印象。金句内存不是仓库是城市——有规划、有分区、有城管GC。搞不懂规划图别进城。下篇预告Day 5《GC调优实战指南从看懂GC日志到解决Full GC频繁》堆的分区和对象流转搞清楚了下一篇我们就讲堆的城管——垃圾收集器。CMS、G1、ZGC该怎么选Full GC频繁怎么排查GC日志那堆数字到底什么意思老梁用生产案例逐行给你讲。我是「技术宅·老梁」用实战讲技术。关注我90天从CRUD到AI工程师。
