共享锁

在并发编程中，经常会遇到多个线程访问同一个共享变量，当同时对共享变量进行读写操作时，就会产生数据不一致的情况。 为了解决这个问题 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

laravel 提供了方便快捷的数据库事务使用方式，在使用中遇到过几个容易混淆和被误导的地方，这里做个记录，希望哪里写的不对的地方各位大神指点一下 laravel 事务分为手动方式和自动方式。 但如果我们在使用 laravel 提供的 sharedLock 或者 lockForUpdate 锁表的方式，为了避免不必要的麻烦和错误，建议最好使用手动提交事务来处理，如下图: 下面来说说 sharedLock (共享锁) 和 lockForUpdate (悲观锁) 这两个在使用上的区别和影响 sharedLock (共享锁) sharedLock 使用时等同于 SQL 语句 select from transaction_test where type = 1 lock in share mode; 在事务中使用 sharedLock 时才会生效，会把数据所在行进行锁定，此时被锁定的数据，不允许被其他操作修改，但是被锁定的数据，对查询操作没有影响，无论是普通查询还是事务中的查询操作，都不会受到影响。 被锁定的数据，知道事务被提交或者回滚之后，才会释放. lockForUpdate (悲观锁) lockForUpdate 使用时等同于 SQL 语句 select from transaction_test where type = 1 for update; lockForUpdate

锁的概述 一. 为什么要引入锁 多个用户同时对数据库的并发操作时会带来以下数据不一致的问题: 丢失更新 A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统 脏读 A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致 不可重复读 A用户读取数据,随后B用户读出该数据并修改,此时A用户再读取数据时发现前后两次的值不一致 并发控制的主要方法是封锁,锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致 二 锁的分类 锁的类别有两种分法： 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁 MS-SQL Server 使用以下资源锁模式。 锁模式 描述 共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。 更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。 排它 (X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。 意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。 架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改

(1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束，而不是在语句执行完立即释放所添加的锁。 　　 (2) NOLOCK：不添加共享锁和排它锁，当这个选项生效后，可能读到未提交读的数据或“脏数据”，这个选项仅仅应用于SELECT语句。 　　 (3) PAGLOCK：指定添加页锁（否则通常可能添加表锁）。　 　　 (4) READCOMMITTED用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。 (5) READPAST: 跳过已经加锁的数据行，这个选项将使事务读取数据时跳过那些已经被其他事务锁定的数据行，而不是阻塞直到其他事务释放锁，READPAST仅仅应用于READ COMMITTED隔离性级别下事务操作中的SELECT语句操作。　 　　 (6) READUNCOMMITTED：等同于NOLOCK。　 　　 (7) REPEATABLEREAD：设置事务为可重复读隔离性级别。　 　　 (8) ROWLOCK：使用行级锁，而不使用粒度更粗的页级锁和表级锁。　　 　　 (9) SERIALIZABLE：用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。　 　　 (10) TABLOCK：指定使用表级锁，而不是使用行级或页面级的锁，SQL Server在该语句执行完后释放这个锁

写在前面 这篇文章是在网络上看到其他作者的优秀博文，自己消化理解之后所做的记录。文章基于 MySQL 中的 InnoDB 存储引擎。 原博文地址： 点我 锁 锁知识概览 我们先看一张锁的概览图，方便后续的讲述： 我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库 隐式 帮我们加了；只在某些特定的场景下，才需要程序员手动加锁。 在执行「查询语句」 SELECT 前，会自动给涉及的所有表加「表级锁」中的 读锁 ；在执行「更新操作」 UPDATE、DELETE、INSERT 前，会自动给涉及的表加「表级锁」中的 写锁 对于 InnoDB ,且 使用了索引 的「更新操作」 UPDATE、DELETE、INSERT 语句；这时 InnoDB 会将「表锁」转换成「行锁」，也就是会自动给涉及数据集加「行级锁」中的 排他锁（X) 注意 ：InnoDB 只有通过「索引」检索数据才使用「行级锁」，否则，InnoDB将使用表锁；也就是说，InnoDB 的 行锁基于索引 。 一种特殊情况 如果我们对表中的某列加的是「普通索引」，那也就意味着： 索引列属性可能重复 。 对于普通索引，当 重复率高 时，MySQL 不会把这个普通索引当做索引，即会造成一个没有索引的SQL，从而 形成表锁 。 锁的分类 从上图中，以锁的粒度出发，我们可以看到锁分为「表级锁」和「行级锁」 『表锁』：开销小，加锁快

数据库基本知识点梳理系列 - 锁 数据库的锁是用于保证数据库事务在并发的情况下依旧能够保证数据的一致性的. 所以深入理解锁的原理, 能够帮助我们更好地理解事务隔离级别的原理, 以及在实际的业务场景中, 有把握的使用隔离级别保障系统的效率和稳定. 锁的分级 级别 加锁速度以及开销 是否会出现死锁的情况 粒度 并发事务的性能影响 表级锁 快, 开销小 不会出现死锁 锁定粒度很大, 因此发生加锁的冲突概率最高 并发度最低 行级锁 开销大, 加锁慢 会出现死锁 锁定粒度最小, 发生加锁冲突概率最低 并发度最高 页面锁 开销和加速速度介于上面两者间 会出现死锁 粒度介于上面两者之间 并发度介于两者之间 行级锁 锁名称 代号 描述 共享锁 （S） 读锁 。可以并发读取数据，但不能修改数据。也就是说当数据资源上存在共享锁的时候，所有的事务都不能对这个资源进行修改，直到数据被所有资源读取完成，共享锁释放。 排它锁 （X） 独占锁、 写锁 。就是如果你对数据资源进行增删改(DML)操作时，不允许其它任何事务操作这块资源，直到排它锁被释放，防止同时对同一资源进行多重操作。当资源上已经有共享锁或者排他锁, 则无法对这个资源添加额外的排他锁. 即排他锁与共享锁不兼容. 排他锁与自己也不兼容. 更新锁 （U） 当事务发现资源上既没有更新锁也没有排他锁时, 可以对资源添加更新锁, 也就是说,

数据库锁知识 不少人在开发的时候，应该很少会注意到这些锁的问题，也很少会给程序加锁(除了库存这些对数量准确性要求极高的情况下)，即使我们不会这些锁知识，我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库隐式帮我们加了，只会在某些特定的场景下才需要手动加锁。 对于UPDATE、DELETE、INSERT语句，InnoDB会自动给涉及数据集加排他锁（X) MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁，在执行增、删、改操作前，会自动给涉及的表加写锁，这个过程并不需要用户干预 表锁 首先，从锁的粒度，我们可以分成两大类： 表锁 :开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低 行锁:开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高 不同的存储引擎支持的锁粒度是不一样的==：InnoDB行锁和表锁都支持、MyISAM只支持表锁！InnoDB只有通过索引条件检索数据才使用行级锁==，否则，InnoDB使用表锁也就是说，InnoDB的行锁是基于索引的！ 表锁下又分为两种模式： 表读锁（Table Read Lock）&& 表写锁（Table Write Lock） 从下图可以清晰看到，在表读锁和表写锁的环境下：读读不阻塞，读写阻塞，写写阻塞！读读不阻塞：当前用户在读数据，其他的用户也在读数据，不会加锁 读写阻塞

转载文章，拜读了一下原文感觉很不错，转载一下，侵删 链接地址： http://objcoding.com/2019/05/05/aqs-exclusive-lock/ Java并发之AQS源码分析（一） 2019-05-05 zch Java concurrent AQS CAS AQS 全称是 AbstractQueuedSynchronizer，顾名思义，是一个用来构建锁和同步器的框架，它底层用了 CAS 技术来保证操作的原子性，同时利用 FIFO 队列实现线程间的锁竞争，将基础的同步相关抽象细节放在 AQS，这也是 ReentrantLock、CountDownLatch 等同步工具实现同步的底层实现机制。它能够成为实现大部分同步需求的基础，也是 J.U.C 并发包同步的核心基础组件。 AQS 结构剖析 AQS 就是建立在 CAS 的基础之上，增加了大量的实现细节，例如获取同步状态、FIFO 同步队列，独占式锁和共享式锁的获取和释放等等，这些都是 AQS 类对于同步操作抽离出来的一些通用方法，这么做也是为了对实现的一个同步类屏蔽了大量的细节，大大降低了实现同步工具的工作量，这也是为什么 AQS 是其它许多同步类的基类的原因。 现在我们来直接定位到类 java.util.concurrent.locks.AbstractQueuedSynchronizer，下面是 AQS

orcle的锁机制是一种轻量级的锁定机制，不是通过构建锁列表来进行数据的锁定管理，而是直接将锁作为数据块的属性，存储在数据块首部。 在oracle数据库中，它并不是对某个表加上锁或者某几行加上锁，锁是以数据块的一个属性存在的。也就是说，每个数据块本身就存储着自己数据块中数据的信息，这个地方叫做ITL（INTERESTRED TRANASCTION LIST），凡是在这个数据块上有活动的事务，它的信息就会记录在这里面供后续的操作查询，保证事务的一致性。 在oracle数据库中，不存在真正意义上属于某个对象或数据的锁。oracle锁的信息是数据块的一个物理属性，而不是逻辑上属于某个表或者某个行。 ----------------------------------------------------------------------------------------------------------------------- 按照操作分为DML锁，DDL锁和system locks 首先需要知道的是： 在数据行上只有X锁（排他锁）： 在 Oracle 数据库中，当一个事务首次发起一个 DML 语句时就获得一个 TX 锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行 DML 语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后， TX

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