规范 ≠ 实现
Specification ≠ implementation
JVM 规范描述运行时数据区的职责；“年轻代、老年代、TLAB”等通常是 HotSpot 与具体收集器的实现策略。
The JVM specification describes runtime data areas. Young/old generations and TLABs are typically HotSpot and collector implementation strategies.
JAVA RUNTIME核心概念 · CORE CONCEPTS
How Java
memory works.读懂 JVM
内存管理。
一份从“内存在哪里”到“垃圾如何被回收”的双语图解指南。读完后，你将能把对象分配、线程栈、类元数据、GC 与常见故障串成一张完整地图。
A visual, bilingual guide from where memory lives to how garbage is reclaimed. Connect object allocation, thread stacks, class metadata, GC, and common failures into one coherent map.
开始阅读 · Start learning ↓约 12 分钟
~12 MIN READ
~12 MIN READ
FIG. 01ONE JVM PROCESS / 一个 JVM 进程
OS PROCESS BOUNDARY · 操作系统进程边界
共享 / SHARED线程私有 / PER THREAD本地 / NATIVE
01总览Overview02内存区域Memory areas03对象旅程Object journey04垃圾回收Garbage collection05故障诊断Diagnostics06心智模型Mental model
01 — THE BIG PICTURE
先分清三件事Start with three distinctions
堆 ≠ 全部内存
Heap ≠ total memory
进程还使用线程栈、元空间、代码缓存、直接内存、JNI 与 GC 自身的数据结构。
The process also uses thread stacks, metaspace, code cache, direct memory, JNI, and the collector’s own data structures.
不可达 ≠ 立即释放
Unreachable ≠ instantly freed
对象不可达后只是具备回收资格；何时、以何种方式回收，由垃圾收集器决定。
An unreachable object is merely eligible for reclamation. The collector decides when and how that memory is recovered.
02 — RUNTIME DATA AREAS
内存区域，不止一个“堆”Memory is a set of regions
堆（Heap）Heap
绝大多数对象实例和数组在这里分配，由垃圾收集器管理。常见 HotSpot 配置会按对象年龄组织年轻代与老年代，但这不是 JVM 规范强制规定的物理布局。
Most object instances and arrays are allocated here and managed by the garbage collector. Common HotSpot configurations organize it into young and old generations, but that physical layout is not mandated by the JVM specification.
ASK YOURSELF谁拥有它？谁释放它？耗尽时抛出什么错误？Who owns it? Who releases it? What fails when it is exhausted?
03 — AN OBJECT’S JOURNEY
一个对象的一生The life of an object
申请空间
Request space
多数小对象先尝试在线程本地分配缓冲区（TLAB）中快速分配。
Most small objects first try a fast allocation in the thread-local allocation buffer (TLAB).
进入年轻代
Enter young gen
新对象通常从 Eden 开始；大对象或特定收集器可能采用不同路径。
New objects commonly begin in Eden; large objects or particular collectors may take another path.
接受可达性判定
Reachability test
GC 从根集合出发追踪引用；未被触达的对象成为垃圾。
GC traces references from roots; objects not reached become garbage.
存活与晋升
Survive and age
多次年轻代回收后仍存活的对象，可能被晋升到老年代。
Objects surviving repeated young collections may be promoted to the old generation.
回收或整理
Reclaim or compact
收集器释放空间，并可能复制或压缩存活对象以降低碎片。
The collector frees space and may copy or compact survivors to reduce fragmentation.
GC ROOTS · 根集合
“活着”的起点
Where “alive” begins
典型根包括活动线程栈中的引用、已加载类的静态字段引用、JNI 全局引用，以及 JVM 内部持有的引用。
Typical roots include references in active thread stacks, static fields of loaded classes, JNI global references, and references held internally by the JVM.
04 — GARBAGE COLLECTION
GC 真正做了什么？What does GC actually do?
1ROOTS确定起点 · establish roots
→
2TRACE / MARK追踪并标记 · find survivors
→
3RECLAIM回收垃圾 · free garbage
→
4MOVE?按需复制或压缩 · move if needed
Parallel GC
以较高吞吐量为主要目标，回收阶段通常使用多线程，但会产生停顿。
Prioritizes throughput and uses multiple GC threads, while still introducing stop-the-world pauses.
G1 GC
将堆划分为多个 Region，并围绕可预测停顿目标安排回收工作；它是常见的通用选择。
Divides the heap into regions and schedules work around pause-time goals; a common general-purpose choice.
ZGC / Shenandoah
将更多工作与应用线程并发执行，以降低停顿；代价是额外 CPU、内存和运行时开销。
Perform more work concurrently with the application to reduce pauses, at the cost of CPU, memory, and runtime overhead.
重要 / IMPORTANT具体可用的收集器、默认选择和行为取决于 JDK 发行版与版本。先基于延迟目标、吞吐量和堆大小建立假设，再用真实负载测量。Collector availability, defaults, and behavior depend on the JDK distribution and version. Start from latency, throughput, and heap-size goals—then measure with a representative workload.
05 — FAILURE PATTERNS
从错误反推内存区域Let the failure locate the region
信号 / SIGNAL通常指向 / LIKELY AREA第一步 / FIRST CHECK
OutOfMemoryError: Java heap space堆 · Heap
检查存活集、分配速率、堆转储与 GC 日志。
Inspect the live set, allocation rate, heap dump, and GC logs.
OutOfMemoryError: Metaspace元空间 · Metaspace
检查类数量、动态生成类，以及类加载器是否泄漏。
Inspect class count, generated classes, and class-loader leaks.
StackOverflowError线程栈 · Thread stack
检查无限递归、过深调用链和单个栈帧大小。
Look for unbounded recursion, deep call chains, and large frames.
OutOfMemoryError: Direct buffer memory直接内存 · Direct memory
检查 NIO 缓冲区生命周期、池配置与堆外上限。
Inspect NIO buffer lifetimes, pool configuration, and off-heap limits.
Process RSS keeps rising整个进程 · Whole process
对照堆、线程数、元空间、代码缓存、直接内存与本地库。
Reconcile heap, thread count, metaspace, code cache, direct memory, and native libraries.
OBSERVATION KIT · 观察工具箱
Measure → explain → change
jcmd <pid> GC.heap_info
jcmd <pid> VM.native_memory summary
jstat -gcutil <pid> 1s
-Xlog:gc*命令与选项的可用性取决于 JDK。生产环境中使用前，请查看对应版本的文档并评估开销。
Command and option availability depends on the JDK. Check the matching version’s documentation and evaluate overhead before production use.
06 — THE MENTAL MODEL
带走这张检查清单Keep this checklist
遇到任何 Java 内存现象时，不要先猜 GC 参数。先定位区域、所有权与生命周期，再验证回收路径和实际证据。
When Java memory behaves unexpectedly, do not begin by guessing GC flags. Locate the region, ownership, and lifetime—then verify the reclamation path with evidence.
- 01内存位于哪个区域？Which memory region is involved?
- 02它是共享的还是线程私有的？Is it shared or thread-private?
- 03谁分配它，谁负责释放？Who allocates it, and who releases it?
- 04什么引用让对象继续存活？What reference keeps the object alive?
- 05日志、转储与指标是否支持假设？Do logs, dumps, and metrics support the hypothesis?