应优先用无锁数据结构替代加锁，如ConcurrentHashMap、LongAdder、AtomicInteger等；细粒度控制需按业务拆分锁或哈希分段；避免锁升级，确保锁对象私有、final、稳定；读多写少用读写锁，极简读场景可选StampedLock。
用 ReentrantLock 替代 synchronized 做细粒度控制
synchronized 简单但粗放，锁住整个方法或代码块，容易让不相关的线程互相阻塞。换成 ReentrantLock 后，你可以按业务逻辑拆分临界区，比如把“查库存”和“扣库存”拆成两个独立锁，或对不同商品 ID 使用不同锁实例。
常见错误是直接用一个全局 ReentrantLock 代替所有 synchronized，结果锁竞争一点没少。真正有效的做法是：
- 为高频并发资源（如缓存桶、分段 Map）创建多个
ReentrantLock实例，用哈希取模分配 - 避免在
lock()和unlock()之间做耗时操作（如远程调用、IO） - 务必在
finally块中调用unlock()，否则可能永久死锁
优先用无锁数据结构替代加锁容器
不是所有共享状态都需要锁。JDK 提供的 ConcurrentHashMap、AtomicInteger、LongAdder 等，底层基于 CAS 和分段思想，在多数场景下比手动加锁快得多，且不易出错。
例如高并发计数场景，用 LongAdder 替代 synchronized + int，性能提升常达 5–10 倍；而 ConcurrentHashMap 的 computeIfAbsent 能安全完成“检查-创建-返回”三步，无需额外同步。
立即学习“Java免费学习笔记（深入）”；
注意点：
-
ConcurrentHashMap的size()不是 O(1)，它要遍历所有 segment，高并发下慎用 -
AtomicReference在需要原子更新对象引用时比锁更轻量，但不适用于复合逻辑（如先读再条件写） - 别为了“无锁”强行套用
Unsafe或自旋锁，JVM 对synchronized的锁消除和偏向优化已很成熟
避免锁升级和 monitor 争抢：减少 synchronized 误用
JVM 对 synchronized 做了大量优化，但前提是锁对象稳定、竞争低。一旦出现锁膨胀（从偏向锁 → 轻量级锁 → 重量级锁），每次进入临界区都要触发 OS mutex，性能断崖下跌。
典型诱因包括：
- 用可变对象（如
new Object()或临时字符串）作锁，导致无法启用偏向锁 - 在循环内反复
synchronized同一对象，但每次只做微小操作，放大上下文切换开销 - 锁对象被多个无关模块共用（比如全系统都用
MyClass.class当锁）
实操建议：
- 锁对象声明为
private final Object lock = new Object();，确保唯一性和不可变性 - 把多次小同步合并为一次大同步（但需权衡持有时间，防止阻塞太久）
- 用 JFR 或
jstack观察线程堆栈里是否频繁出现Object.wait()或Unsafe.park()，这是重量级锁已生效的信号
用读写锁分离读多写少场景
如果某个状态被大量读取、极少修改（如配置中心的本地副本、路由表），ReentrantReadWriteLock 能显著提升吞吐。读锁可重入、允许多个线程同时持有；写锁独占，且会阻塞新读锁获取。
但要注意：
- 写锁获取前，所有等待的读锁和写锁都会排队，写操作频繁时反而比普通锁更慢
-
StampedLock更轻量，支持乐观读（tryOptimisticRead），适合读远多于写的极简场景，但它不支持重入，且使用不当易出错 - 不要在读锁内调用可能升级为写锁的方法（如某些集合的
computeIfAbsent内部会写），会导致死锁
锁竞争不是靠“换更高级的锁”解决的，而是靠识别真正共享的变量、缩小临界区、以及用合适语义的数据结构替代裸锁。很多所谓“性能瓶颈”，其实只是锁范围划错了。
