Guice单例绑定失效原因分析与正确初始化方案

有没有遇到过这样的场景？在 Guice 中，明明给 @Provides 方法加上了 @Singleton，信心满满地以为这个实例只会被创建一次，结果日志里却一连打印出三遍“Bean getting created”——构造函数被反复调用，单例语义形同虚设。更头疼的是，如果这个 Guice 库被封装成跨框架组件（比如集成到 Spring 中），这种问题很容易被埋进复杂的初始化逻辑里，调试起来相当棘手。

本文就围绕这个典型问题，拆解其根本原因，并提供一套线程安全、符合 DI 规范的最佳实践。

先看一个典型的错误模式：每次调用 Library.initializeLib(...) 都新建一个 Library 实例，构造函数里却还藏着 createInjector() 的逻辑——即使静态字段里已经存了 injector，也不会去复用，而是重新建一个。这么一来，injector.getInstance(...) 拿到的永远是新 injector 里的实例，@Singleton 自然就成了摆设。更隐蔽的是，条件判断写反了：if (Objects.nonNull(injector)) 本意应该是判断是否为空，结果非空才创建，等于永远不创建？还有，日志里那句“Bean getting created”记录的其实是 injector 的创建，跟目标 bean 的实例化根本不是一回事，严重误导调试方向。

核心问题就一句话：初始化逻辑和 DI 生命周期错位了。

正确的做法是什么呢？把 injector 的初始化与 Library 实例完全解耦，保证全局唯一、惰性加载且线程安全。来看一个标准实现：

public final class Library {
    private static volatile Injector injector;
    // 私有构造，禁止外部实例化
    private Library() {}

    // 惰性、双重检查锁定的 injector 初始化
    private static Injector getInjector(LibraryModule module) {
        if (injector == null) {
            synchronized (Library.class) {
                if (injector == null) {
                    injector = Guice.createInjector(module);
                }
            }
        }
        return injector;
    }

    public static SomeExposedComponent initializeLib(SomeClass someClass) {
        // 注意：此处不应传入 someClass 到 injector 创建阶段，
        // 而应通过 Module 绑定或 Provider 处理运行时依赖
        Injector injector = getInjector(new LibraryModule());
        return injector.getInstance(SomeExposedComponent.class);
    }
}

对应地，在 Guice 模块中，也要避免在 @Provides @Singleton 方法里调用外部初始化逻辑：

public class ServiceModule extends AbstractModule {
    @Override
    protected void configure(Binder binder) {}

    @Provides
    @Singleton
    public SomeExposedComponent provideSomeExposedComponent(
            SomeClass someClass, 
            Library library // 注入已初始化的 Library 工具类（非必需）
    ) {
        // ✅ 正确：依赖由 Guice 自动注入，不主动触发 initializeLib
        // 若 SomeExposedComponent 构造需 someClass，应在 LibraryModule 中声明 binding
        return new SomeExposedComponent(someClass); // 或由 injector 管理
    }
}

这里有几个关键注意事项，必须牢记：

• 不要在 @Provides 方法内调用 Library.initializeLib(...)——这相当于绕过 Guice 的实例管理，@Singleton 自然失效；
• 运行时参数（如 SomeClass）应当通过 Guice 绑定传递，比如在 LibraryModule 中定义 bind(SomeClass.class).toInstance(someClass)，或者使用 Provider；
• 跨框架集成时，推荐将 Guice injector 封装为独立服务，Spring 侧通过 @Bean 委托调用，而不是混用 @Provides；
• 务必校验 injector 初始化条件：写成 if (injector == null)，而不是 nonNull；同时采用 volatile + 双重检查锁，保证线程安全。

总结一下：Guice 的 @Singleton 保障的是 同一个 injector 内部 的单例。任何绕过 injector 直接 new 实例的行为、重复创建 injector 的做法、或者在 provider 里手动触发初始化的写法，都会撕毁这个契约。正确的解法其实很简单——让 injector 成为真正全局、惰性、线程安全的单点入口，所有 bean 的获取都统一经由这个 injector 完成。这样一来，单例语义就稳了，跨框架集成也清爽多了。