synchronized不能修饰构造方法，因对象未创建完成、this不可用，编译报错；需线程安全初始化时应使用静态锁、双重检查或AtomicBoolean。
为什么synchronized不能修饰构造方法
Java语法明确禁止用 synchronized 修饰构造方法——因为对象还没完全创建出来，锁对象（this）尚未就绪，此时加锁无意义，编译器会直接报错 illegal modifier for constructor。
如果你真需要在对象初始化阶段做线程安全控制，常见做法是：
- 把初始化逻辑抽到一个
private static final Object INIT_LOCK = new Object();上同步 - 或使用双重检查 +
volatile字段（适用于单例等场景） - 更推荐用
java.util.concurrent.atomic.AtomicBoolean控制初始化状态，避免锁开销
synchronized(this) 和 synchronized(类.class) 的区别
前者锁的是当前实例对象，后者锁的是类的 Class 对象，作用域完全不同：
-
synchronized(this)：只阻塞同一对象上的多个线程，不同实例之间互不影响 -
synchronized(MyClass.class)：所有该类的实例、静态方法、类初始化都会被同一把锁串行化
典型误用：在工具类中写 synchronized(this)，但调用方每次 new 一个新对象，等于没锁——这时应改用 MyClass.class 或私有静态锁对象。
立即学习“Java免费学习笔记（深入）”；
wait()/notify() 必须在 synchronized 块里调用
否则抛出 IllegalMonitorStateException。这不是约定，是 JVM 强制要求：只有持有对象监视器（monitor）的线程，才能操作其等待队列。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
常见陷阱：
- 在
synchronized块外调用wait()，哪怕只差一行缩进也会崩溃 - 用
notify()而不是notifyAll()，导致部分等待线程永远收不到唤醒（尤其在多个条件共用同一把锁时） - 忘记在
while循环里检查条件，而是用if——虚假唤醒（spurious wakeup）会让线程跳过条件判断直接执行后续逻辑
正确写法示例：
synchronized (lock) {
while (!ready) {
lock.wait();
}
// do work
}synchronized 和 ReentrantLock 在锁升级上的实际差异
JVM 对 synchronized 做了大量优化，从偏向锁 → 轻量级锁 → 重量级锁的升级路径是自动且不可控的；而 ReentrantLock 本质就是基于 AQS 的重量级锁实现，没有“升级”概念，但支持可中断、超时、公平性等特性。
这意味着：
- 高竞争下，
synchronized可能比ReentrantLock更快（JIT 编译后内联、锁消除等优化生效） - 但你需要
tryLock(1, TimeUnit.SECONDS)这种能力时，synchronized完全无法替代 - 排查死锁时，
jstack输出里synchronized显示为- locked，而ReentrantLock显示为java.util.concurrent.locks.ReentrantLock$NonfairSync，定位方式不同
真正容易被忽略的一点：synchronized 锁的是对象头里的 mark word，而对象是否能被锁，取决于它是否已分配到堆上——逃逸分析未生效时，锁可能根本不会进入轻量级状态。
