静态代码块调用外部同步方法会因类初始化锁导致死锁。jvm对每个类加隐式initialization lock，若a类静态块调用b类方法而b又依赖a，则两线程互相等待clinit锁，造成启动卡住。
静态代码块里调用外部同步方法，为什么一启动就卡住？
Java 类初始化阶段可能被多个线程并发触发，而 JVM 会强制对每个类加一个隐式的 initialization lock。一旦某个线程在静态代码块中阻塞（比如等待另一个类完成初始化），又恰好那个类也在等当前类——死锁就成立了。
这不是理论风险，是真实发生的典型场景：比如 A.class 的静态块里调用了 B.doSomething()，而 B.class 的静态块又反向依赖 A.SOME_CONSTANT。
- JVM 规范要求类初始化必须串行化，但不保证跨类顺序，只靠“首次主动使用”触发
- 哪怕你没显式开线程，
ClassLoader.loadClass()、Class.forName()或反射访问静态字段都可能触发初始化 - 常见错误现象：
Thread.getState() == BLOCKED且堆栈停在java.lang.Class.forName或静态块某行，jstack 显示两个线程互相等待对方的initialization lock
如何快速定位哪个类在初始化时互相等待？
别猜，直接看线程快照。关键不是找“死锁”字样，而是找处于 CLINIT 状态的线程（即正在执行 <clinit></clinit> 方法）以及它们阻塞在哪个类上。
- 用
jstack -l <pid></pid>抓取线程 dump，搜索java.lang.Thread.State: BLOCKED (on object monitor)和at java.lang.Class.forName或at <clinit></clinit> - 重点关注堆栈里连续出现的两个类，比如线程1卡在
A.<clinit></clinit>等待B.class，线程2卡在B.<clinit></clinit>等待A.class - IDE 调试时，在静态块第一行设断点，然后用
Ctrl+Break（Windows）或kill -3（Linux/macOS）触发线程 dump，比单步更可靠
static final 字段初始化顺序，为什么不能靠写法“控制”？
很多人以为把 A 的静态字段写在 B 前面，或者用 static {} 块手动排序就能避免问题——不行。JVM 不按源码顺序初始化类，只按“首次主动使用”的时机决定谁先触发。
立即学习“Java免费学习笔记（深入）”；
-
static final int X = B.Y + 1;这种写法，会强制先触发B初始化；但如果B又引用了A.X，就构成循环依赖 - 编译期常量（如
static final int X = 42;）会被内联，不触发初始化；但只要涉及方法调用、非编译期常量表达式，就会触发 - 工具类如
Objects.requireNonNull()、Logger.getLogger()在静态块里调用，也可能间接触发其他类初始化（比如Logger初始化时加载Handler子类）
安全替代方案：延迟到第一次使用再初始化
把静态资源从类加载期挪到运行期，彻底绕过 <clinit></clinit> 阶段的锁竞争。核心思路是用“懒汉式 + volatile + double-check”或 Holder 模式，而不是在 static 块里硬扛。
- 推荐
Holder模式：定义私有静态内部类private static class Holder { static final A INSTANCE = new A(); }，首次调用Holder.INSTANCE才触发初始化，且由 JVM 保证线程安全 - 避免在静态块中做任何可能触发其他类初始化的操作：不要调用非本类的静态方法、不要访问其他类的静态字段、不要 new 其他类实例（除非确定该类无静态初始化逻辑）
- 如果必须预热资源，改用显式初始化方法，比如
public static void init() { ... }，由应用启动流程统一调用，而非依赖类加载自动触发
最麻烦的不是写错，是错得悄无声息——程序在单线程下永远正常，一上生产环境并发加载就偶发挂起。初始化顺序不是靠经验猜出来的，得靠线程 dump 说话。
