Java程序在JVM中的内存流向本质是数据按语义和生命周期自动分配到不同运行时区域的过程，关键看“谁创建、存什么、放哪、何时清”：基本类型局部变量存虚拟机栈的局部变量表，对象引用存栈、对象实例存堆，字符串字面量存堆中字符串常量池，类信息与静态变量值存元空间和堆（JDK8+），方法调用对应栈帧入栈出栈，对象创建于Eden区，经GC Roots可达性判定存活，最终由分代GC回收；StackOverflowError表明栈溢出，OutOfMemoryError则分别指向堆、元空间或本地线程资源耗尽。
Java 程序在 JVM 中的内存流向，本质是数据按语义和生命周期被自动分配到不同运行时区域的过程。分析它不需要从头背结构，而是抓住“谁创建、存什么、放哪、何时清”这四个关键点。
变量和对象分别住哪？看声明位置和类型
代码中每个变量或对象的落脚地，由它的性质决定：
-
基本类型局部变量（如
int a = 5;）→ 存在当前线程的虚拟机栈中，具体在栈帧的局部变量表里 -
对象引用（如
User user;）→ 引用本身存在栈上，但引用指向的对象实例（new User()）一定在堆中（极少数优化场景如逃逸分析后可能栈上分配，但属例外） -
字符串字面量（如
"hello"）→ JDK7+ 起存在堆中的字符串常量池，不是方法区 -
类信息、方法字节码、静态变量（
static int count;）→ 类加载后，元数据进元空间，而静态变量的实际值（非引用）也存于堆中（JDK8+ 已迁移）
方法调用时，栈帧怎么流转？
每次方法执行，都是一次栈帧的入栈与出栈过程，反映的是控制流和数据流的同步：
- 调用
main()→ 创建第一个栈帧，压入当前线程的虚拟机栈 - 在
main()中调用doWork()→ 新建栈帧，压入栈顶；局部变量、形参、操作数栈独立开辟 - 执行
doWork()内部的new String("abc")→ 对象分配在堆，引用存入该栈帧的局部变量表 - 方法返回 → 当前栈帧弹出，其中所有局部变量失效，操作数栈清空，控制权交还给上层栈帧
对象从创建到回收，路径清晰可追踪
一个典型对象的生命周期在内存中体现为跨区域协作：
-
诞生：执行
new指令 → JVM 在堆的 Eden 区分配内存（若开启 TLAB，则在线程本地缓冲区快速分配） -
关联：构造方法执行 → 初始化成员变量，若含新对象（如
this.name = new String(...)），再次触发堆分配 - 存活：只要还有GC Roots 可达的引用链（例如栈中引用、静态字段、其他活对象引用），对象就留在堆中
- 回收：当引用断开且 GC 触发 → 根据分代规则（年轻代 Minor GC / 老年代 Major GC）清理不可达对象，释放堆空间
异常报错是内存流向的“路标”
报错类型直接对应问题发生的内存区域，是反向验证流向的关键线索：
-
StackOverflowError→ 虚拟机栈溢出，通常是递归太深或方法调用链过长，说明栈帧堆积失控 -
OutOfMemoryError: Java heap space→ 堆无法分配新对象，可能是内存泄漏、缓存未清理或堆设置过小 -
OutOfMemoryError: Metaspace→ 元空间耗尽，常见于大量动态类生成（如 Spring Boot 热部署、字节码增强框架） -
OutOfMemoryError: unable to create new native thread→ 本地方法栈或线程创建失败，往往因系统级线程数超限，而非 JVM 参数配置问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
