共享锁

一：概述 相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；InnoDB存储引擎既支持行级锁（ row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MySQL主要的两种锁的特性可大致归纳如下:  表级锁： 开销小，加锁快；不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁)；锁定粒度大，发生锁冲突的概率最高,并发度最低。  行级锁： 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 考虑上述特点，表级锁使用与并发性不高，以查询为主，少量更新的应用，比如小型的web应用；而行级锁适用于高并发环境下，对事务完整性要求较高的系统，如在线事务处理系统。 二：MyISAM锁细述 (1). 锁模式 MySQL的表级锁有两种模式： 表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。 (2). 如何加锁 当MyISAM在执行查询语句时，会自动给涉及到表加读锁，在执行更新操作时，会加写锁。当然用户也可以用LOCK TABLE 去显式的加锁。显式的加锁一般是应用于：需要在一个时间点实现多个表的一致性读取，不然的话，可能读第一个表时

一：概述 相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；InnoDB存储引擎既支持行级锁（ row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MySQL主要的两种锁的特性可大致归纳如下:  表级锁： 开销小，加锁快；不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁)；锁定粒度大，发生锁冲突的概率最高,并发度最低。  行级锁： 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 考虑上述特点，表级锁使用与并发性不高，以查询为主，少量更新的应用，比如小型的web应用；而行级锁适用于高并发环境下，对事务完整性要求较高的系统，如在线事务处理系统。 二：MyISAM锁细述 (1). 锁模式 MySQL的表级锁有两种模式： 表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。 (2). 如何加锁 当MyISAM在执行查询语句时，会自动给涉及到表加读锁，在执行更新操作时，会加写锁。当然用户也可以用LOCK TABLE 去显式的加锁。显式的加锁一般是应用于：需要在一个时间点实现多个表的一致性读取，不然的话，可能读第一个表时

这段时间一直在学习 mysql 数据库。项目组一直用的是 oracle ，所以对 mysql 的了解也不深。本文主要是对 mysql 锁的总结。 Mysql 的锁主要分为 3 大类： 表级锁：存储引擎为 Myisam 。锁住整个表，特点是开销小，加锁快，锁定力度大，发生锁冲突的概率最高，并发度最低。 页级锁：存储引擎为 BDB 。锁住某一页的数据（ 16kb 左右），特点：开销和枷锁时间介于表级和行级之间；会出现死锁，锁定力度介于表锁和行锁之间，并发度一般。 行级锁：存储引擎为 innodb 。锁住某一行的数据，特点：锁的实现更加复杂，开销大，加锁速度慢。 根据以上特点，仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如 Web 应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（ OLTP ）系统。 接下来进行行级锁的详解，行级锁主要分为以下 7 类：共享 / 排他锁、意向锁、记录锁、间隙锁、临建锁、插入意向锁、自增锁。 共享 / 排他锁： 共享锁：又称读锁，可以允许读，但不能写。共享锁可以与共享锁一起使用。 语句： select ... lock in share mode 排他锁：又称写锁，不能允许读，也不能允许写，排他锁不能与其他所一起使用。 语句： select ... for

1.可重入锁 synchronized和Lock都是可重入锁 表明了锁的分配机制是基于线程，而不是基于方法 例如，在一个同步方法中调用了另一个同步方法，再进入第二个同步方法时，不需要重新申请锁 2.可中断锁 synchronized是不可中断的。 　　一个线程已经获得了某对象的锁，另一个线程想获得该对象的锁时，必须等待，直到第一个线程释放锁（执行完、异常） Lock调用lockInterruptibly方法获得锁时，是可中断的。 　　一个线程已经获得了某对象的锁，另一个线程想获得该对象的锁时，等待，在等待过程中，可以调用该线程的interrupt方法终端等待 3.公平锁、非公平锁 公平锁：按照请求的顺序获得锁 非公平锁：不保证获取锁的顺序，吞吐量高，造成优先级反转或者饥饿现象（有的线程一直等待） synchronized是非公平锁 Lock的实现类：ReentrantLock它默认情况下是非公平锁，在创建相应对象时，使用重载的构造器，传入参数（true），设置成公平锁 4.共享锁、排它锁 共享锁：锁可以被多个线程持有 排它锁：锁只能被一个线程持有 synchronized和Lock都是排它锁 ReadWriteLock（读写锁），其读锁是共享锁，写锁是排它锁 　　 　　实现类ReentrantReadWriteLock 　　 　　 5.乐观锁、悲观锁 乐观锁：对同一数据的并发操作

案例描述 在定时脚本运行过程中，发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时，mysql会检测出死锁，并打印出日志。 两个sql语句如下： （1）insert into backup_table select * from source_table （2）DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND joinTime<'$daysago_1week' teamUser 表的表结构如下： PRIMARY KEY (`uid`,`Id`), KEY `k_id_titleWeight_score` (`Id`,`titleWeight`,`score`), ENGINE=InnoDB 两语句对source_table表的使用情况如下： 死锁日志打印出的时间点表明，语句（1）运行过程中，当语句（2）开始运行时，发生了死锁。 当mysql检测出死锁时，除了查看mysql的日志，还可以通过show InnoDB STATUS \G语句在mysql客户端中查看最近一次的死锁记录。由于打印出来的语句会很乱，所以，最好先使用pager less命令，通过文件内容浏览方式查看结果，会更清晰。（以nopager结束） 得到的死锁记录如下： 根据死锁记录的结果，可以看出确实是这两个语句发生了死锁

引言 大家在面试中有没遇到面试官问你下面六句Sql的区别呢 select * from table where id = ? select * from table where id < ? select * from table where id = ? lock in share mode select * from table where id < ? lock in share mode select * from table where id = ? for update select * from table where id < ? for update 如果你能清楚的说出，这六句sql在不同的事务隔离级别下，是否加锁，加的是共享锁还是排他锁，是否存在间隙锁，那这篇文章就没有看的意义了。 之所以写这篇文章是因为目前为止网上这方面的文章太片面，都只说了一半，且大多没指明隔离级别，以及 where 后跟的是否为索引条件列。在此，我就不一一列举那些有误的文章了，大家可以自行百度一下，大多都是讲不清楚。 OK，要回答这个问题，先问自己三个问题 当前事务隔离级别是什么 id列是否存在索引 如果存在索引是聚簇索引还是非聚簇索引呢？ OK，开始回答 正文 innodb一定存在聚簇索引，默认以主键作为聚簇索引 有几个索引，就有几棵B+树(不考虑hash索引的情形)

一、业务场景 同一个jvm里多个线程操作同一个有状态的变量，可以通过JVM内的锁保证线程安全。 如果是多个JVM操作同一个有状态的变量，如何保证线程安全呢？ 这时候就需要分布式锁来发挥它的作用了 （想自学习编程的小伙伴请搜圈T社区]mhttp://www.ag-Nquanti.co)( http://www.aiquanti.com )]，更多行业相关资讯更有行业相关免费视频教程。完全免费哦!） 二、特点 分布式系统往往业务流量比较大、并发较高，对分布式锁的高可用和高性能有较高的要求。一般分布式锁的方案需要满足如下要求： 有高可用的获取锁和释放锁功能 获取锁和释放锁的性能要好 这把锁要是一把可重入锁（避免死锁） 这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条） 这把锁最好是一把公平锁（根据业务需求考虑要不要这条） 三、基于数据库的分布式锁方案 1、基于表主键唯一做分布式锁 利用主键唯一的特性，如果有多个请求同时提交到数据库的话，数据库会保证只有一个插入操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，当方法执行完毕之后，想要释放锁的话，删除这条数据库记录即可 1.1、缺点 数据库单点 没有锁超时机制 不可重入 非公平锁 非阻塞锁 1.2、优化点 数据库主从备份，解决单点问题。因为主从同步有延迟，可能导致数据不一致 定时任务检测锁超时自动释放或者通过

死锁的发生 sql大概是这样的 A1 update 表 set 字段 = (select * from 表 where 主键 = ‘’)…(再做某些处理) A2 update 表 set 字段 = (select * from 表 where 主键 = ‘’)…(再做某些处理) 这条sql单独执行的时候没有问题,但当两条相同的主键都要update时就发生了死锁,最后分析如果有误望大神指正(MySQL,innodb) A1 对 表加共享锁， A2 也对 表 加共享锁， 当 A1 的 select 执行完时执行 update， 根据锁机制， A1 的共享锁需要升级到排他锁才能执行接下来的 update .在升级排他锁前， 必须等 表 上的其它共享锁,也就是A2释放， 同时，A2 也在等 A1 的共享锁释放。于是死锁产生了。 来源： https://blog.csdn.net/cuigaoshun/article/details/98874019

原文： https://www.jianshu.com/p/46bd98ea9845 公平锁与非公平锁： https://www.cnblogs.com/DDiamondd/p/11316393.html 自旋锁与阻塞锁： 自旋锁： 是指当线程获取锁失败的时候，去执行一个无意义的循环，循环结束后再重新去竞争锁，如果竞争不到则继续循环。整个过程中线程一直处于运行（running）状态。 阻塞锁： 和自旋锁相对，指当线程获取锁失败时，线程进入阻塞（blocking）状态，当获取相应的信号时（唤醒，时间），进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争，进入运行状态。 自旋锁的出现原因： 线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作。而且，很多对象锁的锁定状态只会持续很短的一段时间，例如整数的自加操作，在很短的时间内阻塞并唤醒线程显然不值得，为此引入了自旋锁。 适用情况： 自旋等待不能代替阻塞。自旋等待本身虽然，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋当代的效果就会非常好，反之，如果锁被占用的时间很长，那么自旋的线程只会白白浪费处理器资源。 可重入锁和不可重入锁： 可重入锁： 指的是同一线程外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。即获取锁的粒度是线程而不是调用。 不可重入锁：

引言 大家在面试中有没遇到面试官问你下面六句Sql的区别呢 select * from table where id = ? select * from table where id < ? select * from table where id = ? lock in share mode select * from table where id < ? lock in share mode select * from table where id = ? for update select * from table where id < ? for update 如果你能清楚的说出，这六句sql在不同的事务隔离级别下，是否加锁，加的是共享锁还是排他锁，是否存在间隙锁，那这篇文章就没有看的意义了。 之所以写这篇文章是因为目前为止网上这方面的文章太片面，都只说了一半，且大多没指明隔离级别，以及 where 后跟的是否为索引条件列。在此，我就不一一列举那些有误的文章了，大家可以自行百度一下，大多都是讲不清楚。 OK，要回答这个问题，先问自己三个问题 当前事务隔离级别是什么 id列是否存在索引 如果存在索引是聚簇索引还是非聚簇索引呢？ OK，开始回答 正文 本文假定读者，看过我的 《MySQL(Innodb)索引的原理》 。如果没看过，额，你记得三句话吧 innodb一定存在聚簇索引