后端开发过程中的乐观锁和悲观锁怎么理解并选型？

笔者在参加某银行软开面试时被问到这个偏实践类的问题，特来学习并总结

开门见山，在选择悲观锁和乐观锁时，需要根据具体的应用场景进行考虑：

• 悲观锁适用于对数据的修改操作频繁，且并发冲突较为频繁的场景。
• 乐观锁适用于对数据的读操作频繁，冲突较少发生的场景

锁的概念

首先了解两种锁的区别是什么

悲观锁 

悲观锁是一种保守的锁策略，它假设在整个数据访问过程中会发生冲突，因此在访问数据之前会先获取锁。悲观锁主要用于对数据的修改操作，它确保在一个事务中只有一个线程能够访问和修改数据，其他线程必须等待锁的释放。悲观锁的特点是阻塞其他线程的访问，从而保证数据的一致性。

乐观锁

乐观锁是一种乐观的锁策略，它假设在整个数据访问过程中不会发生冲突，因此不会立即获取锁。乐观锁主要基于版本号或时间戳来实现，每个数据记录都会有一个版本号或时间戳，当要更新数据时，会比较当前版本号或时间戳与更新前获取的版本号或时间戳是否一致，如果一致则可以更新，否则表示数据已被其他线程修改，需要进行相应的处理（如回滚或重试）。乐观锁的特点是不会阻塞其他线程的访问，通过检测冲突并处理冲突来保证数据的一致性。

参考

对于锁机制的评论以及这两种锁选型在DBMS中的运用，我们可以看一个stackoverflow中的高赞回答

Optimistic Locking is a strategy where you read a record, take note of a version number (other methods to do this involve dates, timestamps or checksums/hashes) and check that the version hasn't changed before you write the record back. When you write the record back you filter the update on the version to make sure it's atomic. (i.e. hasn't been updated between when you check the version and write the record to t