JVM的内存模型、垃圾回收机制和性能优化，本质上是一套“让对象活得好、死得干脆、停顿更短”的分治策略：内存划分决定对象的存身之处，GC负责清理无用对象，优化则是根据业务场景调整参数，最终在吞吐量和延迟之间找到平衡。 如果你正在排查线上OOM，或者准备JVM调优面试，这篇文章会把三者的底层逻辑串成一条线。
JVM内存模型详解：堆、栈与方法区到底怎么分工？
JVM内存模型也叫运行时数据区,按线程是否共享分成两类，线程私有的有程序计数器、虚拟机栈、本地方法栈；线程共享的只有堆和方法区，几乎所有GC和性能问题都发生在这几个区域，搞懂分工是调优的第一步。
堆：对象存储的主战场
堆是JVM管理内存中最大的一块,所有new出来的对象都在这里分配，堆内部又分年轻代和老年代，年轻代再拆成Eden区和两个Survivor区，大部分对象先进Eden区，经过一轮轮Minor GC后仍然存活的对象，才会晋升到老年代。
- 年轻代：存储短命对象，GC频繁，回收成本低。
- 老年代：存储长命对象或超大对象，GC频率相对低。
- Eden区：新对象分配入口，空间不够时触发Minor GC。
- Survivor区：存放每轮GC后存活下来的对象，两个区交替使用。
如果你写过一个高并发接口,会发现每秒创建大量临时对象，Eden区反复被填满，这时候堆大小和GC频率的关系会直接影响接口延迟。
虚拟机栈：线程的私有空间
每个线程启动时会创建一个栈,内部由多个栈帧组成，每个栈帧对应一次方法调用，栈帧里保存局部变量、操作数栈、方法返回地址等，递归调用太深时，会因为栈空间不足抛出StackOverflowError，栈上的数据不需要GC操心，方法执行完栈帧弹出就是回收。
方法区与元空间
方法区存放类元信息、运行时常量池、静态变量等，JDK8之前叫永久代，JDK8开始改为元空间，直接使用本地内存，两者最大的区别是元空间不再受堆内存上限约束，默认可以无限增长，但你仍可以通过-XX:MaxMetaspaceSize设置上限，避免类加载过多把物理内存耗尽。
直接内存
严格说直接内存不属于JVM运行时数据区,但Java NIO的堆外内存会用到它，它由操作系统分配，脱离堆限制，适合大块数据读写，Netty这类高性能网络框架底层就依赖直接内存，你调优时如果遇到OutOfMemoryError: Direct buffer memory，就要重点查这块。
Java垃圾回收机制有哪些？从分代收集到G1
垃圾回收机制的核心任务是识别不存活的对象,释放堆内存，这个过程需要暂停工作线程，也就是我们常说的STW（Stop The World），不同的垃圾收集器，本质就是如何在停顿时间和回收效率之间做取舍。
对象存活的判断：可达性分析
主流JVM使用可达性分析算法,从一组称为GC Roots的根节点出发，沿着引用链扫描，所有能被访问到的对象都标记为存活，其余对象判定为可回收，GC Roots包括栈帧中的局部变量、静态变量、JNI引用、活跃线程等，引用计数法虽然简单，但解决不了循环引用问题，所以现代JVM已经放弃。
分代收集：绝大多数Java应用的默认策略
行业共识认为,大部分对象“朝生夕灭”，活过几次GC后变成老顽固，所以JVM把堆分成年轻代和老年代，年轻代用复制算法，每次只复制少量存活对象，成本极低；老年代用标记-清除或标记-整理算法，避免内存碎片，这就是分代收集理论。
主流垃圾收集器对比
| 收集器 | 线程模式 | 核心特点 | 适用场景 |
|---|---|---|---|
| Serial | 单线程 | 实现最简单，停顿长 | 客户端小应用 |
| Parallel | 多线程 | 吞吐量优先 | 后台批处理、离线计算 |
| CMS | 并发多线程 | 低延迟，易产生碎片 | 面向用户的Web服务 |
| G1 | 并发多线程 | 堆分区块，可预测停顿 | JDK9+默认，大堆服务 |
| ZGC | 并发多线程 | 停顿极短，支持超大堆 | 追求极致低延迟场景 |
G1最大的特点是把堆划分成一个个Region,不再强制固定年轻代和老年代，它会根据你设定的-XX:MaxGCPauseMillis目标停顿时间，动态调整每个区域的角色，所以用G1时，调参方式和传统分代GC不太一样。
垃圾回收调优的底层逻辑
调优不是选最贵的收集器,而是选最匹配业务的那一个，如果是夜间跑的数据分析任务，用户不感知停顿，Parallel把吞吐量拉满就行，如果是每秒几千请求的支付接口，停顿几十毫秒都可能引发超时，CMS或G1更稳妥，ZGC适合堆上G的极大规模场景，但版本和操作系统兼容性要求高。
JVM性能优化参数怎么调？场景化调优流程与常用命令
性能优化到底优化什么？简单说就两个指标：吞吐量和停顿时间，吞吐量等于用户代码运行时间占总时间的比例，停顿时间就是单次GC让应用冻结的耗时，Web应用更在乎停顿，离线任务更在乎吞吐，这两者在参数上往往是矛盾的。
常用JVM参数一览
先记住这些核心参数,后面排查问题时你会反复用到：
-Xms和-Xmx：设置堆初始大小和最大大小，生产环境建议设置成相同值，避免堆扩容引发额外开销。-XX:NewRatio：设置年轻代与老年代比例，-XX:NewRatio=2表示老年代是年轻代的2倍。-XX:SurvivorRatio：设置Eden和Survivor的比例，默认值是8，表示Eden占年轻代的8/10。-XX:MaxGCPauseMillis：G1垃圾回收器的目标停顿毫秒数，设置后G1会朝这个目标调整区域回收策略。-XX:MetaspaceSize和-XX:MaxMetaspaceSize：控制元空间初始和最大容量，防止无限膨胀。
实操：用命令行工具定位GC问题
调优不能靠猜,要先用工具看现象，最常见的命令组合有这些：
jstat -gcutil <pid> 5 1000：每5秒输出一次GC各区域的利用率，直接观察Minor GC和Full GC频率。jmap -heap <pid>：查看当前堆内存各区域占用，确认内存分配是否符合预期。jmap -dump:format=b,file=heap.hprof <pid>
：导出堆快照，配合MAT分析对象引用链。
jstack <pid>：查看线程栈，排查死锁、长阻塞、线程数异常。
频繁Full GC导致接口变慢
假设你负责的订单服务上线后,突然出现大量超时，先跑jstat -gcutil看老年代占用率，如果老年代一直高居不下，说明有对象常年被根引用挂着，再执行jmap导出堆快照，用MAT检查是否有一个静态Map存放了所有订单对象，或者数据库连接没有释放，这种问题改代码释放引用比调大堆内存更有效，因为调大堆只是延迟问题爆发。
堆内存设置过大导致慢启动
另一个反面案例是盲目加堆,堆太大让单次GC扫描区域变长，年轻代每次复制开销也会上升，更糟的是物理内存不足时触发操作系统换页，性能断崖式下跌，正确做法是先估算实例内存上限，再根据业务对象存活率确定年轻代和老年代比例，对象快速创建销毁的服务，适当加大年轻代；对象存活时间长的服务，加大老年代更合理。
关于JVM内存模型与垃圾回收机制的常见问题解答
JVM内存模型和垃圾回收机制有什么关系？
JVM内存模型中的堆是垃圾回收的主要活动区域,栈和方法区各有自己的生命周期方式，不参与GC，堆内部划分年轻代和老年代，是为了匹配分代收集理论，让兜售不同的回收算法各司其职，所以理解内存模型是理解GC的前提。
JVM性能优化有哪些常见误区？
常见误区包括堆大小设置得越大越好、直接换成G1就以为万事大吉、忽略元空间上限，实际上调优必须先定位是内存泄漏还是分配过快，再结合业务对延迟的容忍度选参数，单纯堆参数解决不了代码层面的持有引用问题。
Full GC频繁时怎么排查？
先通过jstat -gcutil确认老年代和元空间使用率，再用jmap dump导出堆快照，分析哪些对象占据最多内存，重点排查静态集合、长期运行线程的ThreadLocal字段、未关闭的外部资源连接，找出根引用后释放对象，或者调整老年代容量，Full GC频率才会真正降下来。