GC（垃圾回收）基础算法与对象生命周期

学完本章，你能把一个对象从分配到回收讲成一条可验证的引用链：先判断谁在持有它，再判断为什么收不掉，最后选择从代码、容量还是收集策略治理。本文只讲 GC（垃圾回收）基础算法和对象生命周期；G1（垃圾优先回收器）的 Region（区域）回收阶段、记忆集实现和并发标记细节留在 04。

1. 学习边界与面试主线

对象生命周期：实例从分配、初始化、安全发布、存活、跨代引用、不可达、终结边界到被回收的过程。
JVM（Java 虚拟机）与类生命周期：进程启动关闭、类加载初始化卸载，是不同层级的问题；对象不因类仍加载就必然存活。
回答顺序：引用根 → 可达性 → 引用类型 → 回收算法 → 分代与晋升 → 跨代引用 → 项目证据链。

容易混淆的对象	生命周期主体	开始条件	结束条件	面试结论
JVM（Java 虚拟机）生命周期	进程与运行时	进程创建并启动 JVM（Java 虚拟机）	正常退出、崩溃或被终止	关心运行时基础设施和存活线程。
类生命周期	类元数据	ClassLoader（类加载器）定义并初始化类	类加载器与关联元数据满足卸载条件	关心类身份、初始化和元空间。
对象生命周期	单个实例	分配内存	对象不可达且被某次 GC（垃圾回收）实际回收	关心引用链、分配速率与回收时机。

2. 对象生命周期、可达性与基础算法

2.1 对象生命周期：从分配到回收，而不是从 `new`（创建对象）到析构

对象生命周期从分配开始，而不是从构造器返回才开始。JVM（Java 虚拟机）先确认类已可用，在可用空间或线程本地分配区取得内存，写入默认零值和对象头，再执行构造方法。构造完成后仍需安全发布；把未完成的 this（当前对象引用）交给其他线程，会让对象虽“已分配”却不具备可正确使用的业务状态。对象之后可能在年轻代多次存活、被老年代对象引用，最终在没有任何垃圾回收根路径时成为回收候选。不可达不是“立即消失”，而是等待适当回收周期处理。

flowchart TD
    A["类已可用"] --> B["分配实例内存"]
    B --> C["默认零值与对象头"]
    C --> D["构造方法初始化"]
    D --> E["安全发布给业务线程"]
    E --> F["存活、引用变化、可能跨代"]
    F --> G{"仍可从垃圾回收根到达？"}
    G -->|是| F
    G -->|否| H["回收候选与终结边界检查"]
    H --> I["某次 GC（垃圾回收）回收空间"]
    X["失败：构造期间 this（当前对象引用）逸出"] -.-> E
    Y["失败：缓存或队列继续持有"] -.-> G

正常路径：对象完整构造后发布；业务完成后最后一条根路径断开，后续 GC（垃圾回收）释放空间。
失败路径：构造器注册回调、启动线程或写入全局集合，使其他线程观察到半初始化对象；无界缓存和任务队列会把本应短命的对象延长为长期存活。
结论：对象生命周期是引用可达性的生命周期，不等同于 JVM（Java 虚拟机）进程或类生命周期；“局部变量离开作用域”也不等于立刻回收。

阶段	堆中状态	正确实践	常见错误
分配	取得一段实例空间	控制对象大小与批量上限	把巨型结果集一次性装入列表。
初始化	默认值、对象头、构造字段逐步就绪	完成构造后再发布	构造器里暴露 `this`（当前对象引用）。
发布与存活	被栈、字段、集合或队列引用	使用清晰所有权与完成回调	监听器未注销、结果列表未清空。
不可达与回收	无根路径后等待回收时机	让资源关闭独立于内存回收	依赖 finalize（终结方法）释放文件或连接。

2.2 GC（垃圾回收） Roots（垃圾回收根）与引用链：存活判断从根出发

GC（垃圾回收）不会把“谁的引用计数不为零”当作存活标准，而是从一组运行时确定的根开始遍历对象图。典型根包括：各活跃 Java（编程语言）线程栈帧中的局部引用、已初始化类的 static（静态关键字）字段、JNI（Java 本地接口）持有的对象句柄、被同步锁持有或等待使用的对象、运行中线程本身及 JVM（Java 虚拟机）内部运行时结构。根不是一个固定的业务名单；它代表收集器在安全暂停或并发协议下必须认为“仍可能被程序直接使用”的入口。

flowchart LR
    S["线程栈局部引用\n垃圾回收根"] --> T["导出任务"]
    T --> P["当前页数据"]
    C["static（静态关键字）缓存\n垃圾回收根"] --> M["缓存映射"]
    M --> O["订单快照"]
    N["JNI（Java 本地接口）句柄\n垃圾回收根"] --> B["直接缓冲关联对象"]
    L["活跃线程与同步锁\n垃圾回收根"] --> Q["锁保护的会话"]
    X["循环对象 X"] --> Y["循环对象 Y"]
    Y --> X
    F["失败：线程池队列"] --> T

正常路径：根只持有必要的工作对象；任务结束、局部变量退出且集合清空后，整段业务对象图失去入口。
失败路径：静态缓存未过期、线程池队列堆积、JNI（Java 本地接口）代码忘记释放句柄，都会使“大对象仍然可达”而非“GC（垃圾回收）失效”。
结论：堆转储首先看 Path to 垃圾回收根的路径；最大的对象通常只是结果，真正要修的是最上游不该长期存在的根边。

根类别	典型引用	线上误用	治理动作
栈局部引用	正在执行的方法参数、局部变量	长循环把整批结果一直放在局部集合	缩小批次和变量作用范围，流式处理。
static（静态关键字）字段	全局缓存、单例注册表	无上限缓存或永久监听器	设置容量、过期和注销协议。
JNI（Java 本地接口）句柄	本地库回调、直接缓冲关联	本地代码长期保留对象句柄	明确释放时机并做泄漏测试。
活跃线程与锁	线程上下文、等待队列、锁对象	线程池不清理上下文	在任务边界清理并控制队列容量。

2.3 四类引用、ReferenceQueue（引用队列）与 Cleaner（清理器）：缓存和资源的边界

强引用是普通字段和局部变量的默认语义；只要从 GC（垃圾回收） Roots（垃圾回收根）沿强引用可达，对象就必须保留。SoftReference（软引用）适合“可重建且允许在内存压力下丢失”的缓存，但不是容量治理工具；WeakReference（弱引用）在下一次相关 GC（垃圾回收）后可能被清除，适合不应反向延长生命周期的关联；PhantomReference（虚引用）不能取得被引用对象，只能配合 ReferenceQueue（引用队列）在对象进入回收后阶段做通知。Cleaner（清理器）基于虚引用思想提供注册清理动作的机制，但它同样不是确定性的业务资源关闭协议。

flowchart TD
    R["GC（垃圾回收） Roots（垃圾回收根）"] --> S["强引用：业务对象"]
    S --> A["缓存值"]
    H["SoftReference（软引用）"] -. "内存压力时可清除" .-> B["可重建缓存"]
    W["WeakReference（弱引用）"] -. "下次回收可清除" .-> C["关联键"]
    P["PhantomReference（虚引用）"] -. "不可取回对象" .-> D["待回收对象"]
    P --> Q["ReferenceQueue（引用队列）"]
    Q --> K["Cleaner（清理器）登记的清理动作"]
    F["失败：把软引用当无上限缓存"] -.-> B
    G["失败：弱引用承载必须存在的数据"] -.-> C

正常路径：缓存值可重建且有容量、过期与命中率观测；外部资源由显式关闭释放，虚引用队列只做补救性清理或诊断。
失败路径：软引用缓存无法保证命中率，内存紧张时集中失效会造成回源风暴；弱引用若承载业务必需对象，会产生随机丢数据式故障。
结论：引用类型解决“对象是否应影响另一对象存活”，不替代缓存策略、连接关闭、限流和生命周期管理。

引用类型	被引用对象的保留语义	是否可通过引用取对象	合适场景	不能承担的职责
强引用	只要根链可达就保留	可以	业务所有权、任务参数	自动缓存淘汰。
SoftReference（软引用）	内存压力下可被清除	可以，清除后得到 null（空值）	可重建本地缓存	严格容量和稳定命中率。
WeakReference（弱引用）	下次回收时可清除	可以，清除后得到 null（空值）	元数据关联、避免反向持有	业务状态或可靠队列。
PhantomReference（虚引用）	仅用于回收阶段通知	不可以	回收后登记处理、诊断	读取对象或确定性释放。
Cleaner（清理器）	依赖回收时机触发动作	不应作为业务取回手段	防御性兜底	连接、文件等关键资源关闭。

2.4 可达性分析、Stop The World（停顿世界）与安全点：正确性有协调成本

可达性分析要在对象图相对一致的视图上完成。应用线程会持续写字段、替换数组槽位和压入栈帧；如果收集器一边标记、应用一边任意改引用，可能漏标仍被使用的对象。安全点是 JVM（Java 虚拟机）选择的一类可协调位置：线程到达后可以报告栈与引用状态，回收器据此完成根枚举、短暂停顿或阶段切换。Stop The World（停顿世界）并不等同于“整个 GC（垃圾回收）过程只能停顿”；不同收集器可把部分工作并发化，但根快照、引用重定位或重新确认等阶段仍需严格协调。

sequenceDiagram
    participant A as 应用线程
    participant J as JVM（Java 虚拟机）协调
    participant G as GC（垃圾回收）线程
    A->>J: 到达安全点并报告栈引用
    J->>G: 枚举 GC（垃圾回收） Roots（垃圾回收根）
    G->>G: 标记或准备移动对象
    alt 正常：引用视图受控
        G->>J: 完成短暂停顿阶段
        J->>A: 恢复执行
    else 失败：长时间未到达安全点或存活集过大
        G->>J: 停顿延长或回收跟不上
        J->>A: 延迟抖动、吞吐下降
    end

正常路径：线程在可协调位置停下，收集器得到可靠根集合；并发阶段用必要屏障维护标记正确性。
失败路径：存活对象过多、线程难以及时进入安全点或短暂停顿工作量过大，会放大接口延迟；这不是“把 GC（垃圾回收）线程调多”即可消除的现象。
结论：可达性分析比单纯计数更能处理完整对象图，但代价是根扫描、标记、写屏障与线程协作；优化首先应降低无效存活集和分配峰值。

机制	解决的问题	代价	排查信号
可达性分析	识别从根可见的对象图	遍历存活图、维护标记状态	存活集大时标记时间增长。
Stop The World（停顿世界）	获得可靠根或安全移动窗口	请求暂停应用线程	P99（99 分位响应时间）延迟与停顿对齐。
安全点	协调线程栈和运行状态	线程须在合适位置检查	停顿等待线程进入安全点。
写屏障	记录并发期间的引用变化	每次特定引用写入增加开销	高写入负载下的额外成本。

2.5 标记清除、复制、标记整理与分代：算法不是收集器名称

算法回答“怎样找出垃圾并释放空间”，收集器回答“用哪些阶段、线程和区域组合这些算法”。标记清除先标记可达对象，再清除未标记对象，优点是无需移动存活对象，缺点是留下碎片；复制把存活对象复制到另一块连续空间，回收成本与存活量相关且得到整块连续空闲区，但需要预留目标空间并付出移动成本；标记整理先标记，再把存活对象向一端压缩，消除碎片但需要移动和更新引用。分代收集建立在“大多数对象朝生夕灭、长期存活对象相对少”的经验假设上：让年轻区域偏向复制，让老年代更关注存活对象、碎片和长停顿权衡。

flowchart LR
    A["标记"] --> B{"选择回收算法"}
    B --> C["标记清除：释放死对象\n可能碎片"]
    B --> D["复制：搬运存活对象\n连续空间"]
    B --> E["标记整理：压缩存活对象\n消除碎片"]
    F["年轻对象多数短命"] --> G["年轻区域偏向复制"]
    H["长期存活对象较多"] --> I["老年代关注整理或分区回收"]
    X["失败：只说某收集器等于某算法"] -.-> B

正常路径：根据对象存活率、可用空间、停顿目标和碎片风险组合算法，年轻区域快速回收短命对象。
失败路径：把 G1（垃圾优先回收器）或任何具体收集器简单等同于一种算法，会忽略它的阶段、区域、并发协议和失败退化条件。
结论：标记清除、复制、标记整理是基础工具箱；空间预留、移动成本、碎片和暂停必须一起比较，不能只背“复制最快”。

算法	空间特点	停顿与移动特点	主要风险	适用直觉
标记清除	不需要额外完整目标区	不移动存活对象	碎片导致大对象或连续分配失败	存活对象不宜频繁移动但能接受碎片治理。
复制	需要目标空间或保留区	复制存活对象并更新引用	高存活率时复制量大	多数对象短命的年轻区域。
标记整理	回收后空间连续	需要移动存活对象	移动与引用修正成本	需要消除碎片、保证连续空间时。
分代收集	把不同寿命对象分区处理	结合多种基础算法	跨代引用与晋升压力	对象寿命分布明显的通用服务。

2.6 复制回收逐步演绎：存活对象少时为何高效

以经典年轻代模型说明复制：Eden（伊甸园区）放新对象，两个 Survivor（幸存区）轮换承担存活对象的目标区。一次 Minor GC（年轻代垃圾回收）时，从根和跨代入口找出 Eden（伊甸园区）与当前 Survivor（幸存区）的存活对象，把它们复制到另一块 Survivor（幸存区）或按规则晋升；来源区域随后整体视为可复用。这里的“两个 Survivor（幸存区）”是经典理解模型，用于解释年龄和复制；现代 Region（区域）化收集器的物理布局与调度并不等同于固定连续分区。

flowchart LR
    E["Eden（伊甸园区）\nA 存活、B 死亡、C 死亡"] --> M["Minor GC（年轻代垃圾回收）标记"]
    S1["from Survivor（幸存区）\nD 存活"] --> M
    M --> S2["to Survivor（幸存区）\n复制 A、D；年龄加一"]
    M --> X["B、C 无根路径，不复制"]
    S2 --> N["来源区整体复用"]
    F["失败：存活对象超过目标区"] -.-> O["提前晋升或回收压力"]

正常路径：Eden（伊甸园区）中多数对象死亡，只复制少量幸存对象，得到连续空闲空间；分配指针可快速前移。
失败路径：批量对象跨多轮回收或单次幸存量暴涨，目标 Survivor（幸存区）装不下，复制成本和提前晋升同时上升。
结论：复制算法快的前提不是“内存足够大”，而是“本次存活集小且有足够目标空间”；对象长期存活时需要重新审视批次、并发和晋升策略。

时刻	Eden（伊甸园区）对象	from Survivor（幸存区）对象	目标区结果	解释
回收前	A 20 MB（兆字节）存活，B 300 MB（兆字节）死亡	D 10 MB（兆字节）存活	空	根扫描只需确认 A、D。
复制时	A 被复制	D 被复制	A 20 MB（兆字节）+ D 10 MB（兆字节）	两者年龄各加一。
回收后	来源区整体复用	来源区整体复用	30 MB（兆字节）连续存活区	310 MB（兆字节）无需逐块清扫。
失败样本	180 MB（兆字节）对象存活	60 MB（兆字节）对象存活	目标区仅 100 MB（兆字节）	超出部分可能提前晋升，老年代压力上升。

2.7 年龄、晋升、动态年龄与分配担保：对象为何会提前变老

经典分代模型为存活对象记录年龄：对象经过一次 Minor GC（年轻代垃圾回收）仍存活，复制后年龄加一；达到设定阈值通常会晋升到 Old（老年代）。这是经验规则，不是对象必须“活满若干次”的法律。若同一年龄及以上对象在 Survivor（幸存区）中占用达到目标 Survivor（幸存区）容量的一定比例，收集器可能执行动态年龄判定，让该年龄及以上对象提前晋升；若本次幸存对象无法放入目标 Survivor（幸存区），也会发生提前晋升。所谓分配担保，是在年轻代回收前评估老年代是否可能容纳此次需要晋升的对象；这是一种容量风险控制，不保证业务内存一定安全。

flowchart TD
    A["Eden（伊甸园区）分配新对象"] --> B["Minor GC（年轻代垃圾回收）后仍存活"]
    B --> C["复制到 Survivor（幸存区），年龄加一"]
    C --> D{"达到年龄阈值？"}
    D -->|是| O["晋升 Old（老年代）"]
    D -->|否| E{"动态年龄条件或目标区不足？"}
    E -->|是| O
    E -->|否| C
    O --> G{"老年代是否可容纳晋升对象？"}
    G -->|是| H["继续服务"]
    G -->|否| F["失败：回收压力扩大，可能触发更重回收"]

正常路径：短命对象在年轻区域消失，少量对象逐步积累年龄后晋升；老年代增长速度与真实长寿业务数据相匹配。
失败路径：单批导出或异步任务使大量对象同时幸存，动态年龄和目标区不足让对象提前晋升；Old（老年代）呈阶梯上升并增加重回收风险。
结论：晋升年龄是结果指标，不是孤立调参旋钮。先减少跨轮存活对象和队列等待时间，再验证阈值、Survivor（幸存区）容量与分配担保。

触发条件	对象去向	业务含义	优先治理方向
达到年龄阈值	晋升 Old（老年代）	正常长寿对象逐步沉淀	确认长期缓存与会话规模。
动态年龄条件成立	提前晋升 Old（老年代）	某年龄段存活对象集中	缩小批量、降低并发、缩短引用链。
目标 Survivor（幸存区）不足	部分对象提前晋升	单次存活量超过预期	查导出、聚合和重试对象。
老年代难以担保	回收压力升级	需要晋升的数据没有安全去处	先止血并检查老年代持有链。

2.8 大对象与 Region（区域）化边界：不要把经典模型硬套到现代收集器

大对象的风险不只是“占用多”：它要求连续空间、复制或清理成本高，并且短时间大量产生时会迅速改变分配与晋升曲线。在经典分代模型里，大对象可能因为年轻区域容纳或复制代价而直接进入 Old（老年代）；具体阈值与实现、参数和收集器有关，不能把某个数值当跨版本结论。现代 Region（区域）化收集器将堆切为许多相同大小的 Region（区域），大对象通常占用连续多个 Region（区域），其定义和回收路径有自身规则。本文只建立边界：大对象会影响连续空间和回收节奏；具体 Region（区域）回收、Humongous（大对象区域）与 G1（垃圾优先回收器）细节在 04。

flowchart LR
    A["请求分配对象"] --> B{"普通小对象？"}
    B -->|是| C["优先走年轻区域快速分配"]
    B -->|否| D["检查连续空间与收集器规则"]
    D --> E["可能直接进入 Old（老年代）\n或占用多个 Region（区域）"]
    E --> F["对象释放前长期占用大块空间"]
    X["失败：全量字节数组或报表拼接"] --> D
    F --> Y["失败：可用总量足够但连续空间不足"]

正常路径：大文件、大报表和批量数据采用流式处理与固定大小缓冲，单次对象大小受控，峰值可预估。
失败路径：把全部 PDF（便携式文档格式）或 CSV（逗号分隔值）内容拼入一个字节数组，导致连续空间需求和大对象回收成本同时上升。
结论：大对象阈值是实现细节，工程上更可靠的规则是控制单次驻留数据、避免巨型中间数组、观察大对象数量与回收后空间。

大对象来源	错误写法	正确边界	验证证据
导出文件	全量拼接为单个字节数组	分页查询、分段写出、固定缓冲	单对象大小和任务峰值内存。
PDF（便携式文档格式）合并	全部文档同时解码	分批合并、临时文件、及时关闭	合并期间老年代和直接内存走势。
图片或附件	请求线程一次读完	限制上传大小、流式转存	请求大小、分配速率和失败率。
序列化消息	无上限聚合后发送	设消息上限并拆分	队列积压与单消息体积分位数。

2.9 跨代引用、Card Table（卡表）与 Remembered-Set（记忆集）：只扫描必要入口

Old（老年代）对象可能引用 Eden（伊甸园区）或 Survivor（幸存区）对象。年轻代回收若每次都扫描整个 Old（老年代）寻找这些边，成本会随老年代规模膨胀，违背“小范围快速回收”的目的。因此 JVM（Java 虚拟机）在引用写入时记录“某个老年代区域可能指向年轻区域”的线索；经典实现常以 Card Table（卡表）把堆切为小卡片并标脏，Region（区域）化收集器会以 Remembered-Set（记忆集）维护跨 Region（区域）入口。这里重点是动机和正确性：它们是缩小根扫描范围的索引，不是业务缓存，也不保证代替完整可达性分析。

flowchart LR
    O["Old（老年代）订单聚合"] -->|跨代引用| Y["Eden（伊甸园区）新建明细"]
    W["引用写入"] --> C["Card Table（卡表）记录脏卡"]
    C --> M["Minor GC（年轻代垃圾回收）只扫描相关卡"]
    R["Region（区域）化场景"] --> S["Remembered-Set（记忆集）记录入边"]
    S --> M
    F["失败：没有跨代索引时扫描整个 Old（老年代）"] -.-> M

正常路径：老对象写入年轻对象引用时留下记录；年轻代回收从根和少量跨代入口开始，不必全扫老年代。
失败路径：若没有这类记录，年轻代回收遗漏老到新的引用会误回收对象；若每次全扫老年代，短暂停顿会随老年代增长而恶化。
结论：Card Table（卡表）和 Remembered-Set（记忆集）是“缩小扫描范围”的运行时账本；G1（垃圾优先回收器）的具体记忆集维护成本和阶段留给 04。

概念	记录什么	在回收中的作用	不应误解为
跨代引用	老对象指向年轻对象的边	把老年代中的必要入口补入年轻回收扫描	所有老对象都要完整扫描。
Card Table（卡表）	可能发生相关引用写入的小内存卡片	用粗粒度索引缩小检查范围	精确到每个对象的业务索引。
Remembered-Set（记忆集）	某个 Region（区域）的外部入边线索	支持分区回收时找到引用来源	普通应用缓存或持久化数据。
写屏障	引用写入时维护记录的动作	保证跨代入口不会漏记	只在 GC（垃圾回收）发生时才执行。

2.10 七组对象数据演绎与项目治理：从现象到引用链闭环

下面七组演绎使用同一判断框架：先列出根和对象边，再判断本轮 GC（垃圾回收）后谁存活，最后给出代码或架构治理。它们不是收集器日志的替代品，而是把日志、堆转储和业务行为连接起来的推理模板。

flowchart TD
    A["现象：内存不回落或停顿增加"] --> B["识别对象类型与数量"]
    B --> C["查看 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）"]
    C --> D{"根链属于哪类？"}
    D -->|缓存| E["容量、过期、失效回调"]
    D -->|队列或线程| F["有界队列、取消、finally（最终清理）"]
    D -->|跨代或批次| G["缩短对象寿命、流式处理"]
    D -->|引用类型误用| H["恢复可靠状态与显式资源管理"]
    E --> I["压测验证回收后曲线"]
    F --> I
    G --> I
    H --> I

正常路径：先用对象和引用链证据定位，再将治理落到容量、生命周期或所有权，最后以相同压力验证回收后曲线。
失败路径：只凭“Full GC（完全垃圾回收）频繁”盲调堆或年龄阈值，会掩盖无界队列、缓存泄漏和弱引用误用。
结论：GC（垃圾回收）问题的主语常常是业务对象图；收集器只是暴露了对象无法按预期死亡的结果。

演绎	初始对象边	回收判断	失败现象	正确动作
1. 循环引用	A → B，B → A，无根边	A、B 都不可达，可一起回收	误以为循环必泄漏	查根路径而非内部环。
2. 软弱虚引用	缓存分别用软、弱、虚引用	软弱对象可被清理；虚引用只入队	把弱引用当可靠状态	可靠状态放共享存储。
3. 复制存活	Eden（伊甸园区）500 MB（兆字节），仅 40 MB（兆字节）存活	复制 40 MB（兆字节）并整体复用来源区	错把总分配当回收成本	关注存活率和复制量。
4. 年龄晋升	对象连续经历 6 次 Minor GC（年轻代垃圾回收）	达到阈值后晋升	调大年龄却忽略目标区不足	先查批次存活量。
5. 动态年龄	年龄 2 以上对象合计超过目标区可承受量	可能整体提前晋升	老年代突增	减并发、缩批次。
6. 大对象	单个 64 MB（兆字节）数组	依实现走特殊分配路径	连续空间或回收压力	流式分块处理。
7. 跨代引用	Old（老年代）会话 → 新请求对象	新对象由跨代入口保活	年轻对象意外变长寿	只保留紧凑必要状态。

演绎一：循环引用为什么仍可回收

时刻 T0：任务根引用 A，A 指向 B，B 指向 A，二者都存活。
时刻 T1：任务结束，根不再指向 A；外部没有其他根边。
时刻 T2：可达性分析从 GC（垃圾回收） Roots（垃圾回收根）出发访问不到 A、B；内部环不构成根。
结果：A、B 一起进入回收候选。若仍存活，必须继续找 static（静态关键字）集合、线程、队列或 JNI（Java 本地接口）等外部边。

演绎二：软、弱、虚引用的不同结局

时刻 T0：本地可重建缓存用 SoftReference（软引用），元数据关联用 WeakReference（弱引用），诊断登记用 PhantomReference（虚引用）和 ReferenceQueue（引用队列）。
时刻 T1：内存压力出现，软引用缓存可能被清除；弱引用关联可在回收后清除；虚引用对象不可重新取得。
时刻 T2：队列消费者根据 ReferenceQueue（引用队列）删除登记信息；关键连接仍由业务显式关闭。
结果：缓存丢失只导致重建，不影响订单、库存或支付事实；若把事实状态放弱引用，则会出现随机重复或丢失。

演绎三：复制存活率

时刻 T0：Eden（伊甸园区）分配 500 MB（兆字节）导出行对象。
时刻 T1：流式写出后仅当前页 40 MB（兆字节）仍被根引用。
时刻 T2：Minor GC（年轻代垃圾回收）复制 40 MB（兆字节）到 Survivor（幸存区），460 MB（兆字节）来源空间整体复用。
结果：存活率 8%，复制有效；若 350 MB（兆字节）仍被结果列表持有，复制与晋升压力就明显异常。

演绎四：年龄晋升

时刻 T0：会话对象在 Eden（伊甸园区）创建。
时刻 T1 至 T6：对象每次 Minor GC（年轻代垃圾回收）都仍被活跃会话根引用，年龄持续增加。
时刻 T7：达到当前策略阈值，对象进入 Old（老年代）。
结果：长期会话属于合理长寿对象；若是导出批次对象，应通过任务结束清理而非让其“自然晋升”。

演绎五：动态年龄

时刻 T0：高峰期同时启动 200 个 Runner（执行器）任务，年龄 1 和年龄 2 的批次对象共同存活。
时刻 T1：目标 Survivor（幸存区）容量不足以承接这些对象。
时刻 T2：动态年龄判断使某年龄及以上对象提前晋升。
结果：Old（老年代）短时阶梯增长；治理是降低同批存活对象，而非只把年龄阈值调高。

演绎六：大对象

时刻 T0：面单合并把 64 MB（兆字节）文件读成单个数组。
时刻 T1：并发 20 个任务时，单数组及解码中间对象迅速占满可用连续空间。
时刻 T2：回收即使释放一些小对象，也未必能满足连续大块请求。
结果：拆分为固定大小流和临时介质，单任务峰值受控；同时限制并发避免大对象齐发。

演绎七：跨代引用

时刻 T0：Old（老年代）中的长期库存聚合对象保存一次请求的完整上下文。
时刻 T1：请求主流程结束，但聚合对象仍指向该上下文，形成 Old（老年代）到年轻区域的边。
时刻 T2：Minor GC（年轻代垃圾回收）通过跨代入口识别上下文仍存活，并可能把它继续复制或晋升。
结果：聚合对象只保存幂等键、数量和时间戳，完整请求对象不再被长期持有。

2.11 项目落地话术：缓存泄漏、异步导出、ThreadLocal（线程本地变量）与弱引用误用

项目表达应把 GC（垃圾回收）从“调参数经历”转换为“对象生命周期治理”。下面四类案例只描述可复用的设计与排查方法，不虚构具体事故规模或收益：缓存泄漏看 static（静态关键字）根链和淘汰策略；异步导出看批次对象和队列背压；ThreadLocal（线程本地变量）看复用线程中的弱键强值边界；弱引用误用看业务事实是否被放进了不可靠的生命周期容器。

flowchart TD
    A["缓存或任务内存异常"] --> B{"证据链"}
    B --> C["static（静态关键字）缓存根链"]
    B --> D["ThreadPoolExecutor（线程池执行器）队列根链"]
    B --> E["ThreadLocal（线程本地变量）值根链"]
    B --> F["弱引用导致业务状态丢失"]
    C --> G["容量 + 过期 + 失效回调"]
    D --> H["有界队列 + 流式任务 + 取消"]
    E --> I["finally（最终清理）remove（移除）"]
    F --> J["可靠状态外置 + 弱引用仅做关联"]
    G --> K["压测与长稳验证"]
    H --> K
    I --> K
    J --> K

正常路径：缓存、队列和线程上下文都有明确所有者、容量、过期和清理时机；业务事实保存在可靠介质，内存结构只做受控加速。
失败路径：无界缓存把数据永久挂在 static（静态关键字）根上；等待队列把未执行任务变成堆积对象；ThreadLocal（线程本地变量）值随线程复用残留；弱引用让关键状态被随机清除。
结论：项目话术必须同时说出“谁持有、何时释放、满了怎么办、怎样验证”，这比报出一个 GC（垃圾回收）参数更能体现工程能力。

项目场景	根因模式	立即止血	长期修复	验证方式
缓存泄漏	static（静态关键字）缓存无容量或无过期	降低写入、清理可重建条目	容量、过期、淘汰和命中率监控	回收后占用回落，缓存大小受限。
异步导出对象滞留	队列与结果列表同时持有	暂停低优先级任务、限制并发	流式分页、有界队列、检查点恢复	任务结束后老年代回落。
ThreadLocal（线程本地变量）残留	线程池线程长期持有值	滚动释放有问题实例前取证	finally（最终清理）remove（移除）和上下文封装	堆转储无陈旧值根链。
弱引用误用	去重或状态被不可靠引用承载	切换到可靠状态存储	明确弱引用只做关联	重压下无重复通知或状态丢失。

可直接复述的项目话术

“我处理 JVM（Java 虚拟机）内存问题时，先不把它当成参数问题，而是把它拆成对象生命周期问题。先通过 GC（垃圾回收）日志确认是分配过快、晋升过快还是回收后老年代不下降；再用堆转储从大对象沿 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）定位，是缓存、任务队列、ThreadLocal（线程本地变量）还是跨代聚合对象持有。异步导出这类场景我会把全量驻留改成分页流式写出，任务队列改为有界并保留检查点；缓存补容量、过期和淘汰；线程上下文在 finally（最终清理）中 remove（移除）。修复后用相同数据量做压测，验证分配和晋升下降、任务结束后内存回落、P99（99 分位响应时间）延迟稳定。这样既能止血，也能证明对象真的按预期死亡。”

3. 章节收束：从知识学习切换到综合表达

本小节是非知识型过渡区，不再引入新的原理。复习时先用前文图表建立“对象分配—根可达—引用变化—分代流转—空间回收”的主线，再进入综合题库练习。每道综合题都应同时讲清机制、边界、日志或堆转储证据、项目改造与验证指标，避免只背收集算法名称。

4. 复习清单

能区分对象生命周期、类生命周期和 JVM（Java 虚拟机）生命周期。
能从 GC（垃圾回收） Roots（垃圾回收根）解释循环引用、缓存滞留和线程池任务滞留。
能按对象存活率解释复制、标记清除、标记整理与分代收集的权衡。
能说明跨代引用为什么需要 Card Table（卡表）或 Remembered-Set（记忆集），并把具体实现留给 G1（垃圾优先回收器）章节。
能把异步导出、Runner（执行器）队列、ThreadLocal（线程本地变量）和 IoT（物联网）弱引用误用讲成“证据—根因—修复—验证”闭环。

5. 综合面试题与追问

问题（综合题）：请完整说明一个 Java（编程语言）对象从创建到被 GC（垃圾回收）回收的生命周期。
- 口述答案：我会先把对象生命周期和 JVM（Java 虚拟机）生命周期、类生命周期区分开。JVM（Java 虚拟机）生命周期讨论进程启动和退出，类生命周期讨论加载、初始化与卸载；对象生命周期只讨论一个实例何时分配、谁能访问它、何时可回收。创建对象时，运行时先确认类可用，再在堆的可用空间中分配内存，写入默认零值和对象头，随后执行构造方法完成业务字段初始化。构造完成并不天然等于其他线程能正确使用，若在构造期间把 this（当前对象引用）注册到监听器、静态集合或新线程，可能发生半初始化对象逸出。对象发布后，它会被栈局部变量、实例字段、缓存、队列或线程上下文持有；年轻对象可能经历多次复制并积累年龄，或者被老年代对象跨代引用。只有从 GC（垃圾回收） Roots（垃圾回收根）出发再也找不到它时，它才成为回收候选；实际释放内存在后续某次 GC（垃圾回收）中完成。对于文件、连接等外部资源，不能等对象不可达才释放，而要在业务完成、异常和取消路径显式关闭。排查时我会从堆转储的 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）验证对象为什么还活着，而不是只按代码作用域猜测。进一步验证时，我会把分配速率、年轻代回收次数、对象年龄、晋升量和回收后老年代占用放到同一时间线上，再结合对象直方图确认“对象仍在创建”还是“旧对象没有断根”。若 WMS（仓储管理系统）导出任务结束后列表仍由线程池队列或监听器持有，手工触发回收也不会解决；修复必须让任务完成、失败、超时和取消路径都释放引用。上线后用相同数据量做长稳压测，要求任务结束后保留集回到基线、吞吐不下降且延迟分位稳定，才算对象生命周期真正闭环。
- 追问树：
  - 问：构造器中发布 this（当前对象引用）如何修复？答：先完整构造，再通过受控发布点交付。
  - 问：局部变量离开作用域是否立即回收？答：不是，仍要等待可达性判断和回收周期。
  - 问：为何资源不能依赖回收？答：回收时机不确定，外部资源必须显式关闭。
- 查看对象生命周期详细章节
问题（综合题）：GC（垃圾回收） Roots（垃圾回收根）有哪些？线上如何利用它定位内存不回落？
- 口述答案：GC（垃圾回收） Roots（垃圾回收根）是可达性分析的起点，它们代表应用或运行时仍能直接使用的入口。常见来源包括活跃 Java（编程语言）线程栈帧中的局部引用、已初始化类的 static（静态关键字）字段、JNI（Java 本地接口）持有的对象句柄、活跃线程和同步运行时结构。收集器从这些根沿引用关系遍历，能到达的对象必须保留；到不了的对象才是回收候选。线上出现内存不回落时，我不会先认定堆不够，而是先保留 GC（垃圾回收）日志、任务队列长度和堆转储，找保留大小大的对象，再查看 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）。如果路径落在 static（静态关键字）缓存，重点检查容量、过期和监听器注销；如果落在 ThreadPoolExecutor（线程池执行器）队列，重点检查任务生产速度、并发和取消；如果落在 ThreadLocal（线程本地变量），检查复用线程是否在 finally（最终清理）中 remove（移除）；如果落在 JNI（Java 本地接口），则要核对本地库的持有和释放。这样能把“对象大”定位为具体所有者，而不是盲目扩大堆。分析时不能只看浅堆大小，因为一个很小的缓存管理器可能经由映射和列表保留数百兆对象，真正关键的是保留大小与根路径的第一条业务边。我会连续采集两到三份堆转储，比较同一类型的实例数和保留大小是否单调增长，并把变化与请求量、重试数、队列积压和回收日志对应。修复后再验证原根路径已经消失、回收后占用恢复基线且缓存或任务正确性不受影响，这比“重启后内存下降”更能证明根因已消除。
- 追问树：
  - 问：循环引用会成为根吗？答：不会，只有外部根能到达时环才存活。
  - 问：大对象一定是根因吗？答：不一定，关键看谁通过根链保留它。
  - 问：先加堆是否可行？答：只可短暂止血，不能替代持有链治理。
- 查看 GC（垃圾回收） Roots（垃圾回收根）详细章节
问题（综合题）：为什么引用计数无法单独解决 Java（编程语言）堆回收？
- 口述答案：引用计数的思路是对象被引用时加一、引用失效时减一、计数为零就释放。它对没有环的简单对象图直观，但不能单独解决循环引用：对象 A 引用 B、B 引用 A，外部业务引用即使全部断开，A 和 B 的计数仍然都大于零，计数器无法判断这两个对象其实已经不可从程序入口访问。可达性分析换了判断角度，它不关心对象内部有多少引用，而是从 GC（垃圾回收） Roots（垃圾回收根）出发看是否存在一条可达路径；没有根路径的整个环都会被识别为垃圾。引用计数还有并发更新成本：每一次字段赋值都可能需要维护计数，存在写放大、原子更新和级联释放复杂度。可达性分析的代价则集中在根枚举、对象图遍历和并发引用变化协调，需要安全点、Stop The World（停顿世界）或写屏障协议。两者本质是不同的成本分配方式，JVM（Java 虚拟机）选择可达性分析是为了正确处理通用对象图；工程排查也因此必须找根路径，而非只看对象互相引用。并发标记期间，应用线程可能删除旧引用或建立新引用，因此收集器还要用写屏障和重新标记保证不会漏掉仍然存活的对象，这说明可达性分析的正确性来自完整协议而非一次简单遍历。项目验证可以构造“两个对象互相引用但外部根断开”和“同一对象环仍被静态缓存持有”两组数据：前者在后续回收后消失，后者在堆转储中仍有清晰根链。这个对照能直接证明泄漏取决于外部可达性，而不是对象内部是否成环。
- 追问树：
  - 问：引用计数完全没有价值吗？答：可用于局部所有权，但不能独立做通用堆回收。
  - 问：可达性分析最大代价是什么？答：根扫描、存活图遍历和并发协调。
  - 问：循环引用导致内存问题时先查什么？答：查外部根边，而不是环内部边。
- 查看可达性分析详细章节
问题（综合题）：强引用、SoftReference（软引用）、WeakReference（弱引用）、PhantomReference（虚引用）如何用于缓存和资源治理？
- 口述答案：我会先按业务后果划分，而不是把四类引用当作性能优化选项。强引用表示当前组件拥有对象且业务必须保留；普通字段、局部变量和任务参数都是这种语义。SoftReference（软引用）只适合可重建、允许在内存压力下被丢弃的本地缓存，但它不提供容量上限、稳定命中率或过期策略，因此不能用来代替缓存治理。WeakReference（弱引用）适合不应反向延长对象生命周期的关联，例如某些元数据索引；它在回收后可能随时失效，绝不能承载订单幂等、库存状态或告警去重事实。PhantomReference（虚引用）不能重新取得对象，只能与 ReferenceQueue（引用队列）配合得到对象进入回收阶段的通知，用于清理登记信息或诊断。Cleaner（清理器）也是补救机制，不是连接、文件和锁的确定性关闭方案。项目中我会给缓存补容量、过期、淘汰和命中率监控，给外部资源补显式关闭；引用类型只帮助表达“这条关联是否有资格延长对象存活”。从可达性角度看，四类引用会影响对象在不同回收阶段的处理，但都不能替代业务所有权协议。我会在压测中同时观察引用队列入队量、缓存条目数、回源次数、分配速率和延迟，防止软引用集中失效造成缓存击穿；对支付幂等、库存扣减和告警去重则做故障注入，确认即使内存紧张并触发回收，可靠存储中的状态仍完整。只有“可丢失且可重建”的数据才允许使用弱化引用，外部资源则必须由显式关闭路径承担主责任。
- 追问树：
  - 问：软引用缓存为何可能造成抖动？答：压力下集中失效会导致大量重建或回源。
  - 问：弱引用可做分布式去重吗？答：不可，状态会被非确定性清除。
  - 问：Cleaner（清理器）何时使用？答：作为遗漏关闭的防御性兜底和诊断。
- 查看引用类型详细章节
问题（综合题）：为什么 GC（垃圾回收）需要 Stop The World（停顿世界）？怎样解释安全点？
- 口述答案：GC（垃圾回收）需要先获得一个足够可靠的对象图视图。应用线程在执行时不断压入栈帧、替换字段引用、修改数组元素；若收集器一边扫描、应用一边任意改变边，可能出现对象已被新引用但未被标记的情况，最终造成错误回收。根枚举必须知道每个线程栈和运行时结构里有哪些引用；复制或整理对象时还要防止应用继续按旧地址使用对象，因此这些关键阶段需要 Stop The World（停顿世界）。安全点可以理解为 JVM（Java 虚拟机）安排的线程协调位置，线程到达后能够报告可用于根扫描的状态，收集器才安全切换阶段。现代收集器会把部分标记、清理或重定位并发执行，但并发不意味着完全没有暂停；仍要在初始根、重新确认或引用修正等位置协调。排查长停顿时我会看暂停时间、存活对象量、晋升速率、线程到达安全点的等待和业务分配尖峰，避免只根据堆总大小下结论。治理重点是减少无效存活对象、削平批处理峰值并让核心链路避开大任务竞争。写屏障的作用是记录并发期间对象引用图的变化，使收集器能够在重新标记阶段修正视图；它会增加引用写入成本，却换来大部分阶段与业务并发执行。线上判断时要把暂停日志中的阶段、用户线程进入安全点耗时、应用延迟和中央处理器饱和度对齐。如果支付回调、查询接口和异步任务在同一时刻都出现日志空洞，且暂停事件完全重合，才能有证据地归因于运行时停顿；随后用削峰前后的同流量对比证明治理有效。
- 追问树：
  - 问：停顿时间只由堆大小决定吗？答：更受本次存活集、根数量和移动量影响。
  - 问：安全点是每一行代码吗？答：不是，通常位于适合协调的执行位置。
  - 问：并发收集是否零停顿？答：不是，关键阶段仍存在短暂停顿。
- 查看安全点详细章节
问题（综合题）：标记清除、复制、标记整理三种算法怎样比较？
- 口述答案：三种算法都先要知道哪些对象存活，差别在于如何处理死对象和空间形态。标记清除在标记后直接释放不可达对象，不移动存活对象，优点是移动成本低，缺点是留下零散空洞；当业务需要一个连续大块分配时，空闲总量够也可能失败。复制算法把存活对象搬到目标空间，来源区整体复用，因此不会留下碎片，成本主要随存活对象量变化；它需要目标空间，并且当存活率高时搬运和目标区压力很大。标记整理先标记，再把存活对象压缩到一端，回收后空间连续，适合需要消除碎片的场景，但移动对象和修正引用会增加停顿或并发协议成本。分代收集会把它们组合使用：新对象大多短命，年轻区域常受益于复制；长期对象更多的区域则要在碎片、移动、吞吐和停顿之间权衡。算法不是具体收集器名称，真实收集器还涉及线程模型、区域、并发阶段和失败退化。排障时应读实际回收阶段与存活率，而不是背某个名称就断言使用了唯一算法。比较算法必须带入数据：例如年轻区域分配 1 GB（吉字节）但只存活 50 MB（兆字节），复制成本接近存活集而非总分配量；若存活 800 MB（兆字节），复制空间与移动开销就明显恶化。日志中要关注回收前后容量、存活量、复制失败、晋升量和暂停阶段，堆转储则验证谁让对象长期可达。项目优化先降低批任务存活集，再在相同数据规模下比较暂停、吞吐和空间回收结果，不能只凭算法名称做参数结论，并要保留可复现实验记录。
- 追问树：
  - 问：复制为什么适合年轻区域？答：短命对象多，实际搬运的存活量较小。
  - 问：标记清除最大风险？答：碎片影响连续空间分配。
  - 问：标记整理是否没有代价？答：有对象移动和引用修正成本。
- 查看算法详细章节
问题（综合题）：Minor GC（年轻代垃圾回收）中 Eden（伊甸园区）与 Survivor（幸存区）怎样协作？
- 口述答案：经典模型中，新对象优先在 Eden（伊甸园区）分配，两个 Survivor（幸存区）轮换保存经历过年轻回收仍然存活的对象。发生 Minor GC（年轻代垃圾回收）时，收集器从 GC（垃圾回收） Roots（垃圾回收根）和必要的跨代入口找到 Eden（伊甸园区）以及当前来源 Survivor（幸存区）中的幸存对象，把它们复制到另一块目标 Survivor（幸存区），并增加对象年龄；未被复制的对象随来源区域整体复用。这样的好处是死亡对象不必逐个形成空闲块，后续分配能在连续区域快速推进。它的前提是本次存活对象不多且目标区足够；如果导出任务把整批结果、格式化字符串和字节数组持续保存在列表中，幸存量会增加，目标 Survivor（幸存区）可能装不下，导致提前晋升到 Old（老年代）。因此我会把异步导出改为分页读取、流式写出、批次结束立即断开引用，并对任务队列限流。验证时看每批存活量、复制量、晋升速率和任务结束后的内存回落，而不是只看一次任务是否成功。跨代入口不能遗漏：老年代任务管理器若仍指向某个年轻批次，写屏障维护的卡表线索会把这条边加入扫描，否则可能误回收。排查时我会对照回收日志中的目标区使用量、对象年龄分布和晋升字节数，并在堆转储中检查幸存对象是否由队列、重试表或上下文持有。改造后要求每页处理完成即可断根、目标区压力下降、老年代不再阶梯上涨，同时导出结果行数和断点恢复保持正确。
- 追问树：
  - 问：为什么要两个 Survivor（幸存区）？答：明确来源和目标，完成后可整体复用来源区。
  - 问：复制成本和什么最相关？答：与存活对象扫描和搬运量更相关。
  - 问：目标区不足会怎样？答：对象可能提前晋升并增加老年代压力。
- 查看复制演绎详细章节
问题（综合题）：对象年龄、动态年龄和分配担保如何解释频繁晋升？
- 口述答案：对象年龄不是按现实时间增长，而是每经历一次 Minor GC（年轻代垃圾回收）并仍存活就增加一次。达到当前策略阈值后，对象通常从 Survivor（幸存区）晋升到 Old（老年代），以避免长期对象反复复制。但阈值只是常规路径：如果某一年龄及以上的对象总量已经接近目标 Survivor（幸存区）可承受范围，运行时可能使用动态年龄判定，让这些对象提前晋升；如果本次存活对象目标区装不下，也会提前晋升。分配担保关心的是年轻回收前，Old（老年代）是否可能容纳本次需要晋升的对象，它是容量风险判断而非成功承诺。线上看到老年代在批任务期间阶梯上涨时，我会先检查是否有大量对象跨轮存活、任务是否排队太久、结果列表是否未清空，再看 Survivor（幸存区）压力和晋升速率。只把年龄阈值调大可能让目标区更拥挤，只把堆调大则把风险推迟；正确顺序是先缩小批次、降低并发、让任务完成后对象断根，再用固定压测判断容量参数是否仍需要调整。年龄分布只是结果，根因仍可能是对象被线程池队列、静态缓存或老年代聚合对象持续可达。我会把每轮回收的年龄直方图、晋升量、老年代回收后占用和任务生命周期对齐，确认是稳定长寿对象还是业务峰值制造的“伪长寿”。在 Runner（执行器）调度场景中，通过限制在途批次、只保留检查点并清理失败任务参数，再以同样积压量验证晋升速率下降；若对象图已经有界，才评估年龄与区域容量参数。
- 追问树：
  - 问：年龄由时间决定吗？答：由经历年轻回收的次数决定。
  - 问：动态年龄是故障吗？答：不是，但频繁发生说明存活量与模型不匹配。
  - 问：分配担保失败只能重启吗？答：先降载止血、保存证据并清理持有链。
- 查看晋升详细章节
问题（综合题）：大对象为什么容易导致连续空间和停顿问题？
- 口述答案：大对象的风险不只是占用字节多，而是它往往要求一次获得足够连续的空间，并且复制、整理或释放时涉及更大的数据块。标记清除留下碎片时，虽然总空闲量可能看起来充足，却未必有一个连续块能满足大数组或大缓冲的请求；区域化管理下也要符合 Region（区域）可用规则。大对象若大量短时间产生，会迅速提高分配速率和老年代或特殊区域压力，多个任务同时拼接文件时更容易放大峰值。工程上我不依赖某个固定阈值判断“大对象”，因为具体路径随收集器、参数和版本变化；我会约束单次驻留数据，用流式读取、固定大小缓冲、分页写出和临时文件替代全量字节数组，并按文件大小限制并发。比如跨境物流面单合并，任务只保存检查点和临时文件位置，分段合并后立即释放解码对象。验证要同时看单对象大小分布、并发任务数、回收后占用和请求失败率，确认问题不是被移到不可观测的地方。证据上要区分“对象仍被根链持有”和“对象已死亡但空间形态不满足分配”：前者在堆转储中有清晰 Path to GC（垃圾回收） Roots（到垃圾回收根的路径），后者可能表现为回收后总占用下降却仍发生连续空间分配失败。日志还应关联大对象分配、整理或疏散阶段和暂停时长。面单任务改造后要校验文件字节一致、失败可重试、临时文件有配额与过期清理，并确认峰值内存不再随文件总大小线性增长，连续高峰期间也不出现老年代基线漂移。
- 追问树：
  - 问：大对象一定进入 Old（老年代）吗？答：不一定，具体取决于实现和当前空间。
  - 问：总空闲足够为何仍失败？答：可能没有满足请求的连续空间或区域。
  - 问：临时文件有什么代价？答：引入磁盘配额、清理和 I/O（输入输出）治理。
- 查看大对象详细章节
问题（综合题）：什么是跨代引用？为什么要有 Card Table（卡表）或 Remembered-Set（记忆集）？

口述答案：跨代引用是长寿对象，例如 Old（老年代）里的订单聚合或会话，指向年轻区域中新创建对象的引用。它会影响 Minor GC（年轻代垃圾回收）：如果收集器只扫描年轻区域和线程栈，就可能漏掉“老对象仍在使用新对象”这条路径，把新对象错误回收。最朴素的做法是每次年轻回收都扫描整个 Old（老年代），但老年代通常更大，这会让本应很快的年轻回收成本随堆规模膨胀。Card Table（卡表）和 Remembered-Set（记忆集）的共同动机是提前记录可能存在这类引用的位置：对象字段写入时通过写屏障留下线索，回收时只扫描相关卡片或入边集合，而不是全扫老年代。它们以少量写入和内存开销换取更小的暂停范围。项目设计上更重要的是减少无意义跨代边，例如长期 SKU（库存单位）聚合只保留幂等键、数量、时间戳等紧凑状态，不保存一次请求的完整上下文、字节数组和回调对象。具体 G1（垃圾优先回收器）记忆集实现和维护成本我会放到收集器章节讲。这里要区分 GC（垃圾回收） Roots（垃圾回收根）与跨代入口：老年代对象本身仍需从根可达，跨代索引只是帮助年轻回收快速发现它指向的新对象，并不改变可达性规则。验证时可比较聚合对象瘦身前后的引用写入频率、年轻代扫描入口、晋升量和暂停时间，同时用堆转储确认完整请求上下文不再挂在长寿聚合上。若性能改善但库存幂等或审计信息缺失，说明状态裁剪过度；因此还要用并发扣减与故障恢复测试验证业务正确性。
追问树：
- 问：跨代引用是否应完全禁止？答：不必，但应少、轻且有过期边界。
- 问：写屏障有什么代价？答：高频引用写入会增加额外记录成本。
- 问：为何不能全扫老年代？答：会放大年轻回收暂停时间。
查看跨代引用详细章节

问题（综合题）：如何解释“循环引用不会泄漏，但缓存循环引用仍可能泄漏”？

口述答案：这两句话讨论的不是同一个条件。循环引用本身只说明对象之间互相指向，例如 A 指向 B、B 再指向 A；Java（编程语言）的可达性分析从 GC（垃圾回收） Roots（垃圾回收根）出发判断对象图，若外部没有根能到达 A 或 B，整个环都不可达，因此可以一起回收。所谓“循环引用导致泄漏”通常是误把环内部边当成了根因。缓存场景真正的问题是 static（静态关键字）缓存、单例管理器、活跃线程或任务队列仍有一条边指向这个环；只要根到环的入口没断，环内所有对象都会被保留。排查时我会找 Path to GC（垃圾回收） Roots（到垃圾回收根的路径），区分是缓存条目未过期、淘汰策略失效、监听器未注销，还是异步任务未完成。修复不是强行打断所有双向关联，而是给缓存设容量、过期和失效协议，给监听器设注销责任，给任务设完成、取消和超时清理。这样既保留必要的对象关系，也让业务结束后最外层根边能够按预期断开。验证时看缓存大小上限、任务结束后的保留集和长稳运行曲线，而不是只做一次手工 GC（垃圾回收）。为了形成证据闭环，我会构造两组对象图：一组仅保留环内部引用，另一组额外放入静态缓存；连续堆转储应显示第一组实例在回收后消失，第二组经缓存根链持续存在。生产上还要结合缓存键增长率、淘汰数、回收后老年代占用和请求量，排除只是流量增长。修复后不仅检查内存，还要验证缓存并发失效、回源限流和业务数据一致性，防止断根正确却引入缓存雪崩。
追问树：
- 问：双向关联是否都不推荐？答：不是，关键是外部所有权和释放边界。
- 问：如何找到入口边？答：从大对象查看 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）。
- 问：缓存有过期就一定安全？答：还要有容量、淘汰、异常清理与监控。
查看循环引用演绎

问题（综合题）：SoftReference（软引用）缓存为什么不是内存治理方案？

口述答案：SoftReference（软引用）表达的是“缓存值可在内存压力下被放弃”，它并没有表达缓存应保存多少条、保存多久、淘汰哪一条、失效后如何限速重建。把软引用当成无上限缓存会导致两个问题：第一，内存不紧张时缓存仍可无限增长，元数据、键、索引和关联对象也会持续占用空间；第二，内存压力出现时大量缓存可能在短时间失效，多个请求同时回源或重新计算，造成数据库、远程服务或 CPU（中央处理器）突刺，反而加剧抖动。正确做法是先明确缓存是否只是加速层，唯一业务事实仍在可靠存储；再依据单值大小、键基数、堆预算和重建成本设置容量与时间过期，配合淘汰、加载合并、限流和命中率监控。SoftReference（软引用）若使用，只能是这套治理之外的可选辅助，不能承担严格内存上限。线上若发现回收后内存下降却请求延迟和下游负载飙升，应检查软引用缓存是否集体失效。对 WMS（仓储管理系统）商品或库存读模型，宁可用明确大小和失效策略的缓存，也不能把库存正确性押在回收时机上。可达性处理只决定软引用对象何时可能被清理，并不知道下游能否承受同时重建。验证方案应注入内存压力，记录软引用清除量、缓存命中率、回源并发、数据库耗时和接口延迟，确认加载合并与限流有效；同时检查键和缓存元数据是否仍被强引用保留。即使回收日志显示堆占用下降，如果回源把订单或库存链路压垮，也不能称为成功治理，容量上限和可靠状态边界仍是主方案。
追问树：
- 问：软引用适合什么？答：可重建、丢失后不影响正确性的本地加速数据。
- 问：缓存命中率低先调软引用吗？答：先看容量、访问分布、失效和回源策略。
- 问：库存事实能放软引用吗？答：不能，必须在可靠存储维护。
查看引用类型详细章节

问题（综合题）：WeakReference（弱引用）与 ThreadLocal（线程本地变量）为什么会产生反直觉的内存问题？

口述答案：WeakReference（弱引用）只保证被弱引用的对象在没有更强路径时可以被回收，它不等于“相关值一定自动清掉”。ThreadLocal（线程本地变量）的典型陷阱就是 ThreadLocalMap（线程本地映射）对键使用弱引用，但值仍由工作线程内部结构强持有；当 ThreadLocal（线程本地变量）键本身没有外部强引用后，键可能变成空，而值并不会立即消失。在线程池中，线程会长期复用，陈旧值可能携带用户上下文、报表批次、字节数组或连接引用，最终形成“弱键强值”滞留。正确治理不依赖后续访问碰巧触发清理，而是在每个任务设置上下文后，无论成功、异常、超时还是取消，都在 finally（最终清理）中 remove（移除）；最好把设置、执行和清理封装为任务模板或装饰器。堆转储中若从活跃工作线程到 ThreadLocalMap（线程本地映射）再到大值对象形成路径，就能直接证明根因。弱引用在这里解决的是键不反向保活，不是值的所有权；因此任何需要可靠清理的值都必须由任务边界显式负责。这里的 GC（垃圾回收） Roots（垃圾回收根）通常是长期存活的工作线程，根链为“线程—线程本地映射—条目值”，所以键被清理并不会打断值的强引用。排查可连续执行带唯一批次号的任务，在堆转储中按批次对象反查根路径，并观察线程池空闲后老年代是否回落。修复后要覆盖正常、异常、超时和取消四类路径，验证每个工作线程都没有残留上一个租户或批次的数据，同时确认上下文传播功能仍正确。
追问树：
- 问：键被回收后值为何还在？答：值仍被线程内部条目强持有。
- 问：线程结束能释放吗？答：能，但线程池线程可能长期不结束。
- 问：只依赖后续 set（设置）清理行吗？答：不可靠，必须主动 remove（移除）。
查看项目治理详细章节

问题（综合题）：PhantomReference（虚引用）、ReferenceQueue（引用队列）和 Cleaner（清理器）应该怎样解释其资源释放边界？

口述答案：PhantomReference（虚引用）的核心不是“还能拿到一个更弱的对象”，而是明确不能再通过它获取被引用对象；它只与 ReferenceQueue（引用队列）协作，让应用感知某对象已经进入回收处理阶段。典型用途是删除与对象身份关联的登记信息、统计未显式关闭的资源或实现防御性清理。Cleaner（清理器）可以把清理动作登记在类似机制上，但触发前提仍是对象不可达并且 GC（垃圾回收）实际运行，因此时间不确定，进程异常退出时也未必执行。文件句柄、网络连接、数据库连接、锁和事务上下文属于外部稀缺资源，必须由业务路径在使用结束时显式关闭；异常、超时和取消路径也要覆盖。把 Cleaner（清理器）当主路径会让资源泄漏从“代码能看见的错误”变成“运行一段时间后偶发耗尽”，排查更难。实际项目中我会采用显式关闭加告警：资源对象实现明确关闭语义，未关闭时 Cleaner（清理器）只记录告警或做最后补救；容量监控则看打开句柄、连接池借还、任务取消和异常路径。这样内存回收与资源释放各自有确定责任。可达性和引用队列只提供“对象进入某个回收阶段”的运行时信号，不能提供事务提交、文件刷盘或连接归还的业务时序保证。测试时应故意遗漏一次关闭，确认清理器能够记录资源身份和分配位置，但主流程测试必须断言每条成功与异常路径都立即归还资源。生产证据还包括打开文件数、连接池借出数、引用队列积压和回收日志；即使堆稳定，操作系统句柄持续增长也说明资源生命周期仍未闭环。
追问树：
- 问：虚引用能重新获得对象吗？答：不能，这是它和其他引用的关键区别。
- 问：引用队列保证何时入队吗？答：不保证业务可预测的时间点。
- 问：Cleaner（清理器）适合关闭连接吗？答：只能兜底，主路径必须显式关闭。
查看引用队列详细章节

问题（综合题）：异步导出频繁 GC（垃圾回收）时，如何判断先改代码还是先调参数？

口述答案：我先把问题分成“有界峰值”和“对象生命周期错误”。先对齐任务开始时间、分配速率、Minor GC（年轻代垃圾回收）频率、晋升速率、回收后 Old（老年代）占用、队列长度和导出吞吐。如果每批对象写出后能很快回落，只是单批峰值超过当前年轻区域承受能力，且压测已证明引用链有界，那么容量、批次大小或并发参数可以一起评估；但如果老年代在任务期间阶梯上升、任务结束也不下降，或堆转储显示结果列表、线程池队列、重试表仍持有导出行对象，则必须先改代码。典型改法是游标或稳定键分页读取、边转换边写出、固定缓冲、任务只保存检查点、有界队列和取消清理；不要把所有行、格式化文本和文件字节放进一个列表。改完后再以相同数据量压测，比较分配量、晋升量、回收后占用、P99（99 分位响应时间）延迟和吞吐。单纯增大堆常常只是把 OOM（内存溢出）推迟，并可能让一次回收处理更多存活对象。参数应服务于被证明有边界的工作负载，而不是掩盖无界对象图。进一步要用 GC（垃圾回收） Roots（垃圾回收根）路径解释为什么对象跨越多轮年轻代回收：可能是执行中列表、等待队列或重试登记表仍在持有。日志证据至少包括各阶段暂停、分配与晋升速率、回收后老年代基线和任务完成时间。改造验证使用固定行数、固定并发和相同输出校验，比较峰值堆、吞吐、延迟和失败恢复；只有正确性不变、内存曲线有界后，才基于容量预算调整年轻区或堆参数。
追问树：
- 问：每页越小越好吗？答：不是，要平衡内存、数据库往返和吞吐。
- 问：队列无界有什么问题？答：等待任务本身会成为根链中的堆积对象。
- 问：如何验证代码修复有效？答：固定压力下看回收后曲线和长稳运行。
查看复制与项目治理章节

问题（综合题）：缓存泄漏怎样从 GC（垃圾回收）视角建立排查与修复闭环？

口述答案：缓存泄漏不是“缓存被回收得太慢”，而是缓存条目仍被设计为长期可达。排查首先确认回收后 Old（老年代）是否下降；如果不下降，取堆转储找占用最大的缓存值、键或索引，再沿 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）确认是否由 static（静态关键字）单例、框架注册表、监听器或定时刷新任务持有。随后把业务问题拆成四个边界：缓存是否有明确最大容量，是否有时间过期，是否有淘汰或失效回调，缓存未命中时是否能受控重建。只看命中率不够，因为高命中也可能掩盖无限增长；只加堆也不够，因为持有链仍然持续增长。修复时我会把值设计成紧凑数据，避免缓存完整请求上下文和大对象；给键基数异常、条目大小、淘汰率、命中率和回源延迟设监控；对不可重建的业务事实保留可靠存储。发布后通过固定访问分布和长稳压力验证缓存大小趋于稳定、回收后内存回落且淘汰不引发下游雪崩。这样把 GC（垃圾回收）日志、对象图和缓存产品语义连成闭环。还要区分条目本身和辅助结构：键、统计对象、过期索引或监听器也可能由同一根保留，删除值却不清索引仍会增长。我会连续比较对象直方图和保留大小，确认增长类型与缓存键基数一致，并检查淘汰后根路径是否真正断开。对 WMS（仓储管理系统）读缓存，回归测试既要覆盖容量上限和过期，也要覆盖并发回源、旧值失效和库存数据一致性，确保内存治理没有牺牲业务语义。
追问树：
- 问：缓存未命中就说明容量太小吗？答：还要看访问偏斜、失效和重建竞争。
- 问：如何处理超大值？答：限制单值大小、拆分或转外部存储。
- 问：能靠定时清空缓存吗？答：会造成抖动，必须有渐进淘汰与重建保护。
查看缓存治理章节

问题（综合题）：如何用七组对象演绎解释一次老年代阶梯上涨？

口述答案：我不会把老年代阶梯上涨直接等同于泄漏，而是按对象演绎逐层排除。先看循环引用：没有根入口的环可以回收，因此不能只看对象互相指向；再看复制存活率，若 Eden（伊甸园区）中大多数对象在一轮回收后仍活着，说明批次或队列延长了生命周期。接着看年龄和动态年龄：高峰期大量任务同时存活会让 Survivor（幸存区）不足，短命批次对象也可能提前晋升。再看大对象，文件拼接和大数组会快速占用连续空间并改变区域压力；最后看跨代引用，长期聚合对象若保存完整请求上下文，会把年轻对象保活并逐步沉积到 Old（老年代）。证据上我会结合对象年龄分布、晋升速率、队列长度、回收后老年代占用和堆转储路径。若任务结束后占用下降，更多是容量和峰值问题；若不下降且路径落在缓存、队列或 ThreadLocal（线程本地变量），则是生命周期治理问题。修复要对应最早的错误边：缩批次、流式写出、有界队列、轻量化聚合和显式上下文清理。最终以同样流量验证阶梯是否消失或回落是否恢复。时间线必须至少跨越多个业务周期：单次回收前后不足以判断趋势，要观察每轮峰值、回落基线和晋升累计量。堆转储中再按 GC（垃圾回收） Roots（垃圾回收根）路径抽样各年龄对象，判断它们来自同一批任务还是持续新增的业务事实。若缩小批次后年轻代复制量下降但老年代基线仍上升，就继续查缓存和线程上下文；只有日志曲线、根链变化与项目改造方向一致，才可确认因果关系。
追问树：
- 问：阶梯上涨后回落是否仍有风险？答：要看停顿、晋升和业务延迟是否超目标。
- 问：如何区分峰值与泄漏？答：关键在任务结束或压力降低后是否回落。
- 问：为什么先看队列？答：排队会同时延长对象寿命并放大并发峰值。
查看七组演绎章节

问题（综合题）：库存防超卖服务为什么要避免长期对象持有完整请求上下文？

口述答案：库存防超卖通常需要长期存在的 SKU（库存单位）聚合、幂等记录或热点状态，但这些长寿对象不应该直接保存每次扣减请求的完整上下文。完整上下文往往带有用户信息、追踪字段、原始消息、回调对象和序列化字节，体积大且只在当前请求周期需要；一旦挂到 Old（老年代）聚合对象上，就形成跨代引用，把本应在年轻区域快速死亡的请求对象延长到聚合生命周期。运行时可以用 Card Table（卡表）或 Remembered-Set（记忆集）保证回收正确，但这不是鼓励无边界对象图，而是为正常跨代边付出的成本。正确设计是把请求转换为紧凑、不可变且有明确过期的状态，例如幂等键、版本号、数量、时间戳和处理结果；原始请求在处理完成后断开引用，审计需要的内容写入可靠日志或存储。这样既降低年轻回收的跨代扫描压力，也减少老年代保留集和敏感信息长期驻留。验证时比较聚合对象单值大小、跨代边数量、晋升速率和高峰后老年代回落，并在并发扣减压测中确认正确性不受影响。从 GC（垃圾回收） Roots（垃圾回收根）看，长期缓存或单例管理器是聚合对象的拥有者，写屏障只是保证它新写入的请求引用不会被漏扫；它无法替业务决定何时删除引用。数据演绎可比较“每个聚合保存 1 KB（千字节）紧凑状态”和“额外保存 100 KB（千字节）请求体”在十万热点键下的保留量。发布前还应验证重复扣减、消息重放、故障恢复和审计查询，证明状态瘦身没有破坏幂等与资金库存一致性。
追问树：
- 问：跨代引用是否影响正确性？答：运行时会维护它，但无界持有会影响性能和内存。
- 问：请求审计数据放哪里？答：放可靠日志或存储，不挂在长期内存聚合上。
- 问：只保存幂等键够吗？答：要按业务恢复和审计需求定义最小必要状态。
查看跨代引用章节

问题（综合题）：面试中如何说明“算法、收集器和业务对象图”三者的关系？

口述答案：我会按三层回答。第一层是基础算法：标记清除、复制、标记整理分别在碎片、目标空间和对象移动上有不同代价；分代是假设不同寿命对象应使用不同回收策略。第二层是具体收集器：它会把这些算法组织成阶段，并决定线程并发、区域划分、暂停目标、引用更新和失败退化，因此不能把一个收集器简单等同于一种算法。第三层是业务对象图：收集器只能回收不可达对象，无法替你判断缓存是否应该无上限、任务队列是否应该堆积、ThreadLocal（线程本地变量）是否应该保留用户上下文。业务代码决定对象何时断根，算法和收集器决定断根后的对象怎样被识别和释放。出现频繁 Full GC（完全垃圾回收）时，我先用日志判断是分配峰值、晋升过快、存活集过大还是连续空间问题，再用堆转储定位根链；如果是无界对象图，先改业务生命周期，如果是已证明有界的容量不足，再做收集器和参数评估。这种表达既承认运行时机制，也避免把所有问题归咎于某个参数。写屏障、安全点和跨代索引属于收集器为保证并发可达性正确而付出的机制成本；GC（垃圾回收） Roots（垃圾回收根）路径则把运行时现象连接到业务所有者。实践中我会用日志回答“何时、哪个阶段、处理了多少存活对象”，用堆转储回答“谁在持有”，用压测回答“改造后吞吐和延迟是否达标”。三类证据相互印证后，才决定改对象图、调容量还是更换收集策略，避免用单一参数掩盖设计问题。
追问树：
- 问：收集器选型能修复泄漏吗？答：不能，泄漏对象仍然可达。
- 问：算法知道业务优先级吗？答：不知道，只按可达性和运行时规则处理。
- 问：何时讨论调参？答：对象图有界且压测证明容量不匹配时。
查看算法边界章节

问题（综合题）：请给出一次 JVM（Java 虚拟机）内存事故的完整复盘话术。

口述答案：我会这样复盘：先说明影响与边界，例如异步导出和 Runner（执行器）补偿任务高峰时出现接口延迟和频繁 GC（垃圾回收），核心交易链路受到排队影响。止血阶段先限制低优先级大任务并降低并发，保留 GC（垃圾回收）日志、队列快照和堆转储，避免重启丢掉证据。定位阶段把暂停时间和任务开始时间对齐，发现晋升速率上升、回收后 Old（老年代）不回落；再从大对象沿 Path to GC（垃圾回收） Roots（到垃圾回收根的路径）看到一部分由线程池队列持有等待任务，另一部分由导出结果列表和 ThreadLocal（线程本地变量）上下文持有。根因不是收集器参数单点失效，而是全量驻留、无界排队和清理责任缺失共同延长了对象生命周期。修复上把导出改为分页流式写出和检查点恢复，队列改为有界并按任务类型隔离，线程上下文统一在 finally（最终清理）中 remove（移除），缓存补上容量和过期。验证时使用同一数据量和并发模型压测，确认任务结束后内存回落、晋升下降、P99（99 分位响应时间）延迟稳定，并把队列长度、分配速率、回收后老年代占用和大对象数量做成告警。最后沉淀为代码审查和容量规则，防止同类对象图再次无界增长。复盘还要明确时间线、影响订单数、止血副作用和恢复判据，并保存修改前后的日志片段、对象直方图与根链截图。对于分代行为，要解释批次对象为何跨轮存活、何时晋升以及老年代基线为何不降；对于并发标记，则说明写屏障是正确性机制而非根因。灰度发布先放少量导出任务，核对文件结果、断点恢复和上下文隔离，再逐步提高并发；连续多个高峰周期指标稳定，才能关闭事故并更新容量模型与演练手册。
追问树：
- 问：为什么不先重启？答：重启会丢证据且无法修复无界生命周期。
- 问：如何保证修复不降吞吐？答：用同压测比较吞吐、延迟和内存回落。
- 问：后续预防靠什么？答：容量规则、对象图审查、监控和长稳压测。
查看项目话术详细章节

GC（垃圾回收）基础算法与对象生命周期

GC（垃圾回收）基础算法与对象生命周期

1. 学习边界与面试主线

2. 对象生命周期、可达性与基础算法

2.1 对象生命周期：从分配到回收，而不是从 `new`（创建对象）到析构

热门面试题

2.2 GC（垃圾回收） Roots（垃圾回收根）与引用链：存活判断从根出发

热门面试题

2.3 四类引用、ReferenceQueue（引用队列）与 Cleaner（清理器）：缓存和资源的边界

热门面试题

2.4 可达性分析、Stop The World（停顿世界）与安全点：正确性有协调成本

热门面试题

2.5 标记清除、复制、标记整理与分代：算法不是收集器名称

热门面试题

2.6 复制回收逐步演绎：存活对象少时为何高效

热门面试题

2.7 年龄、晋升、动态年龄与分配担保：对象为何会提前变老

热门面试题

2.8 大对象与 Region（区域）化边界：不要把经典模型硬套到现代收集器

热门面试题

2.9 跨代引用、Card Table（卡表）与 Remembered-Set（记忆集）：只扫描必要入口

热门面试题

2.10 七组对象数据演绎与项目治理：从现象到引用链闭环

演绎一：循环引用为什么仍可回收

演绎二：软、弱、虚引用的不同结局

演绎三：复制存活率

演绎四：年龄晋升

演绎五：动态年龄

演绎六：大对象

演绎七：跨代引用

热门面试题

2.11 项目落地话术：缓存泄漏、异步导出、ThreadLocal（线程本地变量）与弱引用误用

可直接复述的项目话术

热门面试题

3. 章节收束：从知识学习切换到综合表达

4. 复习清单

5. 综合面试题与追问

GC（垃圾回收）基础算法与对象生命周期

1. 学习边界与面试主线

2. 对象生命周期、可达性与基础算法

2.1 对象生命周期：从分配到回收，而不是从 new（创建对象）到析构

热门面试题

2.2 GC（垃圾回收） Roots（垃圾回收根）与引用链：存活判断从根出发

热门面试题

2.3 四类引用、ReferenceQueue（引用队列）与 Cleaner（清理器）：缓存和资源的边界

热门面试题

2.4 可达性分析、Stop The World（停顿世界）与安全点：正确性有协调成本

热门面试题

2.5 标记清除、复制、标记整理与分代：算法不是收集器名称

热门面试题

2.6 复制回收逐步演绎：存活对象少时为何高效

热门面试题

2.7 年龄、晋升、动态年龄与分配担保：对象为何会提前变老

热门面试题

2.8 大对象与 Region（区域）化边界：不要把经典模型硬套到现代收集器

热门面试题

2.9 跨代引用、Card Table（卡表）与 Remembered-Set（记忆集）：只扫描必要入口

热门面试题

2.10 七组对象数据演绎与项目治理：从现象到引用链闭环

演绎一：循环引用为什么仍可回收

演绎二：软、弱、虚引用的不同结局

演绎三：复制存活率

演绎四：年龄晋升

演绎五：动态年龄

演绎六：大对象

演绎七：跨代引用

热门面试题

2.11 项目落地话术：缓存泄漏、异步导出、ThreadLocal（线程本地变量）与弱引用误用

可直接复述的项目话术

热门面试题

3. 章节收束：从知识学习切换到综合表达

4. 复习清单

5. 综合面试题与追问

2.1 对象生命周期：从分配到回收，而不是从 `new`（创建对象）到析构