为什么第5章并发值得单独学习

区分系统事务与业务事务，以隔离、不变量、锁和冲突恢复保护长会话。第5章并发的核心不是套用某个框架 API，而是回答：如何保护跨多个系统事务的业务事务，在冲突检测、提前锁定和恢复成本间作出选择。在两个客服并行修改订单中，如果无法说清责任、状态和失败由谁承担，即使正常请求能够返回，架构决定也没有完成。

不是把数据库事务时间拉长，而是明确用户会话、系统事务和冲突恢复的边界。本页以 2024 年中文版公开目录限定 第5章 并发 的范围，并依据 Martin Fowler 的作者图书页和模式目录独立重写。它不复现原书正文、插图或代码；目录只决定“要讲什么”，这里的案例、实验、判断题和答案均为本课程原创。

先建立直觉：问题、机制与代价

第5章并发面对的具体压力是“冲突概率、业务事务时长、锁粒度、等待时间与回滚代价”。它采用的机制可以概括为：用版本、锁和业务不变量检测或避免丢失更新。机制带来的收益必须与重试、死锁、用户重新编辑和锁管理成本同时记录，否则学习者只会得到一个没有拒绝条件的模式名称。

对第5章并发，优先比较低冲突场景的版本检查、高冲突场景的悲观锁和高损失场景的粗粒度保护。只有当 不变量、冲突信号和恢复路径清晰时，才选择一种控制策略；如果只是把每次数据库提交成功误认为业务事务安全，就不能据此选择第5章并发。乐观并发控制适合低冲突，悲观锁则要承担等待和死锁代价。

目录单元到教学证据

第5章并发

在 第5章并发 的学习边界里，第5章并发不是待背诵的目录词，而是用来检查业务事务是否把责任交给正确对象。对两个客服并行修改订单，学习者要记录执行语境、版本和恢复路径的可观察变化，并说明它何时支持或否定本章结论。

5.1 并发问题

并发问题首先表现为丢失更新、脏读和不一致决策。先固定两个参与者的读取时间和提交顺序，再定位第一个不变量被破坏的状态，才能判断需要检测、锁定还是改写业务流程。

5.2 执行语境

执行语境区分一次数据库系统事务和用户从打开到提交的业务事务。把请求、会话、事务和重试标在同一条时间线上，才能知道版本检查应该发生在哪里，以及重试是否会重复副作用。

5.3 隔离与不变性

隔离与不变性要求明确哪些读取可以并行、哪些状态必须原子改变。库存不能为负、订单不能重复支付等不变量应由领域规则和提交检查共同保护，而不是寄希望于页面顺序。

5.4 乐观并发控制和悲观并发控制

乐观并发控制在提交时检查版本，冲突后拒绝或重试；悲观并发控制在读取前取得锁，减少冲突却增加等待和死锁风险。选择证据应包括冲突概率、单次损失、用户恢复成本和锁可观测性。

5.5 事务

事务章节要区分数据库原子性、应用服务边界和跨系统补偿。一次提交成功不能证明整个业务事务成功；外部支付、消息发送和数据库写回应有明确的顺序、幂等策略和失败记录。

5.6 离线并发控制的模式

离线并发控制把用户编辑和最终提交分开，要求保存版本、差异和冲突提示。冲突不能静默覆盖，系统应让用户重读、合并或撤销，并保留可审计的恢复路径。

5.7 应用服务器并发

应用服务器并发需要说明请求是否共享内存、会话是否跨节点以及锁存放在哪里。无状态服务仍然需要数据库或分布式协调来保护不变量，不能把进程内互斥当成全局并发策略。

5.8 进一步阅读

进一步阅读应把本章证据卡连接到乐观离线锁、悲观离线锁、粗粒度锁和隐式锁等具体模式。下一步选择由冲突与恢复证据驱动，而不是由框架是否提供注解驱动。

专属设计案例：两个客服并行修改订单

把两个客服并行修改订单切成“业务事务 → 读取版本 → 并发修改 → 冲突检测 → 提交恢复”五个观察点。第5章并发的设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及执行语境、隔离、不变量、乐观悲观、事务中哪个指标最先提示当前方案不再适用。

设计记录采用五个可换行字段：单元键为 poeaa24-chapter-05-concurrency；模式族为 concurrency；裁决是“能解释并发的边界与选择轴，逐项覆盖 8 个目录节点，并在同一应用切片中验证”；观测项包括执行语境、隔离、不变量、乐观悲观、事务；拒绝条件是“没有冲突信号、恢复路径或跨请求事务所有者”。

配置不是生产框架语法，而是一张评审卡。对第5章并发的任何实现都要能把运行证据重新映射到这张卡；如果更换数据库、应用服务器或部署平台后无法回答同一组问题，说明决定依赖的是工具偶然行为而不是并发语义。

并发冲突解剖

两个客服读取同一版本，各自修改不同字段，后保存者的完整快照可能覆盖先保存者的工作。

图中对比提交时版本检查与读取时持有排他锁，帮助学习者把冲突成本、等待成本和恢复动作放到同一条时间线上。

第二张图把冲突概率、单次损失和恢复成本转成策略选择顺序，避免把锁或重试当成无条件的默认答案。

选择与拒绝矩阵

代码实践：版本检查保护订单更新

下面的存储接口用 expectedVersion 拒绝过期写入；调用者可以把冲突显示给客服，而不是静默覆盖。冲突拒绝必须和用户恢复动作一起设计。

type Order = {
  id: string;
  version: number;
  note: string;
  status: "open" | "paid";
};
 
interface OrderStore {
  read(id: string): Order | undefined;
  update(order: Order, expectedVersion: number): "updated" | "conflict";
}
 
function saveNote(
  store: OrderStore,
  id: string,
  expectedVersion: number,
  note: string,
): "saved" | "conflict" | "not-found" {
  const current = store.read(id);
  if (!current) return "not-found";
  const result = store.update(
    { ...current, note, version: expectedVersion + 1 },
    expectedVersion,
  );
  return result === "updated" ? "saved" : "conflict";
}
 
function retryAfterConflict(
  store: OrderStore,
  id: string,
  note: string,
): string {
  const latest = store.read(id);
  if (!latest) return "not-found";
  const result = saveNote(store, id, latest.version, note);
  return result === "saved" ? "saved-after-reread" : result;
}

这段代码把过期写入变成显式结果，调用者可以展示冲突、让客服重读后再提交。真实系统还要防止重试重复发送支付或消息副作用；对于高冲突高损失场景，应另外评估悲观锁、串行队列或粗粒度锁。

常见误区

可验证练习

名词解释

本章小结

掌握第5章并发的标志不是记住定义，而是能在两个客服并行修改订单中解释“业务事务 → 读取版本 → 并发修改 → 冲突检测 → 提交恢复”的责任链，利用执行语境、隔离、不变量、乐观悲观、事务作出可证伪的选择，并在缺少冲突信号或恢复路径时明确拒绝当前实现。

前后导航

• 上一页：第4章 Web表示层
• 下一页：第6章 会话状态

来源与改写范围

• Martin Fowler 作者图书页：核对全书主题、教程与模式参考结构。
• Martin Fowler 模式目录：核对模式名称、所属模式族和作者公开摘要。
• Pearson 出版社页面：交叉核对英文版出版信息与目录范围。