单例模式与依赖注入：谁能真正控制对象生命周期？
近期趋势
在软件开发社区中，关于单例模式与依赖注入（DI）的讨论热度持续上升。近期多个技术博客和框架文档开始强调“避免全局状态”与“显式生命周期管理”之间的平衡。一方面，传统单例模式因其简单直接仍被大量遗留系统使用；另一方面，依赖注入容器（如Spring、Guice、.NET Core DI）逐渐成为主流架构的标配。开发者越来越关注：在微服务、云原生环境中，对象何时创建、何时销毁、如何共享——这些生命周期细节正从“隐藏细节”变为“核心设计决策”。
行业背景
单例模式是GoF经典设计模式之一，核心目标是确保一个类只有一个实例，并提供全局访问点。在内存、线程或资源受限的场景下，单例能减少重复创建的开销。然而，它的缺点同样突出：隐藏依赖关系、难以并行测试、违反单一职责原则。依赖注入则通过外部容器管理对象的创建和生命周期，将实例化职责从使用者中剥离。行业背景显示，随着测试驱动开发、持续集成和微服务架构的普及，依赖注入因其可测试性和解耦能力被广泛采纳。但注入容器本身也引入了复杂性：容器需配置作用域（如Singleton、Scoped、Transient），开发者必须理解这些作用域才能正确控制生命周期。
生命周期控制的两种路径
| 维度 | 单例模式 | 依赖注入（DI容器） |
|---|---|---|
| 实例创建时机 | 初次调用时（延迟初始化）或类加载时 | 由容器根据配置（单例/作用域/瞬时）决定 |
| 全局访问 | 通过静态方法或属性暴露 | 通过构造函数/参数注入，无全局状态 |
| 测试友好性 | 低（需在测试中重置单例） | 高（可轻松替换模拟对象） |
| 生命周期粒度 | 整个应用程序生命周期（通常为进程级） | 可细化为请求级、会话级、线程级或自定义 |
| 依赖关系透明度 | 隐式（调用方需知道单例的存在） | 显式（通过接口和构造函数参数体现） |
用户关注点
- 性能 vs 清晰度：单例模式在某些高并发场景下可能成为瓶颈（锁竞争），但依赖注入容器在解析作用域时也会带来微小的性能开销。开发者需要权衡：是接受单例的静态性，还是接受容器管理的额外复杂度。
- 线程安全：单例常因双重检查锁或枚举实现而引入线程安全问题；DI容器通常内置线程安全机制，但若作用域配置错误（例如将瞬态对象注入到单例中）会导致意外的共享状态。
- 资源释放：单例对象在进程结束时才释放，无法精细控制数据库连接、文件句柄等有限资源的释放时机。依赖注入容器提供了生命周期回调（如@PreDestroy、IDisposable），能更可靠地清理资源。
- 可维护性：大量使用单例的代码库常出现“隐式耦合”，重构时难以追踪依赖。依赖注入通过构造函数参数列表让依赖关系一目了然，但也可能因注入过多参数而走向另一个极端（服务定位反模式）。
可能影响
短期内，已采用DI容器的团队会继续强化生命周期管理，例如通过更细粒度的作用域（请求级、事务级）来替代全局单例。可能的影响包括：
- 旧项目重构时，单例向依赖注入迁移会增加初期工作，但长期可降低技术债务。
- 云环境中无服务器函数（如AWS Lambda）实例数动态伸缩，单例模式的“全局唯一性”被打破——每个实例都有自己的单例，反而可能导致逻辑混乱。DI容器的作用域能更好地适配这种弹性运行环境。
- 框架设计趋势：新兴框架（如Quarkus、Micronaut）默认采用编译时依赖注入，将生命周期决策提前到构建阶段，进一步减少运行时开销，同时保留单例控制力。
后续观察
没有绝对的“更好”，只有适合上下文的“更合适”。单例模式与依赖注入并非水火不容，许多DI容器本身就使用单例作用域来管理共享服务（如日志记录器、配置管理器）。真正的控制权在于开发者是否理解对象的创建与销毁边界。
后续值得关注的方向：
- 作用域嵌套与生命周期边界：如何用DI容器实现类似“会话级单例”或“事务级单例”，以替代传统单例的全局性。
- AOT（提前编译）与静态分析：依赖注入容器在AOT环境下能否像单例模式一样实现零反射开销。
- 团队协作规范：是否会在代码评审中明确禁止使用单例模式，或制定“仅在纯工具类中允许单例”的规则。
开发者应结合自身应用的部署模式、性能要求和测试策略，选择一种可预期、可调试的生命周期控制方式。毕竟，控制权不在于模式本身，而在于设计者对对象存在时间的明确认知。