如何选择适当的锁粒度？

为什么要选择匹配自己的锁粒度呢?

  锁粒度的选择直接影响程序的性能、吞吐量和线程安全
  选择适当的锁粒度，意味着在线程安全与并发效率之间找到最佳平衡点

锁粒度简介

锁粒度对系统影响

业务场景选择合适的锁粒度示例

 ✅ 场景一：低并发、操作简单 → 使用粗粒度锁

- 推荐锁：
  - `synchronized`
  - `ReentrantLock`

- 原因：
  - 实现简单，维护成本低。
  - 不需要为低并发引入复杂的锁机制。

- 示例：

```java
public synchronized void addData(Data data) {
    datalist.add(data);
}
 

 ✅ 场景二：高并发读写共享资源 → 使用细粒度锁或分段锁

- 推荐锁：
  - `ReentrantReadWriteLock`
  - `StampedLock`
  - `ConcurrentHashMap`（内部使用分段锁）

- 原因：
  - 提高并发访问效率。
  - 减少线程阻塞。

-例(使用 `ConcurrentHashMap`)
 
ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();
map.put("key1", 100);
Integer value = map.get("key1");
 
✅ 场景三：多线程协作任务 → 使用条件变量 + 细粒度锁
- 推荐锁：
  - `ReentrantLock` + `Condition`

- 原因：
  - 可以实现更灵活的等待/通知机制。
  - 控制不同线程之间的协作。

-例：
ReentrantLock lock = new ReentrantLock();
Condition notFull = lock.newCondition();
Condition notEmpty = lock.newCondition();

lock.lock();
try {
    while (queue.size() == capacity) {
        notFull.await();
    }
    queue.add(item);
    notEmpty.signal();
} finally {
    lock.unlock();
}

✅ 场景四：资源池、连接池等控制访问数量 → 使用 `Semaphore`

- 推荐锁：
  - `Semaphore`

- 原因：
  - 控制同时访问线程数量。
  - 不是对数据加锁，而是对资源访问进行限流。

-例:
Semaphore semaphore = new Semaphore(5); // 最多允许 5 个线程访问

semaphore.acquire();
try {
    // 访问资源
} finally {
    semaphore.release();
}

锁粒度常见误区与建议

各种锁粒度选择对比

锁粒度选择注意事项

  1.优先保证线程安全:
在多线程访问共享资源时，必须加锁
  2.尽量缩小锁的持有时间:
只锁定真正需要保护的部分
  3.根据并发程度调整锁粒度:
并发越高，锁越细
  4.结合实际业务需求选择锁类型:
不盲目追求“最先进”的锁，
而是“最适合当前场景”的锁