当前位置：首页 > news >正文

微服务架构下，同步锁的应用场景有哪些

news 2026/3/30 14:31:31

在微服务架构下，同步锁（Synchronized/Lock）的应用场景发生了根本性的变化。

核心原则是：同步锁只能用于单个 JVM 进程内部（本地锁），无法直接跨越微服务边界。

微服务架构的本质是分布式系统，多个服务实例运行在不同的进程、不同的服务器甚至不同的数据中心。传统的 synchronized 或 ReentrantLock 只能锁住当前进程内的线程，无法阻止其他服务实例的并发访问。

因此，在微服务中讨论“锁”，通常分为两个层面：

进程内锁（本地锁）：依然使用 Java 原生同步锁，但仅限于保护当前实例内部的资源。
分布式锁（Distributed Lock）：当需要跨实例协调时，必须使用基于 Redis、ZooKeeper、数据库等中间件的分布式锁，而非 Java 原生锁。

以下是微服务架构下，Java 原生同步锁的具体应用场景，以及何时不能使用它：

一、适用场景：进程内资源保护 (Local Scope)

只要共享资源的生命周期仅限于当前微服务实例内部，且不涉及跨实例的状态同步，就可以放心使用 synchronized 或 ReentrantLock。

1. 本地缓存更新 (Local Cache)

很多微服务会使用本地缓存（如 Caffeine, Guava Cache, 或简单的 ConcurrentHashMap）来加速读取。

场景：缓存穿透保护（防止大量请求同时去查数据库）、缓存重建（防止多个线程同时回源查询 DB）。

用法：

// 伪代码：双重检查锁定或细粒度锁
public Data getData(String key) {Data data = localCache.get(key);if (data == null) {// 锁定当前实例的特定 Key，防止本实例内重复查库synchronized (key.intern()) { data = localCache.get(key);if (data == null) {data = db.query(key); // 只有本实例的一个线程会执行localCache.put(key, data);}}}return data;
}

注意：这只能防止当前实例重复查库。如果有 10 个服务实例，极端情况下仍可能有 10 个线程同时查库。若需彻底解决，需结合分布式锁。

2. 单例模式与初始化 (Singleton & Initialization)

场景：微服务启动时，某些重量级组件（如本地文件索引器、特定的连接池预加载、定时任务调度器注册）只需要初始化一次。

用法：使用 synchronized 或静态内部类实现线程安全的单例初始化。

// 双重检查锁定 (DCL) - 经典用法
if (instance == null) {synchronized (MyService.class) {if (instance == null) {instance = new MyService();}}
}

3. 内存计数器与统计 (In-Memory Counters)

场景：统计当前实例在内存中的实时指标（如：当前正在处理的请求数、本实例的 QPS 峰值），这些指标不需要全局精确，或者会在稍后异步聚合到监控系统（如 Prometheus）。
用法：
- 低竞争：AtomicLong / LongAdder (推荐，性能更好)。
- 复杂逻辑：ReentrantLock 保护一段包含多个变量更新的代码块。
- 注意：如果是全局配额限制（如“全系统每天只能发 1000 条短信”），绝对不能用本地锁，必须用分布式锁或 Redis 原子计数。

4. 避免本实例内的重复提交 (Duplicate Submission Prevention)

场景：用户快速点击按钮，网关层限流失效后，进入服务层。如果业务允许在极短时间窗口内（毫秒级）由同一个实例处理去重。

用法：使用 ConcurrentHashMap<String, Boolean> 配合 synchronized 或 computeIfAbsent 原子操作。

// 利用 ConcurrentHashMap 的原子性，通常不需要显式锁
processingSet.computeIfAbsent(orderId, k -> {try {return processOrder(orderId);} finally {processingSet.remove(orderId);}
});

如果逻辑复杂，可在 compute 内部加锁，但仅限于防止本实例并发。

5. 虚拟线程环境下的细粒度同步 (Java 21+)

场景：在使用虚拟线程（Virtual Threads）的高并发服务中，对于极短时间的内存状态修改。
用法：虽然虚拟线程不推荐长时间持有锁（会导致 Pinning），但对于纳秒/微秒级的内存变量更新，synchronized 依然是高效且安全的选择。JVM 会优化这种短时锁持有没有 Pinning 问题（或影响极小）。

二、禁用场景：跨实例资源共享 (Global Scope)

以下场景严禁仅使用 Java 原生同步锁，必须引入分布式锁（Redisson, ZooKeeper, Etcd 等）：

场景	为什么本地锁无效	正确方案
库存扣减	服务有 5 个实例，每个实例本地锁只能防住自己，5 个实例并发会导致超卖。	Redis Lua 脚本 / Redisson 分布式锁 / 数据库乐观锁
全局唯一 ID 生成	每个实例生成的 ID 可能冲突。	雪花算法 (Snowflake) / 号段模式 / Redis 原子递增
分布式定时任务	`@Scheduled` 在每个实例都会触发，导致任务重复执行。	XXL-JOB / Elastic-Job / 基于 DB/Redis 的选主机制
幂等性控制	请求被负载均衡分发到不同实例，本地记录无法拦截其他实例的请求。	Redis Token 机制 / 数据库唯一索引
全局配置热更新	一个实例更新了内存配置，其他实例不知情。	配置中心 (Nacos/Apollo) 推送 + 本地锁保护应用过程
秒杀/抢购	高并发下，本地锁完全无法应对跨节点的流量洪峰。	Redis 预扣减 + 消息队列削峰 + 数据库最终一致性

三、微服务架构下的锁选型策略

在微服务开发中，决策流程如下：

资源作用域是什么？
- 仅当前 JVM 内存 $\rightarrow$ 使用 Java 原生锁 (synchronized, ReentrantLock, Atomic).
- 跨 JVM / 跨节点 / 数据库 / 外部系统 $\rightarrow$ 使用 分布式锁.
性能要求如何？
- 极高并发读，少量写 $\rightarrow$ 考虑 StampedLock (本地) 或 Redis 读写锁 (分布式).
- 简单互斥 $\rightarrow> synchronized (本地) 或 Redisson (RLock) (分布式).
是否使用了虚拟线程 (Java 21+)?
- 如果是，尽量避免在虚拟线程中使用 synchronized 包裹 I/O 操作或长耗时逻辑，以防 Pinning（载体线程阻塞）。
- 对于纯内存计算，原生锁依然可用。
- 对于分布式场景，推荐使用支持虚拟线程友好的异步客户端（如 Lettuce, Vert.x）配合异步锁逻辑。

四、代码示例对比

❌ 错误示范：试图用本地锁解决分布式问题

// 微服务实例 A 和 B 同时运行此代码
public void deductStock(String productId) {// 错误！这只锁住了实例 A 的线程，实例 B 完全可以同时进入synchronized (productId.intern()) { if (stock > 0) {stock--; // 可能导致超卖}}
}

✅ 正确示范：使用分布式锁 (以 Redisson 为例)

@Autowired
private RedissonClient redissonClient;public void deductStock(String productId) {RLock lock = redissonClient.getLock("stock_lock:" + productId);// 尝试获取锁，等待 5 秒，锁定 10 秒自动释放（防死锁）boolean isLocked = lock.tryLock(5, 10, TimeUnit.SECONDS);if (isLocked) {try {// 此时无论请求打到哪个实例，都互斥int currentStock = getStockFromDB(productId);if (currentStock > 0) {updateStock(productId, currentStock - 1);}} finally {lock.unlock();}} else {// 获取锁失败，说明正在处理，可返回“排队中”或直接失败throw new BusinessException("System busy, please try later");}
}