业务不再使用对象，与垃圾回收器判定它不可达，是两套不同的标准。
本文使用JDK 7，示例为方法体或类定义片段。源码学习需要区分语言规则、公共接口约定与某个版本的实现。本文把讨论范围固定在 Java 7，不把后续版本的集合结构或语法写进来。
1. 从现象推到机制
垃圾回收从根集合沿引用图寻找仍可达的对象。静态集合、长寿命线程和监听器都可能意外保留对象。把局部变量设为 null 只能断开其中一条引用；其他保留链仍存在时，对象不会因此消失。
图中的四个节点分别表示根集合、引用图、可达判断、回收观察。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用一个长期存在的列表保存临时对象，再显式移除它们。重点比较回收后的存活量，而不是刚分配完成时的瞬时峰值。
1
2
3
4
List<byte[]> retained = new ArrayList<byte[]>();
retained.add(new byte[1024 * 1024]);
// 业务结束后，集合仍保留引用
retained.clear();
将片段放入独立的小工程，补齐 imports（导入声明）和调用入口。观察返回值、异常类型及对象状态；并发实验需要重复交错，单次没有出错不能证明线程安全。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 临时变量离开作用域 | 未必能释放被静态集合引用的对象 |
| 清空长期集合 | 对象在无其他引用时可变为不可达 |
| 调用 System.gc | 只是回收建议而非释放保证 |
对照 1：临时变量离开作用域
未必能释放被静态集合引用的对象。观察时记录从根到对象的保留路径。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：清空长期集合
对象在无其他引用时可变为不可达。观察时记录回收后的存活量变化。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：调用 System.gc
只是回收建议而非释放保证。观察时记录实际回收日志和存活对象。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
回收时机由虚拟机决定，不能靠固定等待时间证明对象已释放。诊断转储文件也可能含业务内容，应在演示数据或脱敏环境分析。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“调用 System.gc”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
