JVM垃圾回收主要针对堆内存，因对象生命周期与应用一致且需动态管理；方法区（元空间）仅极少量类元数据可卸载；线程私有区域（栈、程序计数器等）随线程结束自动释放，无需GC介入。
JVM 内存区域中，并非所有区域都需要垃圾回收，回收行为与各区域的生命周期、用途和线程可见性密切相关。真正需要 GC 主动介入的，其实只有少数几个区域。
堆区是垃圾回收的核心目标
堆（Heap）是所有线程共享的内存区域，对象实例几乎全部在此分配。它的大小动态可调，生命周期与应用一致，不会随方法或线程结束自动释放。因此：
- GC 主要工作对象就是堆中的“无用对象”——即不再被任何 GC Roots 可达的对象
- 堆进一步划分为新生代（Eden + 两个 Survivor）和老年代，对应不同回收频率和算法：新生代频繁发生 Minor GC，老年代触发 Full GC（或 G1/MetaSpace 等新型回收）
- 对象从新生代晋升到老年代有明确规则（如年龄阈值、Survivor 区空间压力、大对象直接分配等）
方法区（元空间）回收范围非常有限
JDK 8 后，永久代（PermGen）被元空间（Metaspace）取代，类元数据存储在本地内存中，而静态变量、常量池等内容已移至堆中。这意味着：
- 元空间本身不直接存放 Java 对象，主要存类的结构信息（Class 对象、方法字节码、符号引用等）
- 类卸载仅在特定条件下发生（如自定义类加载器被回收、对应的 Class 对象不可达），实际极少触发
- 常量池中字符串常量（如 intern 字符串）若不再被引用，可能被回收，但概率低、影响小
线程私有区域基本无需 GC 干预
程序计数器、虚拟机栈、本地方法栈属于线程私有，其内存分配与释放完全由线程生命周期决定：
- 每个方法调用生成一个栈帧，方法执行结束即自动出栈，对应内存立即释放
- 局部变量表中只存基本类型值或对象引用，引用本身不占堆空间；栈帧销毁后，引用消失，可能使堆中对象变为不可达
- 这些区域不存在“长期驻留的垃圾”，也不涉及跨线程共享，GC 完全不管理它们
直接内存和本地内存不在 JVM GC 范围内
通过 NIO 的 DirectByteBuffer 分配的直接内存，或 JNI 调用分配的本地内存，虽然由 JVM 管理申请逻辑，但：
- 不归属 JVM 运行时数据区，不受堆 GC 控制
- 依赖 Cleaner 或 finalize 机制间接释放，容易因疏忽导致内存泄漏
- 监控和排查需借助 native memory tracking（NMT）等工具，而非常规 GC 日志
