如何解决类路径下静态代码块重复执行导致的变量初始化难点

静态代码块本身只执行一次——但多类加载器各自加载同一个类时，会触发多次独立初始化。可以通过日志输出类加载器来验证；推荐使用带锁的静态标志位配合类加载器标识，控制全局单次初始化。

很多人一听到“静态代码块重复执行”，第一反应是代码有bug。其实静态代码块本身绝不会自己跑两遍——它在类被加载时只运行一次。所谓的“重复执行”，真实原因是多个类加载器各自加载了同一个类，每个加载器都触发了一次独立的静态初始化。

根本原因：类加载器隔离

同一个类名，被不同的类加载器（比如 Tomcat 的 WebAppClassLoader 和 SharedClassLoader、Spring Boot DevTools 的重启类加载器、OSGi 的 BundleClassLoader）分别加载，JVM 会把这些视为完全不同的类。它们各自拥有独立的 Class 对象、独立的静态变量空间，自然也会各自独立地执行一次静态块。

• 一个典型的例子：配置文件读取逻辑写在静态块里，两个加载器各跑一遍，结果就是“两次加载配置”“两次注册监听器”这类现象。
• 这种问题常见于热部署、微服务模块隔离、插件化架构，以及测试中反复 reload 类的场景。

验证是否真为多加载器问题

要确认是不是类加载器导致的，最简单的方法就是在静态块里加一行日志，输出当前类的类加载器身份：

static {
    System.out.println("Static init triggered by: " + MyClass.class.getClassLoader());
    // ... your init logic
}

• 如果日志打印出两个不同的类加载器（比如 WebAppClassLoader@1234 和 ParallelWebappClassLoader@5678），那基本可以确定是加载器隔离引起的。
• 注意：SystemClassLoader 或 AppClassLoader 通常只有一份，重复出现的往往是自定义或容器级加载器。

可靠解法：用 ClassLoader 做初始化守门人

不依赖“类是否已加载”这种隐式机制，而是显式控制“某段逻辑全局只执行一次”。推荐使用带锁的静态标志位 + 类加载器标识：

private static volatile boolean initialized = false;
private static final Object initLock = new Object();

static {
    ClassLoader loader = MyClass.class.getClassLoader();
    synchronized (initLock) {
        if (!initialized) {
            doActualInit(); // 真正的初始化逻辑
            initialized = true;
            System.out.println("Initialized once for classloader: " + loader);
        }
    }
}

• 这种方式不依赖 JVM 类加载机制的“单次性”，而是靠应用层自己控制，更可靠。
• 如果需要在多个类加载器之间共享状态（比如统一配置缓存），应该把初始化逻辑移到共享类加载器（如 SystemClassLoader）加载的工具类中。
• 避免在静态块里用 Class.forName(..., true, loader) 主动触发其他类加载——容易引发循环依赖或死锁。

替代方案：延迟初始化 + 显式控制

有些人觉得上面的方式还是有点绕，想彻底绕开类加载时机不可控的问题。那可以把初始化推迟到第一次真正需要时，由调用方明确触发：

• 将静态块里的逻辑封装进一个 public static void initialize() 方法。
• 所有使用方（比如 Spring 的 @PostConstruct、Servlet 的 init()、主应用启动流程）统一调用它一次。
• 方法内部仍可以用双重检查锁确保线程安全，而且还能捕获异常、加重试逻辑、记录上下文，灵活性更高。