Java单例类静态初始化死锁问题及解决方案咨询

DevOps 小满

2026-5-15

解决LibGDX单例静态初始化死锁的实用方案

你遇到的这个问题我太熟悉了——多个静态单例在类加载阶段互相调用getInstance()，导致循环等待类初始化锁，最后抛出RuntimeException崩溃。尤其是当单例数量多、依赖关系复杂时，手动拆解两两依赖根本行不通。好在不用完全放弃现有的单例结构，我们可以通过调整初始化逻辑来解决问题，下面给你几个可行的方案，按修改量从小到大排序：

一、最省心的方案：拆分初始化逻辑到独立方法

这个方案几乎不用改动单例的核心结构，只是把构造器里的依赖调用移到单独的初始化方法，彻底避免构造阶段的循环依赖：

步骤1：改造单例类

把构造器中调用其他单例getInstance()的代码全部移到新的init()方法里，构造器只做无依赖的基础初始化（比如初始化简单变量、创建空集合等）。示例代码：

public class Example1 {
    private static Example1 instance;

    // 静态块简化：类加载时的初始化本身就是线程安全的，不需要额外synchronized
    static {
        try {
            instance = new Example1();
        } catch (Exception e) {
            // 建议把异常也传进去，方便排查问题
            throw new RuntimeException("Failed to initialize Example1", e);
        }
    }

    // 构造器只做无依赖初始化
    private Example1() {
        // 比如：this.configMap = new HashMap<>();
        // 绝对不要在这里调用其他单例的getInstance()！
    }

    // 新增初始化方法，处理依赖逻辑
    public void init() {
        // 在这里安全调用其他单例
        Example2 example2 = Example2.getInstance();
        Example3 example3 = Example3.getInstance();
        // 执行依赖于其他单例的初始化操作
        this.someService = example2.getSomeService();
        this.dataProvider = example3.getDataProvider();
    }

    public static Example1 getInstance() {
        return instance;
    }
}

步骤2：主管理类按顺序初始化

在主管理类中，先一次性触发所有单例的实例创建（此时构造器无依赖，不会触发循环加载），再按照依赖顺序调用每个单例的init()方法：

public class MainManager {
    public void initAllManagers() {
        // 第一步：先创建所有单例实例（构造器无依赖，不会死锁）
        Example1.getInstance();
        Example2.getInstance();
        Example3.getInstance();
        Example4.getInstance();
        Example5.getInstance();
        Example6.getInstance();

        // 第二步：按依赖顺序调用init()
        // 比如：Example3不依赖任何其他单例，先初始化；Example2依赖Example3，次之；以此类推
        Example3.getInstance().init();
        Example2.getInstance().init();
        Example5.getInstance().init();
        Example4.getInstance().init();
        Example1.getInstance().init();
        Example6.getInstance().init();
    }
}

这里的关键是确定init()的调用顺序：如果A依赖B，那么B的init()必须在A之前执行。你可以把每个单例的依赖列出来，整理成一个拓扑顺序（比如画个依赖图），这样就能轻松确定执行顺序。

二、懒加载优化：避免类加载阶段的冲突

如果不想加init()方法，也可以把单例改成懒加载模式（第一次调用getInstance()时才初始化），避开类加载阶段的锁竞争。推荐用线程安全的Holder模式，实现起来很简洁：

public class Example2 {
    // 私有构造器
    private Example2() {
        // 注意：如果这里必须调用其他单例，要确保不会形成循环调用！
        // 比如如果Example2的构造器需要Example1，那Example1的构造器绝对不能调用Example2
    }

    // Holder类：JVM会保证Holder的静态初始化线程安全，且只有第一次调用getInstance()时才加载
    private static class Holder {
        private static final Example2 INSTANCE = new Example2();
    }

    public static Example2 getInstance() {
        return Holder.INSTANCE;
    }
}

不过这个方案有个限制：如果你的单例构造器必须依赖其他单例，那得确保依赖链是单向的（不能循环）。对于6个互相交互的类来说，这个限制可能很难满足，所以还是第一个方案更稳妥。

三、长远解决方案：依赖注入（DI）

如果想彻底解决单例耦合的问题，长远来看可以引入依赖注入框架（比如LibGDX自带的DependencyInjector，或者轻量级的Guice）。DI框架会帮你管理实例的创建和依赖注入，完全不需要手动写单例代码，也从根源上避免了循环依赖问题。不过这个方案需要修改更多代码，适合你后续重构时考虑。

为什么原来的静态块会导致死锁？

再给你解释下问题根源：Java类加载时的静态初始化是由类的Class对象锁保证线程安全的。当Example1加载时，它会持有Example1.class的锁，然后在构造器里调用Example2.getInstance()，触发Example2的类加载；Example2的静态初始化会持有Example2.class的锁，然后又调用Example1.getInstance()——这时候Example1的初始化还没完成，Example2会等待Example1的锁释放，而Example1又在等待Example2的初始化完成，形成死锁，最终抛出异常。

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

Java单例类静态初始化死锁问题及解决方案咨询

一、最省心的方案：拆分初始化逻辑到独立方法 #

步骤1：改造单例类 #

步骤2：主管理类按顺序初始化 #

二、懒加载优化：避免类加载阶段的冲突 #

三、长远解决方案：依赖注入（DI） #