一：介绍
悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。相对悲观锁而言，乐观锁更倾向于开发运用。
1. 乐观锁是一种思想，具体实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，需要再次查看该字段的值是否和第一次的一样。如果一样更新，反之拒绝。之所以叫乐观，因为这个模式没有从数据库加锁。
2. 悲观锁是读取的时候为后面的更新加锁，之后再来的读操作都会等待。这种是数据库锁
二：解决的问题
在多节点部署或者多线程执行时，同一个时间可能有多个线程更新相同数据，产生冲突，这就是并发问题。这样的情况下会出现以下问题：
更新丢失：一个事务更新数据后，被另一个更新数据的事务覆盖。
脏读：一个事务读取另一个事物为提交的数据，即为脏读。
其次还有幻读。。
针对并发引入并发控制机制，即加锁。
加锁的目的是在同一个时间只有一个事务在更新数据，通过锁独占数据的修改权。
三：优缺点
1、悲观锁，前提是，一定会有并发抢占资源，强行独占资源，在整个数据处理过程中，将数据处于锁定状态。
2、乐观锁，前提是，不会发生并发抢占资源，只有在提交操作的时候检查是否违反数据完整性。只能防止脏读后数据的提交，不能解决脏读。
两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
四：使用场景
1.响应速度：如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁
2.冲突频率：如果冲突频率非常高，建议采用悲观锁，保证成功率，如果冲突频率大，乐观锁会需要多次重试才能成功，代价比较大
3.重试代价：如果重试代价大，建议采用悲观锁
参考
https://www.zhihu.com/question/29420056
https://yq.aliyun.com/articles/69708?spm=a2c4e.11153940.blogcont69707.72.1e5447c5h3QZjq
注：如有不妥之处，欢迎指正