java静态块执行时锁的是该类的class对象，jvm在首次主动使用类时自动加锁，仅对未完成初始化的类生效，初始化完成后释放；static final编译期常量不触发初始化；class.forname默认初始化而x.class不初始化；多classloader下锁互不影响。
Java静态块执行时到底锁了谁
类初始化锁不是你手动加的锁，而是JVM在首次主动使用某个类时，自动对Class对象加的内部锁。只有当线程真正触发类初始化（比如调用static方法、访问static字段、new该类实例等），JVM才会尝试获取这个锁；如果此时另一个线程正在初始化，当前线程就阻塞等待。
常见错误现象：Deadlock可能发生在静态块里又去主动加载另一个类，而对方也在做类似操作——比如A类静态块调用B.class，B类静态块又回头调用A.class，且两个线程各自卡在对方的初始化锁上。
- 只对“尚未完成初始化”的类生效；初始化完成后，锁就释放了，后续访问不抢锁
- 锁对象是
A.class本身，不是某个自定义对象，也不是ClassLoader - 子类初始化不会触发父类重新初始化，但会隐式要求父类已完成初始化（所以父类静态块可能更早被锁住）
为什么static final常量不走类初始化流程
编译期就能确定值的static final基本类型或字符串，在字节码里会被直接“内联”成常量值，根本不会触发类加载和初始化。也就是说，读取它不进锁、不执行静态块、也不抛ExceptionInInitializerError。
使用场景：你想让某个配置“看起来像静态变量”，又不想承担初始化风险，可以考虑用static final String + 编译期确定的字面量；但一旦值来自System.getProperty()或new String()，就立刻失去这个优化。
立即学习“Java免费学习笔记（深入）”；
-
static final int PORT = 8080;→ 不触发初始化 -
static final int PORT = Integer.parseInt("8080");→ 触发初始化（因为parseInt是运行时调用） -
static final String TOKEN = UUID.randomUUID().toString();→ 同样触发，且每次都是新值，无法用于编译期常量
Class.forName("X")和X.class初始化行为差异
这是最容易踩坑的地方。Class.forName("X")默认会触发初始化（即执行静态块），而X.class不会——它只是返回已加载的Class对象，哪怕类还没初始化过，也只到“已加载未链接”阶段为止。
性能影响：如果你只是想反射获取字段或方法，用X.class更快、更安全；如果真需要确保静态资源已就位（比如驱动注册），才用Class.forName("X", true, loader)。
-
Class.forName("com.example.Config")→ 执行静态块 -
Config.class→ 不执行，哪怕Config从未被用过 -
Class.forName("com.example.Config", false, loader)→ 等价于X.class，不初始化
多ClassLoader下类初始化锁还有效吗
无效。每个ClassLoader实例加载同一个类名，会产生不同的Class对象，它们的初始化锁互不干扰。也就是说，loader1.loadClass("A")和loader2.loadClass("A")的静态块会各自执行一次，彼此看不到对方的锁。
典型场景：OSGi、Spring Boot DevTools、热部署容器。你以为“只加载一次”，其实只是“在这个类加载器下只加载一次”。跨加载器的单例、静态缓存都会失效，甚至引发ClassCastException（因为A在两个loader下是不同类）。
- 检查是否真共享同一个
ClassLoader：打印A.class.getClassLoader() - 避免在静态字段里存跨loader可变状态，比如
static Map cache = new HashMap(); - 若必须共享，改用
java.util.concurrent.ConcurrentHashMap配合ClassLoader为key来隔离
最麻烦的不是锁没起作用，而是你根本意识不到有两个类同时存在——它们名字一样、代码一样、连toString()都长得一样，但就是不相等。
