事务序列化中读先于写为何被视为冲突？相关困惑求解

嘿，我懂你这种困惑！咱们先把那三类经典的事务并发问题掰扯清楚，再说说你遇到的「读先于写（R before W）」的情况～

三类经典事务并发问题 #

• 丢失更新（Lost update）：就是两个事务同时修改同一条数据，其中一个把另一个还没提交的写入给覆盖了。比如事务A修改了某条记录但没提交，事务B紧接着也改了这条记录并提交，等事务A再提交时，B的修改直接把A的操作冲没了，相当于A的更新“凭空消失”了。
• 脏读（Dirty read）：指一个事务读取了另一个事务尚未提交的写入内容。比如事务A把用户余额改成100但没提交，事务B这时候查询到余额是100，结果后来事务A回滚了，余额又变回原来的数值，那B刚才读的就是完全无效的“脏数据”。
• 不可重复读（Repeatable read）：同一个事务内，前后两次读取同一条数据的结果不一致。比如事务A第一次读某条记录是50，这时候事务B修改了这条记录并提交，事务A再次读取时就变成了100，这会导致同一个事务内的逻辑出现矛盾。

关于你提到的「读先于写（R before W）」 #

其实这个场景并不是一个独立的事务异常类别，它通常是上述三类问题的具体触发场景。很多并发冲突都是源于“先读取数据，再基于读取的值进行修改”的操作顺序——比如丢失更新的典型场景，就是两个事务都先读了同一份数据，再各自写入修改，最后导致其中一个更新被覆盖。

有些练习里把它单独标注出来，大概率是为了更具象地让你理解并发冲突的触发逻辑。举个实际例子：两个用户同时给同一个账户转账，事务1先读余额为1000，准备转100；事务2也读了余额1000，准备转200。如果没有合适的并发控制，最后账户余额可能变成1100或1200，而不是正确的700，这背后就是“读先于写”的操作顺序引发的丢失更新问题。

内容的提问来源于stack exchange，提问作者Maude