学习Hilt/Dagger时，应使用@Singleton注解还是手动实现单例？

核心结论 #

Hilt的@Singleton和你手动实现的双重校验锁单例，在应用进程内的实例唯一性上行为一致，但Hilt方案在Android开发中几乎是更优选择——它更安全、更易维护、更适配依赖注入生态。

1. 二者的行为是否一致？ #

是一致的：

• 你的手动单例：通过静态变量+双重校验锁，保证整个应用进程中只有一个SongController实例（除非用反射强制创建新实例）。
• Hilt的@Singleton：这个注解会把类绑定到ApplicationComponent，也就是整个应用生命周期内，Hilt的容器只会创建一次该类的实例，所有注入点拿到的都是同一个对象，和手动单例的进程级单例效果完全相同。

你看到生成的文件不像单例，是因为Hilt把实例管理逻辑封装在了组件容器里，不是直接用静态变量暴露，但底层保证了实例的唯一性，最终效果和手动单例一致。

2. 线程安全性对比 #

• 手动单例：你写的双重校验锁（带@Volatile和synchronized）是线程安全的，但这种实现很容易写错——比如漏加@Volatile会导致指令重排问题，或者锁错对象引发线程安全漏洞，需要你自己维护同步逻辑的正确性。
• Hilt @Singleton：Dagger/Hilt内部已经实现了线程安全的实例创建与获取逻辑，容器会自动处理同步问题，你完全不用手动写synchronized或volatile，比手动实现更可靠，不会出现人为的同步错误。

3. 使用Hilt @Singleton的核心优势 #

• 减少样板代码：不用写静态变量、双重校验锁这些重复代码，几行注解就能搞定单例，代码更简洁易读：

  @Singleton
  class SongController @Inject constructor() {}
  

• 更好的可测试性：手动单例依赖静态实例，几乎无法Mock；而Hilt可以通过测试组件轻松替换成Mock实例，方便写单元测试和UI测试。
• 自动管理依赖：如果SongController需要依赖其他类（比如AudioPlayer、SongDatabase），Hilt会自动注入这些依赖；手动单例则需要你手动创建并传入依赖，容易导致依赖管理混乱。
• 灵活切换作用域：如果后续需要把SongController的作用域改成Activity级（@ActivityScoped），只需要改注解就行，不用重构整个单例实现逻辑。

4. 什么时候需要用手动单例？ #

只有极少数特殊场景：

• 你的类完全脱离Android框架，且不需要依赖注入（比如纯Java工具类）；
• 你需要严格控制实例的创建时机（比如在Application初始化之前就必须创建实例）。

但这些场景在Android开发中非常少见，绝大多数情况下Hilt的方案更合适。

内容的提问来源于stack exchange，提问作者Groot