应优先用无锁结构（如ConcurrentHashMap、AtomicInteger）替代显式锁；必须加锁时，用ReentrantLock细粒度控制，只锁共享状态修改部分，并配合tryLock()、ThreadLocal等降低竞争。
用 ReentrantLock 替代 synchronized 做细粒度控制
synchronized 简单但粗放，锁住整个方法或代码块，容易把不相关的操作也串行化。而 ReentrantLock 支持可中断、超时获取、公平性选择，更重要的是能配合 tryLock() 实现非阻塞尝试，避免线程长时间挂起。
常见错误是直接用 lock() 包裹大段逻辑，结果锁持有时间过长；正确做法是只锁真正共享状态修改的部分，比如：
private final ReentrantLock lock = new ReentrantLock();
private int counter = 0;
public void increment() {
// 只锁计数器更新这一行
lock.lock();
try {
counter++;
} finally {
lock.unlock();
}
}
- 别在
lock()前做 I/O、远程调用或耗时计算 - 必须用
try-finally保证unlock()执行，否则会永久死锁 - 高竞争场景下考虑
lock.tryLock(1, TimeUnit.MILLISECONDS)配合退避重试
优先用无锁数据结构：从 ConcurrentHashMap 到 AtomicInteger
很多场景根本不需要显式加锁——只要操作是原子的、无依赖的，就该交给 JVM 底层的 CAS 指令处理。比如计数、状态标记、缓存读写。
ConcurrentHashMap 默认分段（Java 8+ 是基于 Node 数组 + TreeBin 的细粒度锁），比 Hashtable 或 synchronized(new HashMap()) 并发吞吐高得多；AtomicInteger 的 incrementAndGet() 比加锁自增快 3–5 倍。
立即学习“Java免费学习笔记（深入）”；
- 避免把
ConcurrentHashMap当普通Map用：containsKey()+put()不是原子的，要用computeIfAbsent() -
AtomicReference适合封装简单对象状态，但注意它不保证内部字段的可见性，别用来包装含多字段的可变对象 - 不要为了“看起来线程安全”而滥用
volatile：它只解决可见性，不解决原子性
减少锁范围：拆分共享状态，用 ThreadLocal 隔离线程视角
锁竞争本质是多个线程争同一块内存。如果能把共享状态按线程维度切开，就能彻底消除锁。比如数据库连接池里每个线程缓存一个连接，日志上下文里存 traceId，都适合用 ThreadLocal。
典型误用是把 ThreadLocal 当全局缓存用，或者忘了 remove() 导致内存泄漏（尤其在线程复用场景如 Tomcat 线程池）。
- 初始化用
withInitial(() -> new XXX())，避免每次get()都判空构造 - 在过滤器、拦截器或 finally 块中调用
threadLocal.remove() -
ThreadLocalRandom是ThreadLocal+Random的优化组合，比全局Random实例快且无竞争
锁升级策略：从无锁 → 偏向锁 → 轻量级锁 → 重量级锁的真实影响
JVM 的锁优化不是黑盒。偏向锁在单线程反复进入同一同步块时省去 CAS 开销；但一旦出现多线程竞争，就会触发撤销（revoke），这个过程要 STW，反而更慢。所以高并发服务通常建议关闭偏向锁：-XX:-UseBiasedLocking。
轻量级锁靠 CAS 尝试替换对象头中的 Mark Word，失败则膨胀为重量级锁（内核态互斥量）。这意味着：频繁失败的 CAS 本身就有开销，且锁膨胀不可逆。
- 观察
-XX:+PrintGCDetails和-XX:+PrintSafepointStatistics可发现偏向锁撤销是否频繁 - 热点同步块若被多个线程轮番进入，不如一开始就用
ReentrantLock显式控制 - 对象逃逸分析开启后（
-XX:+DoEscapeAnalysis），JIT 可能直接消除锁（锁消除），但这只适用于局部变量持有的锁
锁竞争不是越少越好，而是让等待时间尽可能短、唤醒路径尽可能直。真正难的不是选哪种锁，而是识别出哪些状态真的需要跨线程协调——其余的，尽量推给线程本地或无锁结构。
