jvm内存管理是分层分区、分代协作的精密机制：堆为线程共享的对象分配与gc核心，分新生代（eden+s0/s1）和老年代；元空间（取代永久代）存储类元数据，默认无上限但需限制；虚拟机栈与程序计数器线程私有，分别支撑方法执行与指令定位；gc roots是可达性分析起点，决定对象存活与否。
JVM内存管理系统不是简单的“分配+回收”，而是一套分层、分区、分代且线程协作的精密机制。它既要屏蔽底层操作系统差异，又要支撑Java跨平台与自动内存管理两大核心能力，理解它关键在于抓住区域职责、共享属性、生命周期和调优锚点四个维度。
堆：对象分配与GC的核心战场
堆是JVM中最大、最动态的内存区域，所有对象实例和数组都在这里分配。它是线程共享的，也是垃圾回收器（GC）唯一主动管理的区域。
- 按分代模型划分为新生代（Eden + 两个Survivor区）和老年代，不同代采用不同回收算法——新生代用复制算法（快、低碎片），老年代多用标记-整理或标记-清除（兼顾空间与吞吐）
- 堆大小由-Xms（初始）和-Xmx（最大）控制；建议两者设为相等，避免运行时扩容带来的STW停顿
- 新生代大小通过-Xmn单独设定；合理比例（如Eden:Survivor=8:1:1）能减少Minor GC频率和对象过早晋升
- 大对象（如大数组）可能直接进入老年代，触发提前Full GC；可通过-XX:PretenureSizeThreshold干预
方法区（元空间）：类元数据的持久化容器
JDK 8起，永久代被移除，取而代之的是使用本地内存（Native Memory）的元空间（Metaspace）。它存储类结构、常量池、静态变量、JIT编译代码等，不再受JVM堆大小限制。
- 元空间默认无上限，但过度加载类（如热部署、大量反射、动态代理）会导致本地内存耗尽，引发OutOfMemoryError: Metaspace
- 通过-XX:MetaspaceSize（初始阈值）和-XX:MaxMetaspaceSize（硬上限）进行约束，避免无节制增长
- 类卸载依赖于类加载器的可达性，只有当类加载器本身被回收，其加载的类才能被卸载——这是元空间内存释放的前提
栈与程序计数器：轻量级、线程私有的执行支撑
虚拟机栈保存每个方法调用的栈帧，含局部变量表、操作数栈等；程序计数器则记录当前线程执行到哪条字节码指令。二者均为线程私有，随线程创建/销毁而生灭。
- 栈深度超限（如无限递归）抛出StackOverflowError；线程过多或单个栈过大（-Xss设置过高）可能导致OutOfMemoryError
- -Xss参数控制单线程栈大小，默认通常为1MB；高并发场景下可适当调小（如256K），以支持更多线程，但需避开深层调用链
- 程序计数器是JVM中唯一不会发生OOM的区域，也是实现线程切换后精准恢复执行位置的基础
GC Roots与对象存活判定：回收逻辑的起点
JVM不靠引用计数，而是采用可达性分析算法判断对象是否存活。从一组称为GC Roots的对象出发，沿着引用链向下搜索；无法到达的对象即为可回收对象。
- 典型GC Roots包括：虚拟机栈中引用的对象、本地方法栈中JNI引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象、被同步锁持有的对象
- Finalizer机制已废弃（Java 9起标记为deprecated），不应依赖finalize()做资源清理；应使用try-with-resources或Cleaner替代
- 软引用（SoftReference）、弱引用（WeakReference）、虚引用（PhantomReference）提供不同强度的引用语义，用于缓存、监听、资源清理等场景
