13、锁机制
解决资源共享而造成的并发问题
13.1、悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
13.2、乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读，少写的应用类型，这样可以提高吞吐量。
13.2.1、乐观锁的缺点
ABA 问题
如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。
自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销
13.2.2、乐观锁的实现
版本号机制
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略
CAS算法
即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数
- 需要读写的内存值 V
- 进行比较的值 A
- 拟写入的新值 B
当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。
CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效
锁的分类
操作类型：
- 读锁（共享锁）： 对同一个数据，多个读操作可以同时进行，但是不可以进行写操作
- 写锁（互斥锁）： 如果当前写操作没有完毕，那么无法进行其他的操作（读操作、写操作）
操作范围：
- 表锁：一次性对一张表整体加锁 例如MyISAM ,
- 优点：开销小，加锁快
- 缺点：锁的范围大，容易发生冲突。
- 行锁：一次性对一行数据加锁
- 页锁
锁操作
--加锁
lock table mytable read/write;
--查看加锁的表
show open tables;
--会话：session： 每一个访问数据的dos命令行、数据库客户端工具
----------【加读锁】
--会话0
--对A表加了【读锁】，那么会话0可以对A表进行读，但是不可以写
--会话0不可以对其他表进行 读和写
--其他会话
---可以对A表进行读操作，
---写操作会等待A表的读锁释放
----------【加写锁】
--会话0给表A加写锁，那么会话0可以对A表进行【任何操作】，但是【不能】对其他表操作
--其他会话：
---可以对会话0加锁的表进行增删改查，但是要等会话0释放锁
查看那些表加了锁： show open tables ；1代表加了锁
分析表锁定的严重程度： hosw status like ’ table%’ ；
table_locks_immediate：可能获取到的锁数
Table_locks_waited:表示要等待的锁数
表锁通过unlock tables 进行解锁
行锁通过事务进行解锁，commit rollback
行锁的注意情况
–如果没有【索引】，行锁会转换为【表锁】
索引类发生了 类型转换，那么索引失效。因此锁已经转换，那么会执行失败
行锁分析
show status like ‘%innodb_row_lock%’;
----Innodb_row_lock_current_waits ：当前正在等待的锁的数量
| Innodb_row_lock_time ： 等待总时长。从系统启动到现在一共等待的时间
| Innodb_row_lock_time_avg ：平均等待的市场。从系统启动到现在的平均等待时间
| Innodb_row_lock_time_max 最大等待时间。从系统启动到现在最大一次等待时间| Innodb_row_lock_waits ： 等待次数