连接、线程和文件句柄如果由组件创建，就需要有对应的释放时机。Bean 生命周期提供的是挂接点。
本文使用JDK 7、Spring Framework 3.2.6 与 Servlet 容器，代码为结构片段。把请求入口、业务服务和数据访问拆开，是为了明确依赖与事务归属。容器能够装配对象，但应用仍须负责业务规则、异常含义和外部资源生命周期。
1. 从现象推到机制
容器完成对象创建与依赖设置后，才调用初始化逻辑；销毁回调适用于容器管理且被正确关闭的作用域。prototype（原型）对象的完整销毁通常要由使用方负责，不能假设所有实例都会被容器自动清理。
图中的四个节点分别表示实例创建、依赖完成、正常运行、容器关闭。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用演示工作线程说明启动与停止对应关系。初始化失败应清理已取得的资源，停止时设置标记并等待线程退出。
1
2
3
<bean id="worker" class="demo.ReportWorker"
init-method="start" destroy-method="stop"/>
<!-- 容器需要被正常关闭，才有相应销毁机会 -->
将片段放入匹配版本的 Maven 工程，补齐组件扫描、数据库连接及依赖。验证时通过容器取得对象，区分普通对象调用和代理调用，避免绕过要研究的机制。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 容器正常关闭 | 已注册销毁回调应被调用 |
| 初始化中途失败 | 已创建资源仍需要回收 |
| 对象不由容器创建 | 容器不会代管其生命周期 |
对照 1：容器正常关闭
已注册销毁回调应被调用。观察时记录资源持有者与关闭日志。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：初始化中途失败
已创建资源仍需要回收。观察时记录部分初始化完成的步骤。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：对象不由容器创建
容器不会代管其生命周期。观察时记录实例来源与关闭责任。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
异常终止进程不保证执行优雅关闭逻辑。核心数据不能只等销毁回调才落盘，后台任务也需要可恢复的状态设计。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“对象不由容器创建”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
