synchronized锁对象本质是this、Class或显式指定对象；常见错误是用可变或常量池对象作锁；应优先用private final Object作锁，避免锁this或getClass()。
synchronized 关键字怎么用才不踩坑
它是最常用的线程同步语法，但很多人只记得加在方法上，却忽略了锁对象的本质。synchronized 修饰实例方法时，锁的是 this；修饰静态方法时，锁的是当前类的 Class 对象；写在代码块里时，必须显式指定一个非 null 的锁对象。
常见错误是用可变对象（比如 new Object() 每次都新建）当锁，导致实际没锁住；或者用 String、Integer 这类可能被常量池复用的对象，引发意外的锁竞争。
实操建议：
- 优先使用私有 final 对象作锁，比如
private final Object lock = new Object(); - 避免锁
this，除非你完全控制该对象的暴露范围 - 不要锁
getClass()或MyClass.class以外的类对象，子类继承后容易破坏同步语义
public class Counter {
private int count = 0;
private final Object lock = new Object();
public void increment() {
syn
chronized (lock) {
count++;
}
}
}
chronized (lock) {
count++;
}
}
}ReentrantLock 和 synchronized 选哪个
ReentrantLock 是 java.util.concurrent.locks 包里的显式锁，不是语法糖，需要手动 lock() 和 unlock()。它比 synchronized 多出三个关键能力：可中断等待（lockInterruptibly()）、超时获取（tryLock(long, TimeUnit)）、公平锁选择（构造时传 true）。
但代价是容易忘记 unlock()，尤其在异常分支里——必须放在 finally 块中。synchronized 则由 JVM 自动释放，更安全。
实操建议：
- 普通同步场景，优先用
synchronized：简洁、不易出错、JVM 优化成熟 - 需要响应中断或设定超时，才用
ReentrantLock - 永远用
try-finally包裹lock()，别依赖 try-with-resources（它不适用于 Lock）
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
// 临界区操作
} finally {
lock.unlock(); // 必须放这里
}
volatile 能不能代替锁
不能。volatile 只保证变量的「可见性」和「禁止指令重排序」，不提供原子性。对 count++ 这种读-改-写操作，volatile 完全无效——多个线程仍可能同时读到旧值，然后各自加 1 再写回。
它适合的场景非常有限：布尔标志位（如 running）、单次写入后只读的状态变量、配合 CAS 使用的变量（如 AtomicInteger 内部）。
实操建议：
- 只要涉及复合操作（++、--、+=、对象引用更新后再调用其方法），就必须用锁或原子类
- volatile 不能用于保护整个对象状态，只能作用于单个字段
- 别把 volatile 当轻量级 synchronized 用，语义完全不同
死锁的典型模式和快速定位方法
最常见的是两个线程按不同顺序获取两把锁：线程 A 先锁 lock1 再等 lock2，线程 B 先锁 lock2 再等 lock1。JVM 能检测到这种循环等待，但只限于 synchronized 锁（对 ReentrantLock 需靠 ThreadMXBean 主动查）。
排查时先用 jstack 看线程堆栈，搜索 java.lang.Thread.State: BLOCKED 和 waiting to lock；再检查锁对象哈希值是否成对出现。
实操建议：
- 所有线程按固定全局顺序获取锁（比如按锁对象的
System.identityHashCode()升序） - 尽量缩小临界区，避免在持锁时调用外部方法（可能隐含另一次锁获取）
- 用
ReentrantLock.tryLock()做非阻塞尝试，失败就释放已持锁并重试，打破循环等待
真正难处理的是锁嵌套过深、或锁与 I/O、回调混在一起的情况——这时候光看语法没用，得结合线程 dump 和业务逻辑一起推演。
