Java子类引用静态初始化器引发类加载死锁，公共API下如何规避？

这个场景我太熟悉了——公共API类不能随便改，但多线程下类加载死锁的坑又实实在在存在，咱们先把问题掰明白，再给几个不破坏API的可行方案：

为什么会出现死锁？ #

当线程A开始加载父类ItemType时，初始化静态字段DURATION需要创建子类BuiltInAtomicItemType的实例，这会触发子类的加载；而如果同时有线程B先尝试加载子类BuiltInAtomicItemType，子类加载必须先完成父类ItemType的初始化（Java类加载规则：子类加载依赖父类已加载完成）。这下两个线程就卡住了：A等B加载完子类，B等A加载完父类，形成类加载循环等待死锁。

不修改公共API的解决方案 #

1. 启动阶段单线程预加载类 #

最简单的无侵入方案：在应用启动的单线程初始化环节（比如main方法开头、Spring的@PostConstruct初始化方法里），主动触发两个类的加载和初始化，把类加载的工作提前做完，后续多线程环境就不会出现竞争了。代码示例：

// 替换成你的实际包路径
Class.forName("com.yourpackage.ItemType");
Class.forName("com.yourpackage.ItemType.BuiltInAtomicItemType");

Class.forName()会触发类的初始化，确保静态字段和子类都加载完成，彻底避开多线程加载的冲突。

2. 微调代码用静态内部类懒加载（兼容原API） #

如果允许对代码做极小的、不影响公共API的修改（用户完全感知不到变化），可以用静态内部类的延迟加载机制重构静态字段的初始化：

public class ItemType {
    // 原公共字段完全保留，对外API毫无变化
    public static final ItemType DURATION = ItemTypeHolder.DURATION;

    // 静态内部类，只有当被访问时才会初始化
    private static class ItemTypeHolder {
        private static final ItemType DURATION = new BuiltInAtomicItemType(x);
    }

    static class BuiltInAtomicItemType extends ItemType {
        public BuiltInAtomicItemType(X x) {
            this.x = x;
        }
    }
}

Java的类加载机制保证了静态内部类的初始化是线程安全的，而且只有在首次访问DURATION时才会触发，同时父类ItemType的初始化完成后才会加载内部类，从根源上避免了父类和子类加载的循环依赖问题。

3. 容器层面调整类加载顺序 #

如果你的应用运行在Tomcat、Jetty这类容器里，可以配置类加载器的优先级，强制ItemType类在子类之前被加载。不过这种方式依赖容器特性，通用性不如前两种，但也是一种应急的规避手段。

总结 #

如果完全不能改代码，预加载类是最稳妥的选择；如果允许极小的代码优化，静态内部类懒加载是更优雅的长期方案，既能解决死锁，还能保持原API的兼容性。

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