乐观锁和悲观锁

概述

悲观锁 坏事一定会发生，所以先做预防（上锁） 写多读少
乐观锁：坏事不一定会发生，所以事后补偿 写少读多
悲观锁 select for update，sychronized等，乐观锁，乐观锁如cas和版本号
但是，如果使用悲观锁来实现的话，就会导致很多请求被迫阻塞并且排队，那么如果并发请求量很大的话，就可能直接把数据库给拖垮了。
如果是乐观锁的话，可以用版本号的方式来控制有序行，但是这个问题在于高并发场景中会存在大量的失败，而
且高并发场景中也不适合使用乐观锁，因为乐观锁在update的过程中也是需要加行级锁的，也是会出现阻塞的情
况。
悲观锁(Pessimistic Lock),每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

乐观锁

乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。java 中的乐观锁基本都是通过 CAS 操作实现的，CAS 是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。
乐观锁比较乐观，通过预值或者版本号比较，如果不一致性的情况则通过循环控制修改，当 前线程不会被阻塞，是乐观，效率比较高，但是乐观锁比较消耗 cpu的资源。
乐观锁：获取锁----如果没有获取到锁，当前线程是不会阻塞等待 通过死循环控制。 乐观锁属于无锁机制，没有竞争锁流程。

乐观锁的实现方式：
乐观锁一般会使用版本号机制或 CAS 算法
1、使用版本标识来确定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。
2、CAS 算法
java 中的 Compare and Swap 即 CAS ，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。 CAS 操作中包含三个操作数 —— 需要读写的内存位置（V）、进行比较的预期原值 （A）和拟写入的新值(B)。如果内存位置 V 的值与预期原值 A 相匹配，那么 处理器会自动将该位置值更新为新值 B。否则处理器不做任何操作。
其实都是提供的乐观锁。在 Java 中 java.util.concurrent.atomic 包下面的原子变量类就是使用 了乐观锁的一种实现方式 CAS 实现的。
CAS 缺点：
1、ABA 问题
比如说一个线程 one 从内存位置 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且 two 进行了一些操作变成了 B，然后 two 又将 V 位置的数 据变成 A，这时候线程 one 进行 CAS 操作发现内存中仍然是 A，然后 one 操作成功。尽管线程 one 的 CAS 操作成功，但可能存在潜藏的问题。从 Java1.5 开始 JDK 的 atomic 包里提供了一个类 AtomicStampedReference 来 解决 ABA 问题。
2、循环时间长开销大：对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较大，从而
浪费更多的 CPU 资源，效率低于 synchronized。
3、只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时 候就可以用锁。

java如何使用乐观锁（版本号列）

一般用乐观锁代替分布式锁，实际项目中分布式锁性能差
1.在数据表中增加版本号列，例如：
ALTER TABLE table_name ADD COLUMN version INT DEFAULT 0;
2.在修改数据时增加版本号验证，例如：
UPDATE table_name SET column1=value1, version=version+1 WHERE id=some_id AND version=old_version;
在这个例子中，column1是要修改的列，value1是新值，id是主键字段，some_id是记录的ID，version是版本号，old_version是旧版本号。通过WHERE语句的条件限制，乐观锁保证了同时只有一个修改操作可以成功，其余操作都会因版本号匹配失败而无法更新。
需要注意的是，如果有多个并发事务同时尝试修改同一条记录，只有其中一个事务能够成功，其余事务会收到更新失败的错误提示。在这种情况下，需要使用异常处理进行处理，例如在应用层或存储层中进行重试或回滚操作。
乐观锁机制是一种有效地并发控制机制，它能够在保证数据一致性的同时，最大限度地提高系统的并发能力。

悲观锁：

还是像它的名字一样，对于并发间操作产生的线程安全问题持悲观状态，悲观锁认为竞争总是会发生，因此每次对某资源进行操作时，都会持有一个独占的锁，就像 synchronized，不管三七二十一，直接上了锁就操作资源了，悲观锁是就是悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会 block 直到拿到锁。java中的悲观锁就是Synchronized,AQS框架下的锁则是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁，如 RetreenLock。
SQL 语句 select …for update就悲观一种实现
还有 Java synchronized 关键字也悲观锁一种体现
1.站在 mysql 的角度分析：悲观锁就是比较悲观，当多个线程对同一行数据实现修改的时候， 最后只有一个线程才能修改成功，只要谁能够对获取到行锁则其他线程时不能够对该数据做 任何修改操作，且是阻塞状态。
2.站在 java 锁层面，如果没有获取到锁，则会阻塞等待，后期唤醒的锁的成本就会非常高， 从新被我们 cpu 从就绪调度为运行状态。 Lock syn 锁悲观锁没有获取到锁的线程会阻塞等待；

共享锁和排它锁是悲观锁的不同的实现
悲观锁就是在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作，这点跟java中的synchronized很相似，所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。
说到这里，由悲观锁涉及到的另外两个锁概念就出来了，它们就是共享锁与排它锁。共享锁和排它锁是悲观锁的不同的实现，它俩都属于悲观锁的范畴。

排它锁

要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
我们可以使用命令设置MySQL为非autocommit模式：
set autocommit=0; # 设置完autocommit后，我们就可以执行我们的正常业务了。具体如下： # 1. 开始事务 begin;/begin work;/start transaction; (三者选一就可以) # 2. 查询表信息 select status from TABLE where id=1 for update; # 3. 插入一条数据 insert into TABLE (id,value) values (2,2); # 4. 修改数据为 update TABLE set value=2 where id=1; # 5. 提交事务 commit;/commit work;

共享锁–读锁

共享锁又称读锁 read lock，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获得共享锁的事务只能读数据，不能修改数据
打开第一个查询窗口
begin;/begin work;/start transaction; (三者选一就可以) SELECT * from TABLE where id = 1 lock in share mode;
然后在另一个查询窗口中，对id为1的数据进行更新
update TABLE set name=“www.souyunku.com” where id =1;
此时，操作界面进入了卡顿状态，过了超时间，提示错误信息
如果在超时前，执行 commit，此更新语句就会成功。