深入了解 JVM 内存区域划分你就抓住了 Java 性能调优和问题排查的牛鼻子。这篇文章不拽理论从实际开发场景出发把堆、栈、方法区这些核心区域掰开揉碎讲清楚包括它们到底存什么、为什么这么设计、日常开发中怎么基于这套机制定位问题以及面试官最爱问的那些点。全文干货可以收藏了慢慢看。1. 内存区域划分JVM 运行时的“地盘”规划很多Java开发者写代码好几年被问到“你了解JVM内存模型吗”还是一脸懵。这不怪大家毕竟平时写业务代码new一个对象、调一个方法内存就被自动管理了谁也没真去操心这些对象到底放在哪。但你一旦开始接触高并发、大数据量处理或者遇到线上OOM、频繁Full GC不懂内存区域划分就会非常被动。JVM在运行Java程序时会把自己管理的内存划分为若干个不同的数据区域。这个划分不是随意拍的每个区域都有明确的职责边界、生命周期和异常触发条件。整体来看可以分成两条线一条是线程私有的区域随线程的创建而创建随线程的消亡而回收。这类区域包括虚拟机栈、本地方法栈、程序计数器。它们每个线程都有一份互不干扰天然不需要考虑线程安全问题。另一条是线程共享的区域所有线程都能访问。这就是我们常说的堆和方法区JDK8以后叫元空间概念上属于本地内存但逻辑上还是JVM规范里的方法区实现。这两块是垃圾回收的主战场也是OOM最常出现的地方。用一张生活化的图来理解把JVM比作一个公司。堆就是公司的公共仓库所有员工线程生产出来的货物对象都往这里放仓库有容量上限满了就要清理GC虚拟机栈就是每个员工的私人办公桌桌上摆着正在处理的文件栈帧处理完一份就丢掉一份方法区是整个公司的制度手册存放处记录了所有类该怎么创建、方法怎么调用这些模板信息全局共享。理解了这张图你再看“堆、栈、方法区分别存什么”这个问题脑子里就有了清晰的地图。接下来我按照实际排查问题时的关注度先讲重中之重——堆。2. 堆Java 对象的“主战场”堆是JVM管理内存中最大的一块也是垃圾回收器重点照顾的区域。几乎所有new出来的对象实例和数组都在这里分配内存。你写ArrayList、HashMap、String内部的对象实体都躺在堆里。2.1 堆里的对象生命周期与分代设计堆为什么还要继续细分因为不同对象的存活时间差异巨大。有的对象一创建就很快没人用了比如方法内部的临时变量有的对象是全局配置、单例会一直存活到程序结束。如果对所有对象一视同仁去扫描和回收性能太差。所以绝大多数JVM把堆分成新生代Young Generation和老年代Old Generation。新生代里又细分为Eden区、From Survivor区、To Survivor区默认比例是8:1:1。新对象首先进入Eden区Minor GC时把存活对象复制到Survivor区每熬过一次GC年龄加一年龄达到阈值默认15就晋升到老年代。这就是分代收集的核心思想把内存按对象年龄分区用不同的回收策略处理。这个设计有一个很直观的原因绝大多数对象都是“朝生夕灭”的。你在一个方法里new一个StringBuffer拼接字符串方法执行完这个对象就没人引用了。让这类短命对象在新生代快速回收避免频繁把对象挪到老年代能显著降低GC压力。2.2 堆参数怎么调堆的大小决定了一个Java应用能容纳多少对象。调参主要围绕以下几个参数参数作用常见问题-Xms初始堆大小设置过大启动慢设置过小启动后频繁扩容-Xmx最大堆大小太小直接OOM太大影响操作系统其他进程-Xmn新生代大小过大会压缩老年代过小会导致对象频繁晋升-XX:SurvivorRatioEden区与Survivor区比例默认8即8:1:1不要轻易改动-XX:MaxTenuringThreshold晋升老年代的年龄阈值默认15CMS收集器可能调整为6实操过程中最常用的调法是在启动脚本里显式指定java -Xms512m -Xmx2048m -Xmn512m -XX:SurvivorRatio8 -jar your-app.jar这里要注意几点-Xms和-Xmx建议设为相同值避免运行期间堆扩大或缩小时带来的性能损耗和不确定性。JVM在扩容堆时需要向操作系统申请内存这是一个较重的操作在业务高峰期触发扩容很容易造成卡顿。-Xmn不是越大越好新生代太大老年代就相对变小大对象更容易触发Full GC。如果日志里频繁出现“GC (Allocation Failure)”并且耗时越来越长优先检查堆大小配置而不是急着优化代码。2.3 堆外内存也是个坑日常开发中还有一个容易忽略的地方——堆外内存。DirectByteBuffer、Map内存映射文件、Netty的Direct Buffer都使用堆外内存。这部分内存不归GC管大小通过-XX:MaxDirectMemorySize控制默认等于-Xmx。我在实际项目里遇到过一次诡异问题堆内存占用不高但进程整体内存占用不断上涨最后容器被系统OOM Killer杀掉。排查发现是Netty的堆外内存没有及时释放每一帧数据都申请了DirectBuffer但释放依赖Cleaner机制GC一直没触发堆外就越攒越多。排查这类问题时用jcmd命令可以查看堆外内存使用情况jcmd pid VM.native_memory summary不过要提前在启动参数里加上-XX:NativeMemoryTrackingsummary否则拿不到明细。3. 栈线程执行的“现场记录仪”如果说堆是JVM里的大仓库那栈就是每个线程手里的“便签本”。Java虚拟机栈描述的是Java方法执行的线程内存模型每个方法被执行时JVM都会同步创建一个栈帧用来存放局部变量表、操作数栈、动态链接、方法出口等信息。3.1 栈帧里到底有什么局部变量表是这个栈帧最核心的部分。你方法里定义的八种基本数据类型变量byte、short、int、long、float、double、char、boolean、对象引用reference、returnAddress类型都保存在局部变量表里。注意一个关键点局部变量表存储的是对象的引用不是对象本身。对象实体还是放在堆里。比如这样一段代码public void demo() { User user new User(张三); }这里的user是一个局部变量用8个字节的Slot存的是指向堆中User对象的内存地址而User对象本体包括它的name字段值张三全都在堆里。操作数栈可以理解为JVM的“算盘”。所有真正的数值运算比如int类型的加法都是先把操作数压入操作数栈然后执行iadd指令弹出两个数计算结果再压回去。动态链接则是为了支持方法调用符号引用在运行期需要转换为直接引用。3.2 栈溢出是怎么发生的栈最常见的异常是StackOverflowError也就是栈深度超过了JVM允许的最大深度。写递归没有终止条件是生产环境最常见的引发方式public void infiniteLoop() { while (true) { new Thread(() - { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); } }这段代码其实不会栈溢出会先触发线程数上限或内存OOM。真正触发栈溢出的是这种public void test() { test(); }每个线程的栈大小通过-Xss参数设置。但栈溢出多数情况下不是靠调大-Xss解决的而是代码逻辑有问题。把-Xss调大只是在拖延问题无休止的深度递归还会增加GC时间和CPU消耗。3.3 本地方法栈——容易被忽略的兄弟JVM规范里还有一个本地方法栈服务对象是JVM调用到的native方法。比如Thread.start()底层会调用start0()这个native方法执行时的栈就是本地方法栈。很多人在面试时被问到“本地方法栈的作用”第一反应就是“不知道没接触过”。实际上你每天都在用。比如System.currentTimeMillis()是native方法Object.hashCode()的默认实现也是native方法。HotSpot虚拟机把虚拟机栈和本地方法栈合二为一了所以从使用视角来说你不一定感知得到它但理解概念仍然重要。3.4 程序计数器——最小的内存区域还有一块叫程序计数器是所有区域里最小的一块也是唯一一个在规范里没有规定OOM情况的区域。它存储的是当前线程执行的字节码行号指示器。多线程切换时每个线程都需要独立的程序计数器才能恢复到刚才执行的位置。它只占用很小的内存空间平时不需要特别关注。4. 方法区类信息的“档案馆”方法区存储的是已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。在JDK8之前方法区的实现叫永久代PermGen它位于JVM堆内受JVM堆大小限制。JDK8开始永久代被移除取而代之的是元空间Metaspace。4.1 永久代到元空间的变迁逻辑为什么要从永久代换到元空间最核心的原因是永久代的大小难以预测太容易触发OOM。典型场景就是动态生成类特别多的框架比如CGLIB代理、JSP编译、Spring AOP。在JDK7时代一个稍复杂的Web应用部署后就可能报OutOfMemoryError: PermGen space只能靠调大-XX:MaxPermSize解决治标不治本。元空间最大的变化是不再使用JVM堆内存改用了本地内存。默认情况下元空间的容量只受操作系统可用内存限制这给了动态生成类的框架极大的喘息空间。4.2 方法区里存了什么具体来说方法区里主要包括以下几类数据类的元信息类名、访问修饰符、父类、接口、字段描述、方法描述。运行时常量池存放编译期生成的各种字面量和符号引用。静态变量注意JDK7之后静态变量被移到了堆中但逻辑上仍然属于方法区规范的一部分。即时编译器编译后的代码比如热点方法被JIT编译为机器码后缓存也在方法区。我以一个实际例子来解释运行时常量池。你写String a hello;这个hello字符串在类加载时放入运行时常量池。如果这时你用new String(hello)JVM会先看常量池里有没有hello有就返回引用没有才在堆里创建对象。这也是为什么字符串字面量的比较有时返回true的原因之一。4.3 方法区参数调优虽然元空间默认不受上限约束但生产环境不设限不等于万事大吉。如果代码存在类加载器泄漏比如每次热部署都创建新的类加载器且不释放元空间会被不断撑大最终把整个服务器的内存耗尽。常用的元空间参数-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512mMetaspaceSize不是初始容量而是触发Full GC的阈值。当元空间使用量超过这个值JVM会触发一次Full GC来清理不再需要的类信息。调优建议是MetaspaceSize和MaxMetaspaceSize设置为相同值避免动态扩容带来的性能抖动。4.4 还应该关注字符串常量池的位置JDK7之前字符串常量池在永久代JDK7开始被移到了堆中。这一改动影响很大原来字符串常量池里的字符串无法被GC回收频繁创建字符串字面量容易导致PermGen OOM。挪到堆之后字符串常量池可以由GC统一管理内存利用率更高。面试如果被问到“字符串常量池在哪个区域”你可以答出JDK7之后在堆中同时要解释为什么挪出来——因为永久代空间有限GC效率低而字符串常量池又需要频繁进行内存分配和回收。5. 堆、栈、方法区的协同工作与排查实战前面讲完了各个区域的概念现在把它们串起来理解一次对象创建的完整流程。这一步做好了你会对JVM内存有质的认识。5.1 一个对象从创建到使用的内存轨迹执行User user new User(张三)时JVM做了这些事情类加载阶段检查User类是否已加载。如果没有类加载器读取User.class把类的元信息存入方法区元空间并在堆中创建唯一的Class对象。分配内存在堆的Eden区划分一块内存空间给这个新对象。内存空间清零JVM把这块内存区域的字段初始化为零值保证实例字段有确定初值。设置对象头记录对象所属类、哈希码、GC分代年龄、锁状态等信息。构造方法执行调用User的构造方法张三字符串从常量池或新建String对象赋给name字段赋值完成。在这个流程中方法区提供了“模板”类信息堆提供了“实体存储空间”栈中的局部变量表保存了“对象的引用地址”。三者缺一不可。方法执行完毕后栈帧被弹出user这个局部变量随之消失堆里的User对象如果没有其他引用就变成了垃圾等Minor GC时被回收如果对象熬过了多次GC就被晋升到老年代。5.2 实操用IDE调整JVM运行内存排查OOM在本地开发时IDEA默认给应用的堆内存可能很小遇到大集合处理、频繁创建对象容易出现OutOfMemoryError: Java heap space。调整方法有两种一种是在Run Configuration的VM options里加参数只对当前配置有效。另一种是在IDEA安装目录的bin文件夹下修改idea64.exe.vmoptions影响IDE本身的启动内存。我在实际开发中建议给自己的服务启动配置加上这些参数-Xms512m -Xmx1024m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump/这里最关键的是-XX:HeapDumpOnOutOfMemoryError。一旦发生OOMJVM会自动生成一份堆转储文件你拿着这份文件用MAT或者VisualVM分析能直接看到哪些对象占用了大量内存。很多线上问题都是靠这个参数留下的现场抓到真凶的。5.3 如何快速定位堆占用过高的对象假设你已经拿到了heap dump文件用MAT打开后重点关注Histogram视图。我查找内存泄漏的习惯步骤是看Histogram里占用总量前几名的类一般是byte[]、String、HashMap$Node这类。右键某个类选择“Merge Shortest Paths to GC Roots”排除弱引用和软引用看哪个对象被强引用链挂着。顺着引用链往上找大概率能定位到某个业务类持有了一堆不该持有的数据。有一次在线上排查内存溢出发现byte[]占用极高Merge Shortest Paths后找到根源是某个定时任务把一个大文件的全部字节加载进内存处理完后没有释放引用。这个问题靠肉眼很难发现但用MAT配合heap dump三分钟就定位了。6. 常见问题与排查技巧实录速查表面试和实战中最常遇到的内存区域相关的问题我整理成一个速查表方便你随时翻看。问题场景可能原因排查方向堆内存持续增长且GC回收效果差存在对象泄漏对象被意外持有引用生成堆转储分析GC Roots老年代频繁Full GC新生代太小对象过快晋升或者代码中大量产生长生命周期对象调整分代比例检查缓存、全局集合频繁报StackOverflowError递归无终止条件、过深的方法调用链检查递归代码调整-XssMetaspace OOM类加载器泄漏、动态生成类过多查看类加载统计定位未卸载的类加载器堆使用不高但进程内存很大堆外内存使用过多NMT检测堆外内存检查DirectBuffer、Netty字符串大量重复且占用高未使用String.intern或常量池管理不当分析String对象去重、启用String Deduplication启动后很快OOM-Xmx设置过小或初始化加载数据过多查看启动日志调整堆大小6.1 面试高频问题堆和栈的区别面试中这题必问。你可以从以下几个维度作答存储内容堆存储对象实例和数组栈存储局部变量、方法调用信息。线程共享性堆是线程共享的栈是线程私有的。空间大小堆可以设置到很大比如几十GB栈一般只有几百KB到几MB。生命周期堆里的对象由GC负责回收栈帧随方法调用结束自动销毁。异常类型堆内存不足抛OOM栈深度超标抛StackOverflowError。回答时可以顺手举一个例子比如new User()说明User对象实体在堆中User变量引用在栈中这样考官会认为你真的理解了而不是背书。6.2 栈与堆的配合对并发编程的影响因为栈是线程私有的所以局部变量天然线程安全。多线程并发操作同一个堆中的对象时就会产生竞态条件。这也是为什么局部变量在多线程环境下不需要加锁而不是线程安全问题的关键原因。public void method() { int count 0; // 栈中每个线程独立安全 HashMap map new HashMap(); // 堆中多线程共享不安全 }很多人高并发时疯狂加锁但没想过哪块内存是冲突根源。这里多提一嘴如果是全局唯一的对象比如Spring管理的单例Bean它们都在老年代或者堆里天然是线程共享的。如果你把局部变量用static修饰它就从栈挪到堆里线程安全问题立刻出现。6.3 区分JVM内存结构和Java内存模型很多初学者把JVM内存区域和Java内存模型搞混。我这里明说JVM内存区域划分讲的是数据存哪儿堆、栈、方法区这个物理分区的概念**Java内存模型JMM**讲的是多线程编程中共享变量的可见性、有序性、原子性规则它关注的是主内存和工作内存之间的交互协议。JMM与JVM的内存区域划分没有直接对应关系这是两个不同维度的概念。如果你回答面试题“谈谈JVM内存模型”最好先问清楚对方指哪种。如果泛指建议把内存区域划分放前面JMM放后面二者都覆盖到最稳妥。6.4 堆内存参数调整的最佳实践这里分享一套我在生产环境常用的大小估算方法。一个Java服务的堆大小推荐取JVM进程最大可用内存的50%到60%。比如你的容器限制是4GB内存堆建议不超过2.5GB。剩下的留给元空间、线程栈、堆外内存、JIT编译器开销。为什么不能把堆占到80%因为JVM本身运行也需要开销线程栈占用的是进程内存但不是堆内存而且GC算法在堆接近满的时候会更频繁地运行反而降低吞吐量。实践下来堆占整个容器内存的60%是一个比较均衡的数值既给了对象足够的空间又不会挤压其他部分。如果你用容器部署Java10以上的版本建议开启-XX:UseContainerSupport这个参数让JVM自动识别容器内存限制从而合理自适应堆大小防止在容器里把宿主机内存打满。还有一个参数值得一试-XX:UseG1GCG1是JDK9之后的默认垃圾回收器适合大堆场景4GB以上它能比较好地平衡停顿时间和吞吐量。如果你的应用还在用Parallel GC而且在不断调优考虑迁移到G1能省很多心。7. 写在最后的实际排查经验关于JVM内存区域我踩过不少坑有几个体会必须分享。第一个是线上环境一定要加HeapDumpOnOutOfMemoryError并且把dump文件落盘到一个磁盘空间足够的位置。很多团队等内存溢出发生后才后悔没留现场。OOM不是最可怕的最可怕的是OOM了却不知道为什么。第二个是不要神化调优。大多数业务系统的性能瓶颈根本不在JVM内存区域配置上而是代码写得有问题——比如一次性加载全表数据进内存、for循环里不断new对象、坚持用String拼接而不考虑StringBuilder。先把代码写好再谈调优才有意义。第三个是熟悉常用排查命令。jstat -gcutil看GC比例jmap -heap看堆配置jstack看线程状态jcmd GC.class_histogram看类占用。这些命令学起来很快但关键时刻比什么工具都好使因为生产环境往往没有图形化界面。如果你想深入验证自己对内存区域的理解最好的方式是找一个线上疑难问题先根据现象猜原因再用排查命令和dump分析去验证。多来几轮你就能成为团队里的JVM问题终结者。
JVM内存区域划分详解：堆、栈、方法区与性能调优实战
深入了解 JVM 内存区域划分你就抓住了 Java 性能调优和问题排查的牛鼻子。这篇文章不拽理论从实际开发场景出发把堆、栈、方法区这些核心区域掰开揉碎讲清楚包括它们到底存什么、为什么这么设计、日常开发中怎么基于这套机制定位问题以及面试官最爱问的那些点。全文干货可以收藏了慢慢看。1. 内存区域划分JVM 运行时的“地盘”规划很多Java开发者写代码好几年被问到“你了解JVM内存模型吗”还是一脸懵。这不怪大家毕竟平时写业务代码new一个对象、调一个方法内存就被自动管理了谁也没真去操心这些对象到底放在哪。但你一旦开始接触高并发、大数据量处理或者遇到线上OOM、频繁Full GC不懂内存区域划分就会非常被动。JVM在运行Java程序时会把自己管理的内存划分为若干个不同的数据区域。这个划分不是随意拍的每个区域都有明确的职责边界、生命周期和异常触发条件。整体来看可以分成两条线一条是线程私有的区域随线程的创建而创建随线程的消亡而回收。这类区域包括虚拟机栈、本地方法栈、程序计数器。它们每个线程都有一份互不干扰天然不需要考虑线程安全问题。另一条是线程共享的区域所有线程都能访问。这就是我们常说的堆和方法区JDK8以后叫元空间概念上属于本地内存但逻辑上还是JVM规范里的方法区实现。这两块是垃圾回收的主战场也是OOM最常出现的地方。用一张生活化的图来理解把JVM比作一个公司。堆就是公司的公共仓库所有员工线程生产出来的货物对象都往这里放仓库有容量上限满了就要清理GC虚拟机栈就是每个员工的私人办公桌桌上摆着正在处理的文件栈帧处理完一份就丢掉一份方法区是整个公司的制度手册存放处记录了所有类该怎么创建、方法怎么调用这些模板信息全局共享。理解了这张图你再看“堆、栈、方法区分别存什么”这个问题脑子里就有了清晰的地图。接下来我按照实际排查问题时的关注度先讲重中之重——堆。2. 堆Java 对象的“主战场”堆是JVM管理内存中最大的一块也是垃圾回收器重点照顾的区域。几乎所有new出来的对象实例和数组都在这里分配内存。你写ArrayList、HashMap、String内部的对象实体都躺在堆里。2.1 堆里的对象生命周期与分代设计堆为什么还要继续细分因为不同对象的存活时间差异巨大。有的对象一创建就很快没人用了比如方法内部的临时变量有的对象是全局配置、单例会一直存活到程序结束。如果对所有对象一视同仁去扫描和回收性能太差。所以绝大多数JVM把堆分成新生代Young Generation和老年代Old Generation。新生代里又细分为Eden区、From Survivor区、To Survivor区默认比例是8:1:1。新对象首先进入Eden区Minor GC时把存活对象复制到Survivor区每熬过一次GC年龄加一年龄达到阈值默认15就晋升到老年代。这就是分代收集的核心思想把内存按对象年龄分区用不同的回收策略处理。这个设计有一个很直观的原因绝大多数对象都是“朝生夕灭”的。你在一个方法里new一个StringBuffer拼接字符串方法执行完这个对象就没人引用了。让这类短命对象在新生代快速回收避免频繁把对象挪到老年代能显著降低GC压力。2.2 堆参数怎么调堆的大小决定了一个Java应用能容纳多少对象。调参主要围绕以下几个参数参数作用常见问题-Xms初始堆大小设置过大启动慢设置过小启动后频繁扩容-Xmx最大堆大小太小直接OOM太大影响操作系统其他进程-Xmn新生代大小过大会压缩老年代过小会导致对象频繁晋升-XX:SurvivorRatioEden区与Survivor区比例默认8即8:1:1不要轻易改动-XX:MaxTenuringThreshold晋升老年代的年龄阈值默认15CMS收集器可能调整为6实操过程中最常用的调法是在启动脚本里显式指定java -Xms512m -Xmx2048m -Xmn512m -XX:SurvivorRatio8 -jar your-app.jar这里要注意几点-Xms和-Xmx建议设为相同值避免运行期间堆扩大或缩小时带来的性能损耗和不确定性。JVM在扩容堆时需要向操作系统申请内存这是一个较重的操作在业务高峰期触发扩容很容易造成卡顿。-Xmn不是越大越好新生代太大老年代就相对变小大对象更容易触发Full GC。如果日志里频繁出现“GC (Allocation Failure)”并且耗时越来越长优先检查堆大小配置而不是急着优化代码。2.3 堆外内存也是个坑日常开发中还有一个容易忽略的地方——堆外内存。DirectByteBuffer、Map内存映射文件、Netty的Direct Buffer都使用堆外内存。这部分内存不归GC管大小通过-XX:MaxDirectMemorySize控制默认等于-Xmx。我在实际项目里遇到过一次诡异问题堆内存占用不高但进程整体内存占用不断上涨最后容器被系统OOM Killer杀掉。排查发现是Netty的堆外内存没有及时释放每一帧数据都申请了DirectBuffer但释放依赖Cleaner机制GC一直没触发堆外就越攒越多。排查这类问题时用jcmd命令可以查看堆外内存使用情况jcmd pid VM.native_memory summary不过要提前在启动参数里加上-XX:NativeMemoryTrackingsummary否则拿不到明细。3. 栈线程执行的“现场记录仪”如果说堆是JVM里的大仓库那栈就是每个线程手里的“便签本”。Java虚拟机栈描述的是Java方法执行的线程内存模型每个方法被执行时JVM都会同步创建一个栈帧用来存放局部变量表、操作数栈、动态链接、方法出口等信息。3.1 栈帧里到底有什么局部变量表是这个栈帧最核心的部分。你方法里定义的八种基本数据类型变量byte、short、int、long、float、double、char、boolean、对象引用reference、returnAddress类型都保存在局部变量表里。注意一个关键点局部变量表存储的是对象的引用不是对象本身。对象实体还是放在堆里。比如这样一段代码public void demo() { User user new User(张三); }这里的user是一个局部变量用8个字节的Slot存的是指向堆中User对象的内存地址而User对象本体包括它的name字段值张三全都在堆里。操作数栈可以理解为JVM的“算盘”。所有真正的数值运算比如int类型的加法都是先把操作数压入操作数栈然后执行iadd指令弹出两个数计算结果再压回去。动态链接则是为了支持方法调用符号引用在运行期需要转换为直接引用。3.2 栈溢出是怎么发生的栈最常见的异常是StackOverflowError也就是栈深度超过了JVM允许的最大深度。写递归没有终止条件是生产环境最常见的引发方式public void infiniteLoop() { while (true) { new Thread(() - { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); } }这段代码其实不会栈溢出会先触发线程数上限或内存OOM。真正触发栈溢出的是这种public void test() { test(); }每个线程的栈大小通过-Xss参数设置。但栈溢出多数情况下不是靠调大-Xss解决的而是代码逻辑有问题。把-Xss调大只是在拖延问题无休止的深度递归还会增加GC时间和CPU消耗。3.3 本地方法栈——容易被忽略的兄弟JVM规范里还有一个本地方法栈服务对象是JVM调用到的native方法。比如Thread.start()底层会调用start0()这个native方法执行时的栈就是本地方法栈。很多人在面试时被问到“本地方法栈的作用”第一反应就是“不知道没接触过”。实际上你每天都在用。比如System.currentTimeMillis()是native方法Object.hashCode()的默认实现也是native方法。HotSpot虚拟机把虚拟机栈和本地方法栈合二为一了所以从使用视角来说你不一定感知得到它但理解概念仍然重要。3.4 程序计数器——最小的内存区域还有一块叫程序计数器是所有区域里最小的一块也是唯一一个在规范里没有规定OOM情况的区域。它存储的是当前线程执行的字节码行号指示器。多线程切换时每个线程都需要独立的程序计数器才能恢复到刚才执行的位置。它只占用很小的内存空间平时不需要特别关注。4. 方法区类信息的“档案馆”方法区存储的是已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。在JDK8之前方法区的实现叫永久代PermGen它位于JVM堆内受JVM堆大小限制。JDK8开始永久代被移除取而代之的是元空间Metaspace。4.1 永久代到元空间的变迁逻辑为什么要从永久代换到元空间最核心的原因是永久代的大小难以预测太容易触发OOM。典型场景就是动态生成类特别多的框架比如CGLIB代理、JSP编译、Spring AOP。在JDK7时代一个稍复杂的Web应用部署后就可能报OutOfMemoryError: PermGen space只能靠调大-XX:MaxPermSize解决治标不治本。元空间最大的变化是不再使用JVM堆内存改用了本地内存。默认情况下元空间的容量只受操作系统可用内存限制这给了动态生成类的框架极大的喘息空间。4.2 方法区里存了什么具体来说方法区里主要包括以下几类数据类的元信息类名、访问修饰符、父类、接口、字段描述、方法描述。运行时常量池存放编译期生成的各种字面量和符号引用。静态变量注意JDK7之后静态变量被移到了堆中但逻辑上仍然属于方法区规范的一部分。即时编译器编译后的代码比如热点方法被JIT编译为机器码后缓存也在方法区。我以一个实际例子来解释运行时常量池。你写String a hello;这个hello字符串在类加载时放入运行时常量池。如果这时你用new String(hello)JVM会先看常量池里有没有hello有就返回引用没有才在堆里创建对象。这也是为什么字符串字面量的比较有时返回true的原因之一。4.3 方法区参数调优虽然元空间默认不受上限约束但生产环境不设限不等于万事大吉。如果代码存在类加载器泄漏比如每次热部署都创建新的类加载器且不释放元空间会被不断撑大最终把整个服务器的内存耗尽。常用的元空间参数-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512mMetaspaceSize不是初始容量而是触发Full GC的阈值。当元空间使用量超过这个值JVM会触发一次Full GC来清理不再需要的类信息。调优建议是MetaspaceSize和MaxMetaspaceSize设置为相同值避免动态扩容带来的性能抖动。4.4 还应该关注字符串常量池的位置JDK7之前字符串常量池在永久代JDK7开始被移到了堆中。这一改动影响很大原来字符串常量池里的字符串无法被GC回收频繁创建字符串字面量容易导致PermGen OOM。挪到堆之后字符串常量池可以由GC统一管理内存利用率更高。面试如果被问到“字符串常量池在哪个区域”你可以答出JDK7之后在堆中同时要解释为什么挪出来——因为永久代空间有限GC效率低而字符串常量池又需要频繁进行内存分配和回收。5. 堆、栈、方法区的协同工作与排查实战前面讲完了各个区域的概念现在把它们串起来理解一次对象创建的完整流程。这一步做好了你会对JVM内存有质的认识。5.1 一个对象从创建到使用的内存轨迹执行User user new User(张三)时JVM做了这些事情类加载阶段检查User类是否已加载。如果没有类加载器读取User.class把类的元信息存入方法区元空间并在堆中创建唯一的Class对象。分配内存在堆的Eden区划分一块内存空间给这个新对象。内存空间清零JVM把这块内存区域的字段初始化为零值保证实例字段有确定初值。设置对象头记录对象所属类、哈希码、GC分代年龄、锁状态等信息。构造方法执行调用User的构造方法张三字符串从常量池或新建String对象赋给name字段赋值完成。在这个流程中方法区提供了“模板”类信息堆提供了“实体存储空间”栈中的局部变量表保存了“对象的引用地址”。三者缺一不可。方法执行完毕后栈帧被弹出user这个局部变量随之消失堆里的User对象如果没有其他引用就变成了垃圾等Minor GC时被回收如果对象熬过了多次GC就被晋升到老年代。5.2 实操用IDE调整JVM运行内存排查OOM在本地开发时IDEA默认给应用的堆内存可能很小遇到大集合处理、频繁创建对象容易出现OutOfMemoryError: Java heap space。调整方法有两种一种是在Run Configuration的VM options里加参数只对当前配置有效。另一种是在IDEA安装目录的bin文件夹下修改idea64.exe.vmoptions影响IDE本身的启动内存。我在实际开发中建议给自己的服务启动配置加上这些参数-Xms512m -Xmx1024m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump/这里最关键的是-XX:HeapDumpOnOutOfMemoryError。一旦发生OOMJVM会自动生成一份堆转储文件你拿着这份文件用MAT或者VisualVM分析能直接看到哪些对象占用了大量内存。很多线上问题都是靠这个参数留下的现场抓到真凶的。5.3 如何快速定位堆占用过高的对象假设你已经拿到了heap dump文件用MAT打开后重点关注Histogram视图。我查找内存泄漏的习惯步骤是看Histogram里占用总量前几名的类一般是byte[]、String、HashMap$Node这类。右键某个类选择“Merge Shortest Paths to GC Roots”排除弱引用和软引用看哪个对象被强引用链挂着。顺着引用链往上找大概率能定位到某个业务类持有了一堆不该持有的数据。有一次在线上排查内存溢出发现byte[]占用极高Merge Shortest Paths后找到根源是某个定时任务把一个大文件的全部字节加载进内存处理完后没有释放引用。这个问题靠肉眼很难发现但用MAT配合heap dump三分钟就定位了。6. 常见问题与排查技巧实录速查表面试和实战中最常遇到的内存区域相关的问题我整理成一个速查表方便你随时翻看。问题场景可能原因排查方向堆内存持续增长且GC回收效果差存在对象泄漏对象被意外持有引用生成堆转储分析GC Roots老年代频繁Full GC新生代太小对象过快晋升或者代码中大量产生长生命周期对象调整分代比例检查缓存、全局集合频繁报StackOverflowError递归无终止条件、过深的方法调用链检查递归代码调整-XssMetaspace OOM类加载器泄漏、动态生成类过多查看类加载统计定位未卸载的类加载器堆使用不高但进程内存很大堆外内存使用过多NMT检测堆外内存检查DirectBuffer、Netty字符串大量重复且占用高未使用String.intern或常量池管理不当分析String对象去重、启用String Deduplication启动后很快OOM-Xmx设置过小或初始化加载数据过多查看启动日志调整堆大小6.1 面试高频问题堆和栈的区别面试中这题必问。你可以从以下几个维度作答存储内容堆存储对象实例和数组栈存储局部变量、方法调用信息。线程共享性堆是线程共享的栈是线程私有的。空间大小堆可以设置到很大比如几十GB栈一般只有几百KB到几MB。生命周期堆里的对象由GC负责回收栈帧随方法调用结束自动销毁。异常类型堆内存不足抛OOM栈深度超标抛StackOverflowError。回答时可以顺手举一个例子比如new User()说明User对象实体在堆中User变量引用在栈中这样考官会认为你真的理解了而不是背书。6.2 栈与堆的配合对并发编程的影响因为栈是线程私有的所以局部变量天然线程安全。多线程并发操作同一个堆中的对象时就会产生竞态条件。这也是为什么局部变量在多线程环境下不需要加锁而不是线程安全问题的关键原因。public void method() { int count 0; // 栈中每个线程独立安全 HashMap map new HashMap(); // 堆中多线程共享不安全 }很多人高并发时疯狂加锁但没想过哪块内存是冲突根源。这里多提一嘴如果是全局唯一的对象比如Spring管理的单例Bean它们都在老年代或者堆里天然是线程共享的。如果你把局部变量用static修饰它就从栈挪到堆里线程安全问题立刻出现。6.3 区分JVM内存结构和Java内存模型很多初学者把JVM内存区域和Java内存模型搞混。我这里明说JVM内存区域划分讲的是数据存哪儿堆、栈、方法区这个物理分区的概念**Java内存模型JMM**讲的是多线程编程中共享变量的可见性、有序性、原子性规则它关注的是主内存和工作内存之间的交互协议。JMM与JVM的内存区域划分没有直接对应关系这是两个不同维度的概念。如果你回答面试题“谈谈JVM内存模型”最好先问清楚对方指哪种。如果泛指建议把内存区域划分放前面JMM放后面二者都覆盖到最稳妥。6.4 堆内存参数调整的最佳实践这里分享一套我在生产环境常用的大小估算方法。一个Java服务的堆大小推荐取JVM进程最大可用内存的50%到60%。比如你的容器限制是4GB内存堆建议不超过2.5GB。剩下的留给元空间、线程栈、堆外内存、JIT编译器开销。为什么不能把堆占到80%因为JVM本身运行也需要开销线程栈占用的是进程内存但不是堆内存而且GC算法在堆接近满的时候会更频繁地运行反而降低吞吐量。实践下来堆占整个容器内存的60%是一个比较均衡的数值既给了对象足够的空间又不会挤压其他部分。如果你用容器部署Java10以上的版本建议开启-XX:UseContainerSupport这个参数让JVM自动识别容器内存限制从而合理自适应堆大小防止在容器里把宿主机内存打满。还有一个参数值得一试-XX:UseG1GCG1是JDK9之后的默认垃圾回收器适合大堆场景4GB以上它能比较好地平衡停顿时间和吞吐量。如果你的应用还在用Parallel GC而且在不断调优考虑迁移到G1能省很多心。7. 写在最后的实际排查经验关于JVM内存区域我踩过不少坑有几个体会必须分享。第一个是线上环境一定要加HeapDumpOnOutOfMemoryError并且把dump文件落盘到一个磁盘空间足够的位置。很多团队等内存溢出发生后才后悔没留现场。OOM不是最可怕的最可怕的是OOM了却不知道为什么。第二个是不要神化调优。大多数业务系统的性能瓶颈根本不在JVM内存区域配置上而是代码写得有问题——比如一次性加载全表数据进内存、for循环里不断new对象、坚持用String拼接而不考虑StringBuilder。先把代码写好再谈调优才有意义。第三个是熟悉常用排查命令。jstat -gcutil看GC比例jmap -heap看堆配置jstack看线程状态jcmd GC.class_histogram看类占用。这些命令学起来很快但关键时刻比什么工具都好使因为生产环境往往没有图形化界面。如果你想深入验证自己对内存区域的理解最好的方式是找一个线上疑难问题先根据现象猜原因再用排查命令和dump分析去验证。多来几轮你就能成为团队里的JVM问题终结者。
