java的锁机制

锁（Lock）

锁是计算机在执行多线程或线程时用于并发访问同一共享资源时的同步机制，MySQL中的锁是在服务器层或者存储引擎层实现的，保证了数据访问的一致性与有效性。

锁机制的基本原理可以概括为：

• 事务在修改数据之前，需要先获得相应的锁；
• 获得锁之后，事务便可以修改数据；
• 该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁

1.查看锁

select * from information_schema.innodb_locks; #锁的概况
show engine innodb status; #InnoDB整体状态，其中包括锁的情况
#在事务A中执行：
start transaction;
update account SET balance = 1000 where id = 1;
#在事务B中执行：
start transaction;
update account SET balance = 2000 where id = 1;

2.锁机制的必要性

并发用户访问同一数据，锁机制可以避免数据不一致问题的发生。

3.MySQL锁分类

共享锁

又称之为读锁，简称S锁，当事务A对数据加上读锁后，其他事务只能对该数据加读锁，不能做任何修改操作，也就是不能添加写锁。只有当事务A上的读锁被释放后，其他事务才能对其添加写锁。

应用场景：
共享锁主要是为了支持并发的读取数据而出现的，读取数据时，不允许其他事务对当前数据进行修改操作，从而避免”不可重读”的问题的出现。

实现方式：

select * from dept WHERE dept_id=50 LOCK IN SHARE MODE;

排它锁

又称之为写锁、独占锁，排它锁，简称X锁，当事务对数据加上写锁后，其他事务既不能对该数据添加读写，也不能对该数据添加写锁，写锁与其他锁都是互斥的。只有当前数据写锁被释放后，其他事务才能对其添加写锁或者是读锁。

MySQL InnoDB引擎默认update,delete,insert都会自动给涉及到的数据加上排他锁select语句默认不会加任何锁类型。

应用场景：
写锁主要是为了解决在修改数据时，不允许其他事务对当前数据进行修改和读取操作，从而可以有效避免”脏读”问题的产生。

实现方式：

select * from dept WHERE dept_id=50 LOCK IN SHARE MODE;
select * from dept WHERE dept_id=50 FOR UPDATE;

锁的粒度分类

• 表级锁:开销小，加锁快，不会出现死锁，锁定力度大，发生冲突所的概率高，并发度低。
• 行级锁:开销大，加锁慢，会出现死锁，锁定力度最小，发生锁冲突的概率最低，并发度高。
• 页面锁:开销和加锁时间介于表锁和行锁之间，会出现死锁，锁定力度介于表和行行级锁之间，并发度一般。

MyISAM和MEMORY存储引擎采用表级锁
InnoDB支持行级锁、表级锁，默认情况采用行级锁

乐观锁

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做。

应用场景：
适用于读多写少，因为如果出现大量的写操作，写冲突的可能性就会增大，业务层需要不断重试，会大大降低系统性能。
实现方式:
一般使用数据版本（Version）记录机制实现，在数据库表中增加一个数字类型的 “version” 字段来实现

悲观锁

悲观锁，正如其名，具有强烈的独占和排他特性，每次去拿数据的时候都认为别人会修改，对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

应用场景：
适用于并发量不大、写入操作比较频繁、数据一致性比较高的场景。

实现方式：
select…for update是MySQL提供的实现悲观锁的方式，属于排它锁。
在MySQL中使用悲观锁，必须关闭MySQL的自动提交，set autocommit=0。共享锁和排它锁是悲观锁的不同的实现，它俩都属于悲观锁的范畴。

死锁

当某组资源的两个或多个线程之间有循环相关性时，将发生死锁。
死锁是一种可能发生在任何多线程系统中的状态，而不仅仅发生在关系数据库管理系统中。

给MyISAM表施加表级锁不会导致死锁问题的发生，这是由于MyISAM总是一次性地获得SQL语句的全部锁。
给InnoDB表施加行级锁可能导致死锁问题的发生，这是由于执行SQL语句期间，可以继续施加行级锁。

默认情况下： InnoDB存储引擎一旦出现锁等待超时异常，InnoDB存储引擎即不会提交事务，也不会回滚事务，而这是十分危险的。一旦发生锁等待超时异常，应用程序应该自定义错误处理程序，由程序开发人员选择进一步提交事务，还是回滚事务。

为尽可能避免死锁的发生，用户应该遵循以下原则：

• 在所有的事务中都按同一顺序来访问各个表。尽可能利用存储过程来完成一个事务，以便能保证对各表的访问次序都是一致的。
• 事务应该尽量小且应尽快提交。
• 尽量避免人工输入操作出现在事务中。
• 尽量避免同时执行诸如【INSERT】、【UPDATE】和【DELETE】等数据修改语句。