并发的两个本质问题：更新丢失与不一致读

并发控制真正要防范的本质问题主要有两类。更新丢失最容易理解：David和Martin同时编辑同一份文件的不同部分，David先开始却先完成、Martin后完成，Martin提交时读的是David修改前的旧版本，写回时就把David的修改整个覆盖掉，David的更新凭空消失了——这类问题的根源是”读的时候没看到别人已经写进去的东西，写的时候又把这个没看到的更新覆盖了”。不一致读则更容易被忽略：Martin先查了A包有7个类，中途接了个电话，这期间David往A包加了2个类、往B包加了3个类（原本5个类），Martin挂电话后接着查B包看到8个类，两个数字相加得到15——但15永远不是正确答案，正确答案只能是David修改前的12（两次查询都发生在修改前）或修改后的17（两次查询都发生在修改后），因为Martin读到的是两个分别正确但互相矛盾的时间切片拼出来的结果。这两类问题都属于正确性（安全性）层面的失败：只要保证同一时刻只有一人能操作数据，两者都不会发生，但这样做会严重削弱并发的灵活性——因此并发设计从来不是单纯追求正确性，而是要在正确性与灵活性之间根据失败的严重性和实际并发需求做权衡。

结构图：

flowchart TB
  A["并发本质问题"]
  A --> B["更新丢失<br/>后完成的写覆盖了先完成的写"]
  A --> C["不一致读<br/>读到的是跨越不同时间点的数据拼凑结果"]
  B --> D["根源:写之前没重新读最新状态"]
  C --> E["根源:两次读之间数据被改动，结果既非改前也非改后"]