JVM 内存结构概述：堆、栈、方法区

我之前帮团队排查过一个线上服务频繁 Full GC 的问题。现象很简单——每次大促流量上来，老年代就涨得飞快，GC 日志里 Full GC 间隔从半小时缩短到三分钟。我一开始怀疑是代码里 new 了太多短命对象，结果 Heap dump 一分析，发现有一张“永不释放”的 HashMap 挂在某静态变量下，把几万条业务数据全缓存了。嗯，这就是典型的“后台任务未释放引用”导致的 GC 抖动。要真正理解这类问题，咱们得先把 JVM 的内存结构摸透。

堆（Heap）—— 对象的“大本营”

堆是 JVM 管理中最大的一块内存区域，几乎所有的对象实例和数组都在这里分配。说白了，你写的 new Something()，最终都落在堆上。线程共享，所以也是 GC 的主战场。

我个人习惯把堆比作一个“公共仓库”——任何线程都能往里放东西，但管理权归 GC。堆分代（年轻代、老年代）是为了提升回收效率，但这个细节我们后面再聊。今天重点是：只要有一个引用还活着，这个对象就赖在堆里不走。

栈（Stack）—— 线程的“私人工作台”

每个线程都有自己的虚拟机栈。栈里存的是栈帧（Stack Frame），每个方法调用对应一个栈帧。栈帧里包含了局部变量表（存放基本数据类型和对象引用）、操作数栈、动态链接和返回地址。

你想想看，局部变量里的对象引用本身存放在栈里，但引用指向的实际对象还是躺在堆里。这意味着：如果一个栈帧长期不被弹出（比如 while 循环里有个大局部变量没释放），这个引用就会让堆里的对象一直活着。我记得有一次排查一个 Web 服务内存泄漏，发现是某个 Filter 里定义了一个 List，每次请求都往里面 add 数据，但 Filter 实例被单例持有，List 从来没被清空——这就是栈引用（其实是通过实例字段间接引用）把堆对象拖死了。

方法区（Method Area）—— 类信息的“档案馆”

方法区存放的是类信息（类名、字段、方法描述）、常量、静态变量、JIT 编译后的代码等。在 Java 8 之后，它被“元空间（Metaspace）”取代，从堆外移到了本地内存。但概念上，它仍然是逻辑上的“方法区”。

这里容易踩的坑是：静态变量引用了堆里的对象。比如一个静态的 List<Task>，后台线程不断往里塞任务对象，但没有任何清理逻辑。这些对象被静态变量引用，GC 永远无法回收。我见过一个极端案例：某配置中心基类里定义了一个静态的 Map<String, Object>，用来缓存全量配置，结果因为配置项不停变更，旧值没有被 remove，导致老年代持续增长——最终 OOM。你看，方法区本身不直接存对象实例，但它的静态变量可以“勾着”堆里的对象，让它们变成 GC Root。

一张表总结三区特征

内存区域	线程共享？	存储内容	生命周期	GC 影响
堆（Heap）	是	对象实例、数组	由可达性决定	GC 主要工作区，抖动源头
栈（Stack）	否（每个线程私有）	局部变量、操作数栈、方法返回地址	与线程/方法调用一致	引用泄露导致堆对象无法回收
方法区（Metaspace）	是	类信息、常量、静态变量、JIT代码	类卸载或 JVM 关闭	静态引用可“锚定”堆对象

整体结构图

下面这张图梳理了 JVM 三大内存区域之间的关系，以及常见引用路径。看清楚这个图，你就能理解为什么后台线程的局部变量或静态变量一旦没释放，堆里的对象就永远无法被回收。

实践中的关键点

• 栈引用：线程内部的局部变量如果生命周期过长（比如长循环、线程池中线程一直存活并持有引用），会导致大量堆对象无法回收。
• 静态引用：后台任务往往通过单例或静态容器（如 static List、static Map）累积数据，这是最常见的 GC 抖动来源。
• 方法区元空间：虽然元空间不再受限堆大小，但类的加载和卸载依然影响整体内存。如果动态生成类（比如 CGLIB 代理）未及时清理，也会导致元空间泄漏，间接引发 GC 压力。