我注意到我的应用程序经常将值写入依赖于以前的读取操作的数据库。一个常见的例子是用户可以存钱的银行账户：

void deposit(amount) {
    balance = getAccountBalance()
    setAccountBalance(balance + amount)
}

我想避免竞争条件，如果这个方法被两个线程/客户端/ATM同时调用，就像这样，账户所有者会赔钱：

balance = getAccountBalance()       |
                                    | balance = getAccountBalance()
setAccountBalance(balance + amount) |
                                    | // balance2 = getAccountBalance() // theoretical
                                    | setAccountBalance(balance + amount)
                                    V

我经常读到可重复读取或可序列化可以解决这个问题。甚至德文维基百科的丢失更新文章也这样说。翻译成英文：

隔离级别RR（可重复读取）经常被认为是丢失更新问题的解决方案。

这个SO的答案建议在SELECT之后对INSERT的类似问题进行序列化。

据我所知——当右侧的进程试图设置账户余额时，（理论上的）读取操作将不再返回相同的余额。因此不允许写操作。是的——如果你读到这个流行的SO答案，它实际上听起来非常合适：

在REPEATABLE READ下，第二个SELECT保证至少显示从第一个SELECT返回的未更改的行。在这一分钟内，可以通过并发事务添加新行，但不能删除或更改现有行。

但后来我想知道“它们不能被删除或更改”实际上意味着什么。如果你无论如何都试图删除/更改它会发生什么？你会得到一个错误吗？或者你的交易会等到第一笔交易完成，最后也执行它的更新吗？这一切都不同了。在第二种情况下，你仍然会赔钱。

如果你阅读下面的注释，情况会变得更糟，因为还有其他方法可以满足可重复读取条件。例如快照技术：可以在左侧事务写入其值之前拍摄快照，这允许在右侧事务稍后发生第二次读取时提供原始值。例如，请参阅MySQL手册：

同一事务内的一致性读取读取第一次读取建立的快照

我得出的结论是，限制事务隔离级别可能是摆脱竞争条件的错误工具。如果它解决了问题（对于特定的DBMS），这不是由于可重复读取的定义。而是因为满足可重复读取条件的特定实现。例如锁的使用。

所以，对我来说，它看起来像这样：您实际需要解决这个问题的是一种锁定机制。一些DBMS使用锁来实现可重复读取的事实被利用了。

这个假设正确吗？还是我对事务隔离级别的理解有误？

你可能会生气，因为这一定是关于这个话题的第一百万个问题。问题是：示例银行账户场景绝对至关重要。就在那里，应该绝对清楚发生了什么，在我看来，似乎有太多误导和矛盾的信息和误解。