看完这篇文章可以获得什么1.什么是乐观锁？2、乐观锁的实现方式有哪些？3、乐观锁的优缺点是什么？4、乐观锁的适用场景是什么？5.什么是悲观锁？6、悲观锁的实现方式有哪些？7、悲观锁的优缺点是什么？8、悲观锁适用场景有哪些？首先我们来看一下什么是乐观锁。个人理解，乐观锁可以抽象为去银行取钱。如果银行无人，则无需取号，可直接到A柜台办理业务。反之，悲观锁就是你去银行取钱，每次去，A柜台都有人在排队，所以这时候需要取号，然后等取号去柜台A办理业务。（假设银行只有一个柜台A，不是很形象，只是为了说明问题。乐观锁乐观一切，悲观锁悲观。）先看看标准解释是怎么说的，什么是乐观锁？乐观锁乐观锁（OptimisticLocking）与悲观锁相比，乐观锁机制采用了更为宽松的锁机制。大多数情况下，悲观锁是通过数据库的锁机制来实现的，以保证操作的最大程度的排他性。但随之而来的是数据库性能上的大量开销，尤其是对于长事务，这样的开销往往是难以承受的。乐观锁机制在一定程度上解决了这个问题。乐观锁大多是基于数据版本（version）记录机制来实现的。什么是数据版本？也就是给数据加上版本标识。在基于数据库表的版本方案中，一般是通过在数据库表中增加一个版本字段来实现的。读数据的时候一起读这个版本号，更新的时候再给这个版本号加一。此时将提交数据的版本数据与数据库表中相应记录的当前版本信息进行比较。如果提交数据的版本号等于数据库表的当前版本号，则更新，否则认为是过期数据。看完上面这段话，我们应该已经知道了乐观锁的含义，即也就是说，最乐观的加锁其实就是加了版本号version字段。根据这个领域实现的乐观锁机制，那么还有另外一种方法可以实现乐观锁。至于锁，聪明的你一定想到了CAS。是的，CAS（比较和交换）比较和修改。CAS需要三个参数，内存地址V，旧期望值A和新值B。只有当V的值等于A时，V的值才会变为B。那么，在目前乐观锁的实现中，我们知道有版本号机制和CAS机制，那么这两种机制会带来什么问题呢？跟我一起来看看吧。首先，CAS会出现ABA问题。什么是ABA问题？ABA题是张三往桌上放100元，李四中间拿100元。把100块放在桌子上，等张三回来发现还是100块，他就认为这还是他的100块。其实这100块钱已经变了。这是一个经典的ABA问题。这种问题怎么解决，就是我们上面说的版本号机制，加上版本号后（版本号必须按顺序递增），判断版本，版本号相同时才改值,然后是版本号+1;更新值的时候，如果版本号不匹配，就不会再改了，这样就可以避免ABA问题。但是，CAS自旋将始终尝试获取锁。如果不能获取到锁，此时CPU就会爆炸，带来非常大的开销。所以综上所述，乐观锁更适合读多写少的场景，这样就很少发生冲突，降低了加锁的成本；但如果经常发生冲突，应用程序不断尝试加锁，反而会影响系统性能，此时使用悲观锁比较好。什么是悲观锁？其实看了上面的乐观锁，我应该对悲观锁有了一定的概念。错了，悲观锁很悲观。无论您做什么，都假定是冲突场景。就拿我们上面去银行取钱的例子来说。每次去取钱，A柜台一大堆人取钱，排队，轮到我取钱，对应的其他人也要等。对应我们的场景，无论谁获取资源，都必须先获取锁。这就是通俗的悲观锁的概念。我们按照惯例来看一下正统的说法：悲观锁，顾名思义，具有很强的排他性和排他性。指对数据被外界修改（包括系统当前的其他事务，以及来自外部系统的事务处理）的保守态度。因此，在整个数据处理过程中，数据都是被锁定的。悲观锁的实现往往依赖于数据库提供的锁机制（只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则即使在本系统中实现了锁机制，也没有保证外部系统不会修改数据）。那么，如果是这样的话，悲观锁的优缺点是什么？第一个好处是保证了多线程下的顺序读写，防止产生脏数据。缺点是在并发场景下性能下降明显。所以悲观锁对应乐观锁的适用场景是读少写多的场景。这种场景，冲突比较多，悲观锁就很适合。目前我知道的悲观锁实现方式有Lock和Synchronized，后面是MySQL的forupdate语句，MySQL的查询语句，select...forupdate这时候在数据上加了排他锁，排他锁是也是悲观锁。因此，我们对数据的访问都会对数据进行加锁，后续对数据的操作都会排队，直到获得锁。谈到乐观锁和悲观锁，比如java.util.concurrent.Atomic下的原子变量使用的是CAS机制，Elasticsearch使用的是版本乐观锁机制。总结乐观锁是通过Version（递增）版本号机制和CAS机制实现的。悲观锁的实现方式有Synchronized和Lock，数据库有forupdate锁。适用场景乐观锁适合读多写少的场景，悲观锁适合读少写多的场景。本文到此结束。我简单总结一下乐观锁和悲观锁的概念。如果描述有误，欢迎指正，共同进步。原文链接https://mp.weixin.qq.com/s?__...
