本文导读：

1. 举例说明加锁的场景：

多线程并发情况下有资源竞争的时候，如果不加锁，会出现数据错误，举例说明：

业务需求：账户余额>取款金额，才能取钱。 

时间线	两人共有账户	Alice取钱	Bob取钱
00:01	余额50
00:02	余额50	查询账户余额50
00:03	余额50	线程中断(cpu暂停执行)	查询账户余额50
00:04	余额20	线程中断(cpu暂停执行)	取30， 50>30, 可以取，执行sql: amount=amount-30
00:05	余额成了-20	取40， 刚才查询的余额为50，所以可以正常取,执行sql:amount=amount-40

这个例子中， 减余额是用sql减的(实际上是数据库服务器执行的减操作)，数据库对某一条记录写操作的时候，都会加行锁，防止并发，所以执行sql update实际上是串行的，所以最终金额是-20，数据是对的， 就是不满足业务逻辑：账号余额小于取款金额不能取钱。

这个例子稍作调整，减金额，直接在自己的业务代码里先计算好，然后amount作为参数如传到sql里面直接update，那么最终金额就变成了 10 ,alice 的update会覆盖Bob的update,产生更严重的错误。

这个例子是以数据库为基础的，这样更直观，我们自己的代码也一样，自己设置的全局变量能被多个线程并发访问的时候，也需要做类似的考虑，但一般业务系统都会部署多个实例，所以业务系统中最常用的就是利用其他中间件实现的全局锁。

2. 加锁的两种方式：

悲观锁：提前阻止冲突，就是提前上锁(排他锁、写锁)，上锁后独自一个你操作，操作完了其他人再操作，这样就避免并发数据错误。加锁开销高，代价大，适和并发冲突占比高的情况。

乐观锁：容许冲突，先不加锁，真正操作的时候能够检测到冲突，如果检测到了并发冲突，那么就回退重试，检测冲突一般通过版本号实现。适合并发冲突少的情况，只有少量的请求需要回退重试，那么性能就高。

When dealing with conflicts, you have two options:

• You can try to avoid the conflict, and that's what Pessimistic Locking does.
• Or, you could allow the conflict to occur, but you need to detect it upon committing your transactions, and that's what Optimistic Locking does.

Now, let's consider the following Lost Update anomaly:

The Lost Update anomaly can happen in the Read Committed isolation level.

In the diagram above we can see that Alice believes she can withdraw 40 from her account but does not realize that Bob has just changed the account balance, and now there are only 20 left in this account.

Pessimistic Locking

Pessimistic locking achieves this goal by taking a shared or read lock on the account so Bob is prevented from changing the account.

In the diagram above, both Alice and Bob will acquire a read lock on the account table row that both users have read. The database acquires these locks on SQL Server when using Repeatable Read or Serializable.

Because both Alice and Bob have read the account with the PK value of 1, neither of them can change it until one user releases the read lock. This is because a write operation requires a write/exclusive lock acquisition, and shared/read locks prevent write/exclusive locks.

Only after Alice has committed her transaction and the read lock was released on the account row, Bob UPDATE will resume and apply the change. Until Alice releases the read lock, Bob's UPDATE blocks.

Optimistic Locking

Optimistic Locking allows the conflict to occur but detects it upon applying Alice's UPDATE as the version has changed.

This time, we have an additional version column. The version column is incremented every time an UPDATE or DELETE is executed, and it is also used in the WHERE clause of the UPDATE and DELETE statements. For this to work, we need to issue the SELECT and read the current version prior to executing the UPDATE or DELETE, as otherwise, we would not know what version value to pass to the WHERE clause or to increment.

Application-level transactions

Relational database systems have emerged in the late 70's early 80's when a client would, typically, connect to a mainframe via a terminal. That's why we still see database systems define terms such as SESSION setting.

Nowadays, over the Internet, we no longer execute reads and writes in the context of the same database transaction, and ACID is no longer sufficient.

For instance, consider the following use case:

Without optimistic locking, there is no way this Lost Update would have been caught even if the database transactions used Serializable. This is because reads and writes are executed in separate HTTP requests, hence on different database transactions.

So, optimistic locking can help you prevent Lost Updates even when using application-level transactions that incorporate the user-think time as well.

Conclusion

Optimistic locking is a very useful technique, and it works just fine even when using less-strict isolation levels, like Read Committed, or when reads and writes are executed in subsequent database transactions.

The downside of optimistic locking is that a rollback will be triggered by the data access framework upon catching an OptimisticLockException, therefore losing all the work we've done previously by the currently executing transaction.

The more contention, the more conflicts, and the greater the chance of aborting transactions. Rollbacks can be costly for the database system as it needs to revert all current pending changes which might involve both table rows and index records.

For this reason, pessimistic locking might be more suitable when conflicts happen frequently, as it reduces the chance of rolling back transactions.