本文详解在多线程调用并行 rest 请求后、并发写入同一数据库表场景下，如何通过协同调度与数据库级并发控制（如乐观锁）避免线程干扰和数据覆盖。
本文详解在多线程调用并行 rest 请求后、并发写入同一数据库表场景下，如何通过协同调度与数据库级并发控制（如乐观锁）避免线程干扰和数据覆盖。
在典型的微服务集成场景中，一个 Java 业务类常需串行调用多个外部 REST 接口（如用户服务、订单服务），再将各自返回的数据持久化到本地数据库。当为提升响应性能而改用多线程并行发起这些远程调用时，若多个线程最终都更新同一张表（例如 user_profile 或 order_summary），极易因缺乏同步机制导致丢失更新（Lost Update）——即后提交的事务覆盖先提交但尚未刷新的变更。
解决该问题的核心思路是：分离“读”与“写”，并在“写”阶段引入强一致性保障。不推荐对整个方法加 synchronized 或全局锁（严重损害吞吐），而应采用分层策略：
✅ 第一层：协调执行时序 —— 使用 invokeAll 统一收集结果
确保所有 REST 调用完成后再进入数据库写阶段，避免部分线程尚未获取数据就抢先更新。推荐使用 ExecutorService.invokeAll() 阻塞等待全部异步任务完成：
ExecutorService executor = Executors.newFixedThreadPool(2);
List<Callable<ApiResponse>> tasks = Arrays.asList(
() -> callUserService(), // 方法1：调用用户服务
() -> callOrderService() // 方法2：调用订单服务
);
try {
List<Future<ApiResponse>> futures = executor.invokeAll(tasks);
List<ApiResponse> results = futures.stream()
.map(future -> {
try { return future.get(); }
catch (Exception e) { throw new RuntimeException(e); }
})
.collect(Collectors.toList());
// ✅ 此时 results 已完备，可安全进入统一写库阶段
updateSharedTables(results.get(0), results.get(1));
} finally {
executor.shutdown();
}⚠️ 注意：invokeAll 会阻塞直到所有任务完成（或超时），它本身不解决写冲突，但为后续原子化写操作提供了前提条件。
立即学习“Java免费学习笔记（深入）”；
✅ 第二层：保障写操作原子性 —— 数据库乐观锁（Optimistic Locking）
当多个线程几乎同时执行 UPDATE 语句修改同一行时，依赖数据库 ACID 特性实现无锁并发控制。关键是在目标表中添加 version 字段，并在更新 SQL 中校验版本号：
-- 假设当前记录 version = 1 UPDATE user_profile SET email = 'new@ex.com', last_updated = NOW(), version = 2 WHERE id = 1001 AND version = 1;
- 若执行成功（affectedRows == 1），说明该记录未被其他事务修改；
- 若失败（affectedRows == 0），则抛出 OptimisticLockException，业务层应捕获并重试（如重新查询最新数据 + 重新计算 + 再次提交）。
在 JPA/Hibernate 中，只需在实体类中标注 @Version：
@Entity
public class UserProfile {
@Id private Long id;
private String email;
@Version private Integer version; // 自动管理，无需手动赋值
// ...
}Hibernate 会在每次 UPDATE 自动生成 WHERE ... AND version = ? 条件，并在检测到版本不匹配时抛出异常。
✅ 补充建议：更健壮的实践组合
- 结合数据库唯一约束：对业务上不可重复的关键字段（如 order_id + status 组合）设置唯一索引，利用 DB 层报错兜底；
- 使用 SELECT FOR UPDATE（悲观锁）仅限低频高冲突场景：适用于更新前必须强一致读取且事务极短的情况，但会降低并发度；
- 避免跨事务共享可变对象：REST 返回的数据 DTO 应为不可变结构（如 record 或 final 字段），防止线程间意外修改引用；
- 监控与告警：统计乐观锁冲突率（如每千次更新失败次数），持续高于 5% 时需评估是否模型设计存在热点行，考虑分表或缓存预热优化。
综上，高效规避多线程数据库更新干扰，不是靠单一锁机制，而是「逻辑编排 + 数据库原生并发控制」的协同设计：用 invokeAll 实现读写解耦，用乐观锁将并发冲突检测下沉至数据库引擎，既保证数据一致性，又最大限度保留系统吞吐能力。
