锁粒度需平衡：过粗导致线程阻塞，过细则引发伪共享；应缩小同步范围、避免耗时操作、慎用读写锁，并根据硬件与JVM特性综合优化。
锁粒度太粗导致线程频繁阻塞
当多个不相关的操作共用同一把锁（比如整个 ArrayList 实例或一个 synchronized(this) 方法），实际只需要保护其中一小段临界区时，就会人为扩大竞争范围。典型表现是：CPU 使用率不高，但吞吐量上不去，jstack 显示大量线程处于 BLOCKED 状态。
解决思路不是“换锁”，而是“缩范围”：
- 把
synchronized块从方法级别下沉到仅包裹真正共享变量读写的几行代码 - 避免在同步块内做 I/O、远程调用、复杂计算等耗时操作
- 若涉及多个字段更新且需原子性，优先考虑用
java.util.concurrent.atomic类（如AtomicIntegerFieldUpdater）替代锁
过度细化锁粒度引发 cache line 伪共享
为提升并发度，有人会给每个对象字段单独加锁，甚至用 ReentrantLock[] 数组按哈希分桶。但现代 CPU 的缓存行（cache line）通常是 64 字节，相邻字段即使逻辑独立，也可能落在同一 cache line 上。当多个线程高频修改不同字段却命中同一 cache line，就会触发频繁的缓存失效（false sharing），性能反而比粗粒度还差。
识别和规避方法：
- 用
@Contended注解（需 JVM 启动参数-XX:-RestrictContended）隔离热点字段 - 手动 padding：在字段前后插入无用的
long字段（如private long p1, p2, p3, p4;）确保关键字段独占 cache line - 优先使用
Striped（来自 Guava）或LongAdder这类已内置分段/缓存友好设计的工具
ReadWriteLock 在读多写少场景下未必更优
很多人看到“读多写少”就直接上 ReentrantReadWriteLock，但它的读锁是非公平的，且读锁释放时可能唤醒所有等待的写线程，造成“惊群效应”。实测中，当读操作本身很轻（如只是取一个 int 值），使用 ReentrantReadWriteLock 反而比单纯 synchronized 慢 10%–30%。
是否启用读写锁，取决于三个条件：
- 读操作耗时明显大于锁获取开销（例如含简单计算或对象克隆）
- 写操作频率极低（如配置加载后基本只读）
- 没有强一致性要求——
ReentrantReadWriteLock不保证读操作看到的是最新写入值，除非写锁已完全释放并被其他线程观察到
更稳妥的选择是：先用 synchronized 实现，再用 JMH 做压测对比；若确实有瓶颈，再考虑 StampedLock（支持乐观读，失败后降级为悲观读）。
锁升级与偏向锁在高竞争场景下的副作用
JVM 默认开启偏向锁（-XX:+UseBiasedLocking），它在单线程反复进入同一锁时能省去 CAS 开销。但一旦发生竞争，JVM 必须撤销所有偏向锁，这个过程需要全局 safepoint，暂停所有应用线程。在高并发服务中，这会导致不可预测的 STW 延迟。
生产环境建议：
- 高并发 Web 服务、RPC 接口等场景，直接关闭偏向锁：
-XX:-UseBiasedLocking - 确认是否真需要锁升级（偏向 → 轻量 → 重量）：现代 JDK（10+）已默认禁用偏向锁，且轻量锁的自旋次数受
-XX:PreBlockSpin控制，但该参数已被废弃，实际由 JVM 自适应 - 真正影响性能的往往不是锁机制本身，而是临界区内对象分配、GC 压力或锁持有时间——用
async-profiler定位热点，比纠结锁类型更有效
锁的粒度从来不是越细越好，也不是越粗越稳；它必须和数据访问模式、硬件缓存特性、JVM 运行时行为一起看。最容易被忽略的一点是：很多所谓“并发瓶颈”，其实源于共享状态设计本身——如果能把状态拆成线程局部（ThreadLocal）、不可变（final + deep copy）或事件驱动（Actor 模型），往往比调优锁更彻底。
