独占锁
独占锁（Exclusive Lock），又称排他锁或写锁，是一种同步机制，它确保在任一时刻，最多只有一个线程可以获得锁并对受保护的资源进行访问或修改。一旦线程获得了独占锁，其他所有试图获取同一锁的线程将被阻塞，直到拥有锁的线程释放锁为止。独占锁主要用于保护那些在并发环境下会被多个线程修改的共享资源，确保在修改期间不会有其他线程干扰，从而维护数据的一致性和完整性。
对于独占锁就像图书馆里的某本书，这本书只有唯一的一本。当一个读者想要借阅这本书时，他会去图书管理员那里登记并拿到一个“借书凭证”（相当于独占锁）。此时，这本书就被锁定了，其他读者无法借阅这本书，直至第一个读者归还书本并交回“借书凭证”。这就像是线程获得了独占锁，只有拥有锁的线程可以修改或操作资源（书本），其他线程必须等待锁的释放才能执行相应的操作。
独占锁的实现方式
- synchronized关键字：
通过synchronized关键字实现的隐式锁，它是独占锁的一种常见形式，任何时刻只有一个线程可以进入被synchronized修饰的方法或代码块。
- ReentrantLock：
可重入的独占锁，提供了更多的控制方式，包括可中断锁、公平锁和非公平锁等。
场景示例及其示例代码
场景1 ：银行账户转账（synchronized实现）
在银行账户转账场景中，我们需要确保在转账过程中，账户的余额不会被其他操作干扰（例如同时进行的转账或查询），以避免出现数据不一致。
public class BankAccount {
private double balance;
public BankAccount(double initialBalance) {
this.balance = initialBalance;
}
// 使用synchronized方法实现独占锁
public synchronized void transfer(BankAccount target, double amount) {
if (this.balance < amount) {
System.out.println("余额不足，转账失败");
return;
}
// 模拟实际业务处理时间
try { Thread.sleep(100); } catch (InterruptedException e) {}
this.balance -= amount;
target.deposit(amount); // 调用同步方法
System.out.printf("转账成功: %.2f元 | 余额: %.2f%n", amount, balance);
}
// 存款操作也需要同步
public synchronized void deposit(double amount) {
balance += amount;
}
}
// 测试代码
public static void main(String[] args) {
BankAccount acc1 = new BankAccount(1000);
BankAccount acc2 = new BankAccount(1000);
// 模拟多线程转账
new Thread(() -> acc1.transfer(acc2, 200)).start();
new Thread(() -> acc1.transfer(acc2, 300)).start();
}
线程1先获得锁的情况
运行结果：
转账成功: 200.00元 | 余额: 800.00
转账成功: 300.00元 | 余额: 500.00执行流程：
线程1获得acc1的锁
检查acc1余额(1000>200)，通过检查
线程1休眠100ms
acc1余额扣除200 → 800元
调用acc2.deposit(200)（获取acc2的锁）
acc2余额增加200 → 1200元
打印第一条消息
线程1释放所有锁
线程2获得acc1的锁
检查acc1余额(800>300)，通过检查
线程2休眠100ms
acc1余额扣除300 → 500元
deposit(300)（获取acc2的锁）
acc2余额增加300 → 1500元
打印第二条消息线程2先获得的锁的情况
运行结果：
转账成功: 300.00元 | 余额: 700.00
转账成功: 200.00元 | 余额: 500.00执行流程：
线程2获得acc1的锁
检查acc1余额(1000>300)，通过检查
线程2休眠100ms
acc1余额扣除300 → 700元
调用acc2.deposit(300)
acc2余额增加300 → 1300元
打印第一条消息
线程2释放所有锁
线程1获得acc1的锁
检查acc1余额(700>200)，通过检查
线程1休眠100ms
acc1余额扣除200 → 500元
调用acc2.deposit(200)
acc2余额增加200 → 1500元
打印第二条消息
场景2：库存管理系统（ReentrantLock实现）
电商秒杀场景下的库存扣减，多用户同时抢购限量商品，库存数量为共享资源，需确保库存不会超卖（扣减至负数）
import java.util.concurrent.locks.*;
public class InventorySystem {
private int stock = 10;
private final Lock lock = new ReentrantLock(); // 独占锁
public void purchase(int quantity) {
lock.lock(); // 获取锁
try {
if (stock >= quantity) {
// 模拟数据库操作
try { Thread.sleep(50); } catch (InterruptedException e) {}
stock -= quantity;
System.out.println(Thread.currentThread().getName()
+ " 购买成功, 剩余库存: " + stock);
} else {
System.out.println("库存不足，购买失败");
}
} finally {
lock.unlock(); // 确保释放锁
}
}
}
// 测试代码
public static void main(String[] args) {
InventorySystem store = new InventorySystem();
// 模拟10个用户同时抢购
for (int i = 0; i < 10; i++) {
new Thread(() -> store.purchase(1), "用户" + i).start();
}
}
运行结果：
用户1 购买成功, 剩余库存: 9
用户0 购买成功, 剩余库存: 8
用户3 购买成功, 剩余库存: 7
用户2 购买成功, 剩余库存: 6
用户5 购买成功, 剩余库存: 5
用户4 购买成功, 剩余库存: 4
用户7 购买成功, 剩余库存: 3
用户6 购买成功, 剩余库存: 2
用户9 购买成功, 剩余库存: 1
用户8 购买成功, 剩余库存: 0执行过程：
timeline
title 线程执行顺序
section 时间轴
线程A : 获取锁 → 处理50ms → 释放锁
线程B : 等待 → 获取锁 → 处理50ms → 释放锁
线程C : 等待 → 获取锁 → ...
场景3：配置中心更新（带超时的独占锁）
分布式系统中的配置更新，配置为全局共享资源，更新操作需要独占访问，避免更新阻塞导致系统瘫痪
import java.util.concurrent.locks.*;
public class ConfigManager {
private String config = "默认配置";
private final ReentrantLock lock = new ReentrantLock();
public void updateConfig(String newConfig) {
try {
// 尝试在500ms内获取锁
if (lock.tryLock(500, TimeUnit.MILLISECONDS)) {
try {
// 模拟配置更新耗时
Thread.sleep(200);
config = newConfig;
System.out.println("配置更新成功: " + config);
} finally {
lock.unlock();
}
} else {
System.out.println("更新超时，其他线程正在修改配置");
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
// 测试代码
public static void main(String[] args) {
ConfigManager configManager = new ConfigManager();
new Thread(() -> configManager.updateConfig("配置A")).start();
new Thread(() -> configManager.updateConfig("配置B")).start();
}
synchronized 和ReentrantLock 关键性对比
|
特性 |
synchronized |
ReentrantLock |
|
获取方式 |
JVM隐式管理 |
手动lock()/unlock() |
|
超时控制 |
❌ 不支持 |
✅ tryLock(timeout) |
|
中断响应 |
❌ 阻塞不可中断 |
✅ lockInterruptibly() |
|
公平性 |
❌ 非公平锁 |
✅ 可选择公平/非公平 |
|
条件队列 |
✅ wait()/notify() |
✅ 支持多个Condition |
|
锁粒度 |
方法/代码块级 |
灵活控制临界区范围 |
独占锁使用总结
使用建议：
简单场景：优先使用synchronized（简洁安全）
复杂需求：需要超时控制、可中断锁时使用ReentrantLock
最佳实践：
锁范围尽量缩小（减少阻塞时间）
避免锁嵌套（防止死锁）
ReentrantLock务必在finally中释放锁
高并发场景考虑使用读写锁（ReentrantReadWriteLock）优化性能
示例中的sleep()模拟了真实业务中的I/O操作或复杂计算，在实际生产环境中，这些操作会导致线程阻塞，使锁竞争问题更加凸显
独占锁的优缺点：
-
优点：
-
简单易用：对于synchronized关键字，语法简单直观，易于理解和使用。
-
线程安全：确保了对共享资源的独占访问，避免了并发环境下的数据竞争问题。
-
可重入性：像ReentrantLock这样的锁，支持同一个线程重复获取同一把锁，提高了线程间协作的便利性。
-
缺点：
-
粒度固定：对于synchronized，锁的粒度是固定的，无法动态调整，可能导致不必要的阻塞。
-
缺乏灵活性：隐式锁不能主动中断等待锁的线程，也无法设置超时等待。
-
性能瓶颈：在高度竞争的环境中，synchronized可能会造成上下文切换频繁，效率低下；而显式锁虽提供了更灵活的控制，但如果使用不当也可能导致额外的性能损失。
共享锁：
共享锁（Shared Lock）也称为读锁（Read Lock），是一种多线程或多进程并发控制的同步机制，它允许多个线程同时读取共享资源，但不允许任何线程修改资源。在数据库系统和并发编程中广泛使用，确保在并发读取场景下数据的一致性。
共享锁就像图书馆里有一套多人阅读的杂志合订本，这套合订本可以被多个读者同时翻阅，但是任何人都不能带走或在上面做标记。当一个读者要阅读时，他会向图书管理员申请“阅读凭证”（相当于共享锁）。如果有多个读者想阅读，图书管理员会给他们每人一份阅读凭证，这样大家都可以坐在阅览室里一起阅读这套合订本，但是都不能单独占有或改变它。在并发编程中，多个线程可以同时获取共享锁进行读取操作，但都不能修改数据，这就像是多个线程同时持有共享锁读取资源，但不允许在此期间进行写操作。
共享锁的实现方式：
实现共享锁的关键机制是读写锁（ReadWriteLock），这是一种特殊类型的共享锁机制，它巧妙地将对共享资源的访问权限划分为了读取权限和写入权限两类。在读写锁的控制下，多个线程可以同时进行对共享数据的读取操作，形成并发读取，而对数据的写入操作则采取独占式处理，确保同一时间段内仅有一个线程执行写入操作。在写入操作正在进行时，无论是其他的读取操作还是写入操作都会被暂时阻塞，直至写操作结束。
读写锁包含两种锁模式：读锁（ReadLock） 和 写锁（WriteLock）。当多个线程需要访问同一份共享数据时，只要这些线程都是进行读取操作，则都能成功获取并持有读锁，从而实现并行读取。然而，一旦有线程尝试进行写入操作，那么不论是其他正在执行读取的线程还是准备进行写入的线程，都无法继续获取读锁或写锁，直至当前写操作全部完成并释放写锁。这样，读写锁有效地平衡了读取密集型任务的并发性和写入操作的原子性要求。
场景示例及其示例代码
场景1：多线程缓存系统
一个股票价格缓存系统，需要支持高频读取，多个线程同时查询股票价格（读操作），低频更新：单个线程定时更新价格（写操作），保证读取时数据不被修改，更新时数据不被读取
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class StockCacheSystem {
// 共享数据存储
private final Map<String, Double> stockPrices = new HashMap<>();
// 读写锁（共享锁+排他锁）
private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
// 读取股票价格（使用共享锁）
// 许多个线程并行执行 当有线程持有读锁时，写锁无法获取
public Double getStockPrice(String stockCode) {
rwLock.readLock().lock(); // 获取读锁
try {
return stockPrices.get(stockCode);
} finally {
rwLock.readLock().unlock(); // 释放读锁
}
}
// 批量更新股票价格（使用排他锁）
// 同一时刻仅一个线程可进入
public void updatePrices(Map<String, Double> updates) {
rwLock.writeLock().lock(); // 获取写锁
try {
stockPrices.putAll(updates);
System.out.println("数据已更新：" + updates);
} finally {
rwLock.writeLock().unlock(); // 释放写锁
}
}
public static void main(String[] args) throws InterruptedException {
StockCacheSystem cache = new StockCacheSystem();
// 初始化测试数据
cache.updatePrices(Map.of("AAPL", 170.2, "GOOGL", 135.7));
// 创建5个读取线程（并发读）
for (int i = 0; i < 5; i++) {
new Thread(() -> {
for (int j = 0; j < 3; j++) {
System.out.println(Thread.currentThread().getName() +
" 查询AAPL价格: " + cache.getStockPrice("AAPL"));
try { Thread.sleep(100); } catch (InterruptedException e) {}
}
}, "Reader-" + i).start();
}
// 创建1个更新线程（独占写）
new Thread(() -> {
try { Thread.sleep(300); } catch (InterruptedException e) {}
cache.updatePrices(Map.of("AAPL", 171.5, "MSFT", 330.0));
}, "Writer").start();
}
}
运行结果：
数据已更新：{GOOGL=135.7, AAPL=170.2}
Reader-0 查询AAPL价格: 170.2
Reader-1 查询AAPL价格: 170.2
Reader-2 查询AAPL价格: 170.2
Reader-3 查询AAPL价格: 170.2
Reader-4 查询AAPL价格: 170.2
Reader-0 查询AAPL价格: 170.2
Reader-1 查询AAPL价格: 170.2
Reader-2 查询AAPL价格: 170.2
Reader-3 查询AAPL价格: 170.2
Reader-4 查询AAPL价格: 170.2
Reader-0 查询AAPL价格: 170.2
Reader-1 查询AAPL价格: 170.2
数据已更新：{MSFT=330.0, AAPL=171.5}
Reader-2 查询AAPL价格: 171.5
Reader-3 查询AAPL价格: 171.5
Reader-4 查询AAPL价格: 171.5
场景2：电商商品库存系统（读多写少）
每秒数千次商品库存查询（读操作）订单支付成功后扣减库存（写操作）库存低于阈值时补货更新（写操作）
import java.util.concurrent.locks.*;
public class ProductInventory {
private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
private final Lock readLock = rwLock.readLock();
private final Lock writeLock = rwLock.writeLock();
private final Map<String, Integer> inventory = new HashMap<>();
// 查询库存（高频读）
public int checkStock(String productId) {
readLock.lock();
try {
return inventory.getOrDefault(productId, 0);
} finally {
readLock.unlock();
}
}
// 扣减库存（写）
public boolean deductStock(String productId, int quantity) {
writeLock.lock();
try {
int current = inventory.getOrDefault(productId, 0);
if(current < quantity) return false;
inventory.put(productId, current - quantity);
logInventoryChange(productId, -quantity);
return true;
} finally {
writeLock.unlock();
}
}
// 补货操作（写）
public void restock(String productId, int amount) {
writeLock.lock();
try {
int current = inventory.getOrDefault(productId, 0);
inventory.put(productId, current + amount);
logInventoryChange(productId, amount);
} finally {
writeLock.unlock();
}
}
private void logInventoryChange(String productId, int delta) {
System.out.printf("[%s] 库存变更: %s %+d → %d%n",
Thread.currentThread().getName(),
productId,
delta,
inventory.get(productId));
}
}
运行结果：
[Reader-3] 查询: P1001 库存=100
[Reader-1] 查询: P1001 库存=100
[Writer-Order] 库存变更: P1001 -5 → 95
[Reader-2] 查询: P1001 库存=95
[Writer-Restock] 库存变更: P1001 +50 → 145
场景3：实时交通路况
数千个导航客户端同时读取路况数据，交通传感器定时更新路段拥堵指数，事故报告实时更新路况
public class TrafficMonitor {
private final ReadWriteLock rwLock = new StampedLock().asReadWriteLock();
private final Map<String, Integer> congestionLevels = new ConcurrentHashMap<>();
// 获取路段拥堵指数（高频读）
public int getCongestionLevel(String roadId) {
rwLock.readLock().lock();
try {
return congestionLevels.getOrDefault(roadId, 0);
} finally {
rwLock.readLock().unlock();
}
}
// 批量更新传感器数据（中频写）
public void updateFromSensors(Map<String, Integer> sensorData) {
rwLock.writeLock().lock();
try {
sensorData.forEach((road, level) -> {
congestionLevels.put(road,
(congestionLevels.getOrDefault(road, 0) * 0.7 + level * 0.3));
});
} finally {
rwLock.writeLock().unlock();
}
}
// 报告交通事故（紧急写）
public void reportAccident(String roadId, int severity) {
rwLock.writeLock().lock();
try {
int current = congestionLevels.getOrDefault(roadId, 0);
congestionLevels.put(roadId, Math.max(current, severity * 30));
triggerEmergencyResponse(roadId);
} finally {
rwLock.writeLock().unlock();
}
}
}
共享锁使用总结：
什么时候使用共享锁？
- 明确锁粒度：
- 全局数据 → 全局读写锁
- 分片数据 → 分片级读写锁（如商品ID哈希分片）
- 单条数据 → 对象级锁
- 读写比例评估：
if (读操作比例 > 80%) {
使用读写锁
} else if (写冲突率 < 20%) {
考虑乐观锁/CAS
} else {
悲观锁+队列
}
- 避免锁嵌套的死亡陷阱：
// 危险代码：读锁内尝试获取写锁
readLock.lock();
try {
if(needUpdate) {
writeLock.lock(); // 永久阻塞！
// ...
}
} finally { readLock.unlock(); }
// 正确做法：释放读锁后再获取写锁
readLock.lock();
boolean needUpdate = checkCondition();
readLock.unlock();
if(needUpdate) {
writeLock.lock();
// ...
}
- 监控锁竞争（关键运维指标）：
ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
// 监控点1：读锁排队长度
int readQueueLength = lock.getReadLockCount();
// 监控点2：写锁等待线程数
int writeWaitCount = lock.getQueueLength();
// 监控点3：锁升级警告
if (lock.getReadHoldCount() > 0 && lock.isWriteLocked()) {
log.warn("锁升级风险!");
}
- 超时控制（避免系统雪崩）：
// 尝试获取写锁，最多等待100ms
if (writeLock.tryLock(100, TimeUnit.MILLISECONDS)) {
try { /* 写操作 */ }
finally { writeLock.unlock(); }
} else {
// 触发降级策略：返回缓存旧值/拒绝请求
return fallbackOperation();
}
什么时候避免使用共享锁？
- 写密集型场景：
- 频繁更新的计数器
- 实时竞价系统
- 替代方案：LongAdder、ConcurrentHashMap
- 强一致性要求：
- 银行账户余额操作
- 库存精确扣减（避免超卖）
- 替代方案：数据库事务锁、分布式锁
- 超高并发场景：
- 秒杀系统核心资源
- 支付网关交易处理
- 替代方案：无锁队列（Disruptor）、Actor模型
共享锁的优缺点：
-
优点：
-
提高并发性：对于读多写少的场景，共享锁可以使多个读取操作并行执行，显著提高系统的并发性能。
-
数据保护：在读取阶段避免了数据被意外修改，确保读取到的是稳定的数据状态。
-
缺点：
-
写操作阻塞：只要有共享锁存在，其他事务就不能对数据加排他锁（Exclusive Lock）进行写操作，这可能导致写操作长时间等待，降低系统的写入性能。
-
可能导致死锁：在复杂的事务交互中，如果没有合适的锁管理策略，共享锁可能会参与到死锁循环中，导致事务无法正常完成。
-
数据一致性问题：虽然共享锁能保护读取过程中数据不被修改，但并不能阻止数据在读取操作之后立即被其他事务修改，对于要求强一致性的应用可能不够。
扫一扫
171
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
