共享锁

J.U.C剖析与解读2（AQS的由来） 前言 前面已经通过实现自定义ReentrantLock与自定义ReentrantReadWriteLock，展示了JDK是如何实现独占锁与共享锁的。 那么实际JDK源码中的ReentrantLock与ReentrantReadWritreLock是如何实现的呢？我们现有的自定义代码是否可以更进一步呢？ 答案是肯定的。注意看我之前两个Lock的朋友，应该注意到了。自定义ReentrantReadWriteLock的独占锁部分，其实和自定义ReentrantLock是几乎一样的。 也就是说，不同Lock其实现是差不多的。那么是否可以提取公共的部分，是否可以写得更加优雅一些。 那么这篇博客，就是通过提取公共代码，引入模板方法设计模式，并利用Java的一些特性，写出一个自定义的AQS。 当然，最后也会剖析源码中AQS实现与我们自定义AQS的差别所在，并解读源码AQS中一些高级应用，如AQS通过一个state实现读写锁的持有数量（居然通过一个int值的CAS操作，解决了自定义读写锁持有数量的独占操作）。 如果看过源码的朋友，会发现源码中的ReentrantLock会自定义一个Sync，该Sync会继承一个AbstratQueueSynchronizer（简称AQS）。然后源码中的ReentrantLock的tryLock等方法

Java中，锁的种类按照不同的维度可以区分出很多的类型，比如是否公平？可读写？可重入？等等。而本文主要介绍JUC并发包Lock接口下锁的实现，以及对常见的锁类型介绍、在实际使用中应该注意什么等。 如下图，Lock接口及实现类。 一、区分synchronized和Lock 这两者最大的区别：synchronized是Java的一个关键字，Lock是Java并发包下的一个接口。 细分两者区别： 二、Java锁机制 1、公平锁与非公平锁 回到本文的主题，Lock接口，用创建ReentrantLock实例来说明在创建一个它的一个实例对象的时候都干了什么？打开源码看看。 如上图，默认的构造方法会创建一个非公平锁，而这个锁则是继承一个叫做AbstractQueuedSynchronizer的类（简称AQS）。这个AQS类是源码作者Doug Lea大神在JUC并发包中用来构建锁或者其他同步组件（信号量、事件等）的基础框架类，毫不夸张的说只要弄懂这个同步队列的实现，基本整个JUC理解起来都不会有太大困难，等参悟透了再写文章分享。AQS是一个高度抽象的类，用于解决在多线程编程中遇到的并发同步、锁等复杂问题。首先从基础说起，公平锁和非公平锁指的是什么？ 公平锁：指的是多个线程按照申请锁的顺序来获取锁，先到先得，FIFO（First In First Out）。 非公平锁

[zhuan]今天看群里在讨论数据库死锁的问题，也一起研究了下，查了些资料在这里总结下。 所谓死锁 ： 是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。 关于数据库死锁的检查方法 一、数据库死锁的现象 程序在执行的过程中，点击确定或保存按钮，程序没有响应，也没有出现报错。 二、死锁的原理 当对于数据库某个表的某一列做更新或删除等操作，执行完毕后该条语句不提 交，另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态， 此时的现象是这条语句一直在执行，但一直没有执行成功，也没有报错。 三、死锁的定位方法 通过检查数据库表，能够检查出是哪一条语句被死锁，产生死锁的机器是哪一台。 1）用dba用户执行以下语句 select username,lockwait,status,machine,program from v$session where sid in (select session_id from v$locked_object) 如果有输出的结果，则说明有死锁，且能看到死锁的机器是哪一台

一、概述 mysql的锁分为表锁和行锁两种，其中myisam引擎用的是表锁， innoDB默认的使用是行锁， 其他情况是表锁。 两种锁的优缺点： 表级锁：加锁速度快，开销小。不会出现死锁的情况，粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：加锁速度慢，开销大。 会出现死锁的情况，粒度小， 发生锁冲突的概率最小，并发度最高 页面锁：介于以上两者之间 无法确定哪种锁更合适： 表级锁更适合查询为主，只有少量按索引更新数据的应用，如web应用。 行级锁适合有大量索引并发更新少量不同的数据，同时有并发查询的应用，如一些在线的事物系统。 二、MyIsam存储引擎 只支持表锁。 查询表级锁的争用情况： table_locks_waited 和 table_locks_immediate 1. mysql> show status like 'table%'; 2. +-----------------------+-------+ 3. | Variable_name | Value | 4. +-----------------------+-------+ 5. | Table_locks_immediate | 2979 | 6. | Table_locks_waited | 0 | 2.1、表级锁的锁模式 两种模式：表共享读锁，表独占写锁 分析：

前段时间提到的"sql server 2005 死锁解决探索"，死锁严重，平均每天会发生一次死锁，在解决和处理SQL server2005死锁中查了很多资料和想了很多办法， 对为何出现死锁和怎样较少死锁有了进一步认识，在这里和大家一起分享： sql server 锁类型 在数据库中主要存在两种锁: S(共享锁）和X(排他锁） S(共享锁）：在执行查询数据时，sql server会将行锁定，这时只能查询数据，删，改被阻塞， X(排他锁）：在插入和删除数据时，将行锁定，这时增，删，改都被阻塞 以上两种锁都会引起死锁： 死锁定义：在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁 这里模拟一下死锁环境： 建立环境： ----死锁例子,建立表数据 create table [dbo].[[zping.com1]]]( A varchar(2) ,B varchar(2) ,C varchar(2)) --插入数据 insert into [dbo].[[zping.com1]]] select 'a1','b1','c1' union all select 'a2','b2','c2' union all select 'a3','b3','c3' --建立表数据 create table [dbo].[[zping.com2]]] (D

一、概述： 在SQLite中，锁和并发控制机制都是由pager_module模块负责处理的，如ACID(Atomic, Consistent, Isolated, and Durable)。在含有数据修改的事务中，该模块将确保或者所有的数据修改全部提交，或者全部回滚。与此同时，该模块还提供了一些磁盘文件的内存Cache功能。 事实上，pager_module模块并不关心数据库存储的细节，如B-Tree、编码方式、索引等，它只是将其视为由统一大小(通常为1024字节)的数据块构成的单一文件，其中每个块被称为一个页(page)。在该模块中页的起始编号为1，即第一个页的索引值是1，其后的页编号以此类推。 二、文件锁： 在SQLite的当前版本中，主要提供了以下五种方式的文件锁状态。 1). UNLOCKED： 文件没有持有任何锁，即当前数据库不存在任何读或写的操作。其它的进程可以在该数据库上执行任意的读写操作。此状态为缺省状态。 2). SHARED： 在此状态下，该数据库可以被读取但是不能被写入。在同一时刻可以有任意数量的进程在同一个数据库上持有共享锁，因此读操作是并发的。换句话说，只要有一个或多个共享锁处于活动状态，就不再允许有数据库文件写入的操作存在。 3). RESERVED： 假如某个进程在将来的某一时刻打算在当前的数据库中执行写操作，然而此时只是从数据库中读取数据

本文主要涉及以下几个个部分： 1. 为什么要加锁 2. 锁的分类 3. 常见语句的加锁分析 4. 如何分析死锁 5. 如何预防死锁 先列出本地的运行环境 数据库版本是5.7，隔离级别是Repeatable-Read(可重复读)，不同的数据库版本和隔离级别对语句的执行结果影响很大。所以需要说明版本和隔离级别 一、为什么要加锁 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中加锁是为了保证数据库的一致性。 数据库有ACID原则，其中I是隔离性， 脏读：读未提交的数据 不可重复读：读已修改的数据 虚读：读提交了插入/删除的数据 事务隔离机制 和标准SQL规范相比，MySQL中可重复读解决了幻读，实现了串行化隔离级别的功能，同时没有严重影响并发。是通过加锁、阻止插入新数据，来解决幻读的。 二、锁的分类 锁 我们听说过读锁、写锁、共享锁、互斥锁、行锁等等各种名词，简单对这些锁进行了分类。 锁的分类 加锁机制： 1、乐观锁：先修改，保存时判断是够被更新过，应用级别 2、悲观锁：先获取锁，再操作修改，数据库级别 锁粒度： 表级锁：开销小，加锁快，粒度大，锁冲突概率大，并发度低，适用于读多写少的情况。 页级锁：BDB存储引擎 行级锁：Innodb存储引擎，默认选项 兼容性： S锁，也叫做读锁、共享锁，对应于我们常用的 select * from users where id

转自 https://blog.csdn.net/C_J33/article/details/79487941 数据库锁 先看一张图自己整理的数据库锁的树形图 概要 数据库锁一般可以分为两类，一个是悲观锁，一个是乐观锁。 乐观锁一般是指用户自己实现的一种锁机制，假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。乐观锁的实现方式一般包括使用版本号和时间戳。 悲观锁一般就是我们通常说的数据库锁机制，以下讨论都是基于悲观锁。 悲观锁主要表锁、行锁、页锁。在MyISAM中只用到表锁，不会有死锁的问题，锁的开销也很小，但是相应的并发能力很差。innodb实现了行级锁和表锁，锁的粒度变小了，并发能力变强，但是相应的锁的开销变大，很有可能出现死锁。同时inodb需要协调这两种锁，算法也变得复杂。InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。 表锁和行锁都分为共享锁和排他锁（独占锁），而更新锁是为了解决行锁升级（共享锁升级为独占锁）的死锁问题。 innodb中表锁和行锁一起用，所以为了提高效率才会有意向锁（意向共享锁和意向排他锁）。 为了表锁和行锁而存在的意向锁 官方文档中是这么描述的，

SQL SERVER的锁机制系列： SQL SERVER的锁机制（一）——概述（锁的种类与范围） SQL SERVER的锁机制（二）——概述（锁的兼容性与可以锁定的资源） SQL SERVER的锁机制（三）——概述（锁与事务隔离级别） SQL SERVER的锁机制（四）——概述（各种事务隔离级别发生的影响） 锁定：通俗的讲就是加锁。锁定是 Microsoft SQL Server 数据库引擎用来同步多个用户同时对同一个数据块的访问的一种机制。 定义：当有事务操作时，数据库引擎会要求不同类型的锁定，如相关数据行、数据页或是整个数据表，当锁定运行时，会阻止其他事务对已经锁定的数据行、数据页或数据表进行操作。只有在当前事务对于自己锁定的资源不在需要时，才会释放其锁定的资源，供其他事务使用。 一、锁的种类与范围（如下表） 锁类型 说明 共享 (S) 用于不更改或不更新数据的读取操作，如 SELECT 语句。 更新 (U) 用于可更新的资源中。 防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。 独占(也可称排他)(X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。 确保不会同时对同一资源进行多重更新。 意向 用于建立锁的层次结构。 意向锁包含三种类型：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。 架构

在并发编程中，经常会遇到多个线程访问同一个共享变量，当同时对共享变量进行读写操作时，就会产生数据不一致的情况。 为了解决这个问题 JDK 1.5 之前，使用 synchronized 关键字，拿到 Java 对象的锁，保护锁定的代码块。JVM 保证同一时刻只有一个线程可以拿到这个 Java 对象的锁，执行对应的代码块。 JDK 1.5 开始，引入了并发工具包 java.util.concurrent.locks.Lock，让锁的功能更加丰富。 常见的锁 synchronized 关键字锁定代码库 可重入锁 java.util.concurrent.lock.ReentrantLock 可重复读写锁 java.util.concurrent.lock.ReentrantReadWriteLock Java 中不同维度的锁分类 可重入锁 指在同一个线程在外层方法获取锁的时候，进入内层方法会自动获取锁。JDK 中基本都是可重入锁，避免死锁的发生。上面提到的常见的锁都是可重入锁。 公平锁 / 非公平锁 公平锁，指多个线程按照申请锁的顺序来获取锁。如 java.util.concurrent.lock.ReentrantLock.FairSync 非公平锁，指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程先获得锁。如 synchronized、java.util