类初始化锁是jvm内置的原子机制，通过类元数据上的底层互斥原语确保同一类的仅被一个线程执行，其余线程阻塞等待，初始化完成后自动插入内存屏障保证可见性，无需synchronized参与。
初始化阶段的类构造器（<clinit></clinit>）是线程安全的，根本原因不在于Java代码加了什么锁，而在于JVM底层用C++实现的一套原子保障机制——它天然串行化所有线程对同一类的首次初始化请求。
类初始化不是靠synchronized实现的
很多人误以为是用了synchronized(Class.class)，其实不是。JVM在加载类后、执行<clinit></clinit>前，会检查该类是否已完成初始化。若未完成，JVM会尝试获取该类元数据（Klass*结构）上的内部锁。这个锁不是Java对象锁（monitor），而是直接作用于类的运行时常量池和静态字段内存布局的底层互斥原语。
关键点：
- 锁对象是类的元数据本身，所有线程对同一个类的初始化请求，都竞争同一把“类级”锁
- 没有成功获取锁的线程会被挂起，不会执行
<clinit></clinit>，也不会读到部分初始化的静态变量 - 初始化完成后，JVM自动插入内存屏障（memory barrier），确保该类所有静态字段的写入对其他线程立即可见
为什么你写synchronized也模拟不了这个效果
你自己在静态代码块里加synchronized(XXX.class)，只能保证Java层同步，但无法复现JVM级保障：
- 它不能阻止其他线程在你加锁前就已进入
<clinit></clinit>（因为<clinit></clinit>触发时机由JVM控制，比如首次主动使用类的静态成员） - 它不控制类加载过程中的链接（linking）阶段，而真正的初始化安全是在“准备→初始化”跃迁时由JVM原子完成的
- 它无法保证final静态字段的正确发布——JVM在
<clinit></clinit>结束时才将final字段标记为“已稳定”，这是语言规范强制要求
从现象反推你能观察到的证据
你可以通过几个典型现象验证这个机制真实存在：
- 多个线程同时触发同一个未初始化类的静态字段访问，最终只有1个线程执行
<clinit></clinit>，其余全部阻塞等待，且无重复执行 - 在
<clinit></clinit>中抛出异常（如ExceptionInInitializerError），该类会永久处于“初始化失败”状态，后续任何线程访问都会直接抛相同异常——说明JVM记录了明确的初始化终态 - 用JDK自带工具
jstack查看线程堆栈，会看到类似"VM Thread" blocked on (a java.lang.Class for xxx)的提示，这是JVM线程在等类初始化锁
本质上，这是JVM为你免费提供的、无需编码参与的单例保障——每个类的<clinit></clinit>就是它自己的、最轻量又最可靠的“双重检查+volatile+final”组合体。
