Java虚拟机（JVM）内存管理机制核心是自动管理：JVM负责对象内存分配与垃圾回收，程序员无需手动释放；内存分为线程私有区（程序计数器、虚拟机栈、本地方法栈）和线程共享区（堆、元空间），其中堆是GC主要区域，采用可达性分析法识别垃圾，通过分代收集与复制/标记-整理等算法回收。
Java 虚拟机（JVM）的内存管理机制，核心就一句话：**自动管内存，不用你操心“哪块该还、什么时候还”**。它不像 C/C++ 那样要程序员手动 new 之后再 free，而是由 JVM 在背后默默分配空间、识别垃圾、回收内存——你只管创建对象，剩下的交给它。
内存分几块？谁用谁的
JVM 把内存大致分成两类区域：
-
线程私有区：每个线程独享一份，随线程生而生、随线程死而死。包括：
– 程序计数器（记录当前执行到哪行字节码，最小最安全，不会 OOM）
– 虚拟机栈（方法调用时压栈帧，存局部变量、方法参数等；栈太深会 StackOverflowError，扩不出内存会 OutOfMemoryError）
– 本地方法栈（类似虚拟机栈，专供 native 方法用） -
线程共享区：所有线程共用，生命周期跟整个 JVM 一样长。主要包括：
– 堆（Heap）：几乎所有 new 出来的对象都住这儿，是 GC 主战场
– 元空间（Metaspace）：存类的结构信息（比如类名、字段、方法字节码），不在堆里，而是直接用本地内存
对象怎么分配？不是全在堆里
虽然规范说“对象实例都在堆上”，但 JVM 实际做了不少优化：
- 大多数小对象优先在 Eden 区（新生代的一部分）分配
- 超大对象（比如超长数组）可能直接进老年代，避免在新生代反复拷贝
- 某些逃逸分析后发现“这个对象只在当前方法里用、不会被其他线程看到”，JVM 可能干脆不给它分配堆内存，而是拆成基本字段放在栈上（栈上分配），甚至直接优化掉（标量替换）
垃圾是怎么被发现和清理的？
不是靠“谁还引用我”来算（引用计数法有循环引用的硬伤），而是用可达性分析：
- 从一组“根对象”出发（比如线程栈里的局部变量、静态变量、JNI 引用等），顺着引用链往下找
- 所有能被找到的对象标记为“存活”，找不到的就是垃圾
- 后续按算法清理：新生代常用复制算法（快、无碎片），老年代多用标记-整理或标记-清除
- GC 过程中，大部分收集器会暂停应用线程（Stop-The-World），所以频繁 GC 会影响响应速度
为什么很少写内存释放代码，却还会内存泄漏？
自动管理 ≠ 不会出错。泄漏往往是因为本该断掉的引用还留着，让垃圾回收器误以为对象还在用：
- 静态集合类长期持有对象（如 static Map 缓存未清理）
- 监听器或回调注册后忘了反注册
- ThreadLocal 使用不当，线程复用（如线程池）导致旧值堆积
- 内部类隐式持有了外部类引用，造成外部对象无法回收
这些情况 JVM 并不认为是“垃圾”，所以不会回收——问题不在机制，而在代码逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
