Java虚拟机通过类的方法加锁实现类初始化，确保静态代码块仅执行一次；多线程首次使用同一类时，JVM用Class对象内置锁保证初始化排他性，异常会导致初始化失败且不可逆。
Java 虚拟机对类初始化的锁获取逻辑，本质上是通过类的 <clinit></clinit> 方法加锁实现的——这个过程对开发者透明，但它的行为直接反映在代码块执行顺序上。掌握它不需要深入 JVM 源码，只需观察“多线程首次主动使用同一类”时静态代码块的执行表现即可。
静态代码块执行一次就说明初始化锁已生效
当多个线程同时执行 new MyClass()，而 MyClass 尚未初始化，JVM 会确保只有一个线程进入 <clinit></clinit> 执行静态代码块，其余线程阻塞等待。这正是类初始化锁（java.lang.Class 对象的 intrinsic lock）的作用。
- 静态代码块只输出一次 → 表明 JVM 成功用锁排他性地完成了初始化
- 若出现两次或以上相同静态块输出 → 说明类被重复加载（如不同 ClassLoader），不是锁失效，而是根本没走同一条初始化路径
- 没有同步关键字、没有显式锁操作，但效果等价于：
synchronized(MyClass.class) { /* 执行静态初始化 */ }
用双重检查验证锁的阻塞与唤醒行为
写一个带延时和日志的静态块，配合两个线程启动，能直观看到锁的抢占和等待：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 在静态块第一行打印“开始初始化”，最后一行打印“初始化完成”
- 主线程启动后立即 fork 两个子线程，都调用
MyClass.getValue()（一个静态方法） - 观察输出：必然先出现一个“开始初始化”，再出现“初始化完成”，之后才出现第二个线程的返回值 —— 中间空档就是另一个线程在等待锁释放
- 注意：不能用
System.out.println做精确计时，但日志顺序绝对可靠
继承场景下锁按类粒度独立获取
父类和子类各有自己的 <clinit></clinit> 和对应锁。它们的初始化锁互不干扰，但有严格触发依赖：
- 子类初始化一定会触发父类初始化，所以父类锁先被获取并释放，子类锁才可能被争抢
- 若线程 A 正在初始化父类，线程 B 尝试 new 子类 → B 会先等待父类锁，父类完成后才尝试获取子类锁
- 若线程 C 同时调用
Parent.doStatic()，它只争抢Parent.class的锁，与子类初始化无直接竞争 - 每个类的锁只保护自己那块静态初始化逻辑，不跨类
异常会释放锁并标记类为“初始化失败”
这是实战中最容易忽略的关键点：静态块中抛出未捕获异常，会导致锁释放，且该类后续任何主动使用都会立即抛 ExceptionInInitializerError。
- 例如：静态块里读配置文件失败 → 第一个线程抛异常，锁释放；第二个线程进来直接报错，不再重试初始化
- 这种状态不可逆，重启应用或重新加载类（新 ClassLoader）才能恢复
- 因此，静态块内应尽量避免可能失败的 I/O 或网络操作；必须做时，要 try-catch 并提供默认值或明确兜底逻辑
- 可通过
Class.forName("X", false, loader)+loadClass绕过初始化，但无法绕过已失败的类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
