持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第22天，点击查看活动详情
🍊作者简介：少年不想说话，努力长大
🍊往期回顾：从零开始Redis（十一）
🍊近期目标：写完基础源码，点赞👍🏼、收藏⭐、留言📩
接着上文，昨天我们说了事务，那必然要来说说锁了，所以今天我们来说说乐观锁和悲观锁；
乐观锁与悲观锁
先来理解下什么是乐观锁、悲观锁 首先悲观锁的意思就是以悲观的态度去处理数据，他总是认为数据拿到时会被别人修改，所以每次拿数据时都会对其上锁，直到处理完毕才会释放锁，通常我们对数据库的操作就是通过数据库本身的悲观锁机制来实现的； 我们代码里面的synchronized关键字就是一个悲观锁，虽然现在它的锁是逐步升级的；synchronized锁有四种状态：无锁，偏向锁、轻量级锁和重量级锁，所以该锁适合读少写多的情况；
再看下乐观锁，它是乐观的态度去处理数据，他认为数据拿到后该数据不会被别人修改，每次去取数据的时候并不会对数据上锁，只不过在我们对数据 更新的时候会去判断该数据有没有被修改，至于如何判断通常我们会通过一个版本号来操作；或者通过CAS来进行操作，所以该锁适合读多写少的情况；
再看下悲观锁又可分为共享锁和排它锁；
共享锁（shared locks）又称为读锁、S锁。共享锁就是对于多个事务请求它都能访问到对应数据，但是该数据只能读不能修改。
排他锁（exclusive locks）又称为写锁、X锁。排他锁就是如果一个事务请求获取了一个数据，其他事务请求就不能再获取该数据。
这个不好写验证方法，就记忆理解吧，可以去翻翻源码，就看synchronized关键字就行了，从乐观到悲观看完源码就差不多了；
最后总结下，通常我们对于可能并发的数据库数据的修改，往往我们会给该表加上个version列，然后通过version来判断是否可以修改；这是最常见的方法，也是我一直用的方法，不管我们用什么锁，一定要控制锁的粒度，如果范围过大，会严重影响代码的运行效率 ，所以加锁需慎重；好啦🥗🥗🥗；
结束结束，那就🛴🛴🛴
如果对你有所帮助
点个赞呗
