数据库锁分类总结汇总，包含乐观锁、悲观锁、行锁、表锁、共享锁、排它锁、更新锁、活锁、死锁

并发控制技术是实现事务隔离性以及不同隔离级别的关键,实现方式有很多,锁是常见的一种。

基于锁的并发控制流程：

1. 事务根据自己对数据项进行的操作类型申请相应的锁(读申请共享锁,写申请排他锁)
2. 申请锁的请求被发送给锁管理器。锁管理器根据当前数据项是否已经有锁以及申请的和持有的锁是否存在冲突，决定是否为该请求授予锁。
3. 若锁被授予,则申请锁的事务可以继续执行;若被拒绝,则申请锁的事务将进行等待,直到锁被其他事务释放。

---

可能出现的问题:

1. 死锁:多个事务持有锁并互相循环等待其他事务的锁导致所有事务都无法继续执行。

2. 饥饿:数据项A一直被加共享锁,导致事务一直无法获取A的排他锁。

对于可能发生冲突的并发操作,锁使它们由并行变为串行执行,是一种悲观的并发控制。

---

按照其对可能冲突的操作采取的不同策略，分为乐观锁和悲观锁。

• 乐观锁和悲观锁是一种思想，具体实现方式需要具体的锁或者机制

按照锁的作用范围，分为行锁和表锁。

按照锁的用途或者数据库系统角度，分为共享锁和排它锁。

并发控制会造成两种锁：活锁和死锁

---

悲观锁（适用多写场景）

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
悲观锁机制存在以下问题：

1. 在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
2. 一个线程持有锁会导致其它所有需要此锁的线程挂起。
3. 如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

对比于悲观锁的这些问题，另一个更加有效的锁就是乐观锁。其实乐观锁就是：每次不加锁而是假设没有并发冲突而去完成某项操作，如果因为并发冲突失败就重试，直到成功为止。

乐观锁（适用多读场景）

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
常见乐观锁实现方式：

1. 版本号机制

一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

2. CAS算法

即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数

1. 需要读写的内存值 V
2. 进行比较的值 A
3. 拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

注意：乐观锁只能用于本系统控制，无法阻止外系统更新

两种锁的使用场景

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

---

表锁：锁的作用范围是整张表。开销小，加锁快；不会出现死锁，发生锁冲突几率高，并发低。

数据库能够确定那些行需要锁的情况下使用行锁，如果不知道会影响哪些行的时候就会使用表锁。

行锁：开销大，加锁慢；锁的作用范围是行级别。会出现死锁，发生锁冲突几率低，并发高。

mysql中行锁有以下特点：
1.行锁必须有索引才能实现，否则会自动锁全表，那么就不是行锁了。
2.两个事务不能锁同一个索引
3.insert ，delete ， update在事务中都会自动默认加上排它锁。

注意：不同的数据库引擎，对于读操作是否加S锁，可能是不一样的。

例如，对于 UPDATE、 DELETE 和 INSERT 语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通 SELECT 语句，InnoDB不会加任何锁。
当MyISAM在执行查询语句时，会自动给涉及到表加读锁，在执行更新操作时，会加写锁。

---

共享锁（Share Lock）

事务T对数据A加共享锁,其他事务只能对A加共享锁但不能加排他锁
S锁，也叫读锁，用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。
性质

1. 多个事务可封锁同一个共享页；
2. 任何事务都不能修改该页；
3. 通常是该页被读取完毕，S锁立即被释放。

排他锁（Exclusive Lock）

事务T对数据A加排他锁,其他事务对A既不能加共享锁也不能加排他锁
X锁，也叫写锁，表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了。（某个顾客把试衣间从里面反锁了，其他顾客想要使用这个试衣间，就只有等待锁从里面打开了。）
性质

1. 仅允许一个事务封锁此页；
2. 其他任何事务必须等到X锁被释放才能对该页进行访问；
3. X锁一直到事务结束才能被释放。

更新锁

U锁，在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。
性质

1. 用来预定要对此页施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；
2. 当被读取的页要被更新时，则升级为X锁；
3. U锁一直到事务结束时才能被释放。

因为当使用共享锁时，修改数据的操作分为两步：

1. 首先获得一个共享锁，读取数据，
2. 然后将共享锁升级为排他锁，再执行修改操作。
   这样如果有两个或多个事务同时对一个事务申请了共享锁，在修改数据时，这些事务都要将共享锁升级为排他锁。这时，这些事务都不会释放共享锁，而是一直等待对方释放，这样就造成了死锁。
   如果一个数据在修改前直接申请更新锁，在数据修改时再升级为排他锁，就可以避免死锁。

三者总结如下：

是否允许同时存在	S	U	X
S	Y	N	N
U	N	N	N
X	N	N	N

---

并发控制会造成两种锁：活锁和死锁

活锁

定义：指的是T1封锁了数据R，T2同时也请求封锁数据R，T3也请求封锁数据R，当T1释放了锁之后，T3会锁住R，T4也请求封锁R，则T2就会一直等待下去。
解决方法：采用“先来先服务”策略可以避免。

死锁

定义：就是我等你，你又等我，双方就会一直等待下去。比如：T1封锁了数据R1，正请求对R2封锁，而T2封住了R2,正请求封锁R1，这样就会导致死锁，死锁这种没有完全解决的方法，只能尽量预防。
预防方法：

1. 一次封锁法，指的是一次性把所需要的数据全部封锁住，但是这样会扩大了封锁的范围，降低系统的并发度；
2. 顺序封锁法，指的是事先对数据对象指定一个封锁顺序，要对数据进行封锁，只能按照规定的顺序来封锁，但是这个一般不大可能的。
3. 如果不同的程序会并发的存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。

系统判定死锁的方法：

1. 超时法：如果某个事物的等待时间超过指定时限，则判定为出现死锁；
2. 等待图法：如果事务等待图中出现了回路，则判断出现了死锁。
   对于解决死锁的方法，只能是撤销一个处理死锁代价最小的事务，释放此事务持有的所有锁，同时对撤销的事务所执行的数据修改操作必须加以恢复。

---

参考文章：

数据库事务的概念及其实现原理
https://www.cnblogs.com/takumicx/p/9998844.html

数据库锁分类和总结
https://blog.csdn.net/weixin_39651041/article/details/79985715

行锁与表锁详解
https://blog.csdn.net/nicajonh/article/details/78814987

面试必备之乐观锁与悲观锁
https://blog.csdn.net/qq_34337272/article/details/81072874

一文搞懂 db2 的锁（表锁、行锁、共享锁、排他锁）
https://blog.csdn.net/somezz/article/details/84844555

DB2 隔离级别
https://blog.csdn.net/huaxin520/article/details/8312875

MySQL学习笔记(五)：MySQL表级锁和行级锁
https://www.cnblogs.com/zhanht/p/5431273.html