乐观锁、悲观锁并不像行级锁、共享锁等概念一样是真实存在的锁。其实他们只是人们定义出来的概念，可以认为是一种思想。
悲观锁和乐观锁
悲观锁，正如其名，它指的是对数据被外界修改持悲观态度，因此，在整个数据处理过程中，需要先将数据进行锁定，获得锁之后再进行操作。
在MySQL中，可以使用排他锁来实现悲观锁，主要就是用到select ... for update语法。
要使用悲观锁，需要关闭mysql数据库的自动提交属性：set autocommit=0;
然后在事务中，通过如下语句对数据进行加锁：
select status from t_goods where id=1 for update以上，在对id = 1的记录修改前，先通过for update的方式进行加锁，然后再进行修改。这就是比较典型的悲观锁策略。
如果以上修改库存的代码发生并发，同一时间只有一个线程可以开启事务并获得id=1的锁，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。
相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
乐观锁的实现并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本，如以下SQL:
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version}
二者区别
（1）悲观锁是在事务刚开始的时候就加锁，在拿到锁之后再去进行业务操作。而乐观锁是在更新的那一刻才会进行并发控制，所以是先进行的业务操作。
其次，悲观锁主要是借助数据库的排他锁实现的，而排他锁本质上是一种阻塞锁。 如果并发量比较大并且冲突比较多的时候，会导致很多线程被锁阻塞，导致请求的RT被拉长，并且会占用大量的数据库链接。
（2）乐观锁不会造成阻塞，但是他带来的问题就是如果并发的冲突比较高的话，那么就会有很多失败的情况，需要业务代码做好这种失败的特殊处理。
（3）0乐观锁虽然叫锁，但是他并没有额外加锁，它是通过CAS来实现的，所以他的效率比较高，而悲观锁需要利用数据库的锁机制进行加锁，这会带来一定的额外消耗。
（4）悲观锁因为做了加锁的动作，所以是会导致死锁的。
高并发不要使用悲观锁
强烈建议大家，优先使用乐观锁，尤其是并发比较高，并且冲突也比较多的场景。
因为我们前面提到过，悲观锁会有额外的消耗、并且可能会带来死锁。但是这些都不是最重要的。
最重要的是，悲观锁本质上是一种阻塞锁，在并发比较高的情况下，会有很多个线程都被阻塞，而这些阻塞的线程是会占用数据库链接的。所以这时候就会导致你的系统的并发度很低，还有就是这些阻塞的线程的响应时长也会被拉的很长，极度影响用户体验，也会多出来很多慢SQL。
额外提一句，在MySQL 8.0中，已经支持了select ... for update nowait，可以把阻塞锁变成非阻塞的。可以在某种程度上解决悲观锁的阻塞带来的一些问题，但是加锁的额外开销和死锁的问题也还是有的。
所以，高并发场景中，建议大家使用乐观锁，尤其是MySQL 5.x 的版本中，因为不支持nowait，一旦使用悲观锁，会大大降低你的系统的并发度。