共享锁

SQL Server中SELECT会真的阻塞SELECT吗？ https://www.cnblogs.com/kerrycode/p/6250606.html 在 SQL Server中，我们知道一个SELECT语句执行过程中只会申请一些意向共享锁(IS) 与共享锁(S), 例如我使用SQL Profile跟踪会话86执行SELECT * FROM dbo.TEST WHERE OBJECT_ID =1 这个查询语句，其申请、释放的锁资源的过程如下所示： 而且从最常见的锁模式的兼容性表，我们可以看到IS锁与S锁都是兼容的，也就是说SELECT查询是不会阻塞SELECT查询的。 现有的授权模式 请求的模式 IS S U IX SIX X 意向共享 (IS) 是 是 是 是 是 否 共享 (S) 是 是 是 否 否 否 更新 (U) 是 是 否 否 否 否 意向排他 (IX) 是 否 否 是 否 否 意向排他共享 (SIX) 是 否 否 否 否 否 排他 (X) 否 否 否 否 否 否 但是在某些特殊场景。你会看到SELECT语句居然“阻塞”SELECT操作，那么SQL Server中SELECT会真的阻塞SELECT操作吗？我们先构造测试的案例场景，那么先准备测试数据吧 CREATE TABLE TEST (OBJECT_ID INT, NAME VARCHAR(8));

Java中锁分类 锁的分类 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁（java.util.concurrent包下的几乎都是利用锁） CAS 它是解决轻微冲突的多线程场景下使用锁造成性能损耗的 一种机制 。先是 比较 ，如果不符合预期，则 重试 。它有三个操作因素： 内存位置 ， 预期原值 与 新值 。如果内存位置的值与预期原值相等，则处理器将该位置值更新为新值，如果不相等，则获取当前值，然后进行不断的轮询操作直到成果达到某个阙值退出。 AQS AbstractQueuedSynchronizer 简称AQS是一个抽象同步框架，可以用来实现一个依赖状态的同步器。JDK1.5中提供的 java.util.concurrent 包中的大多数的同步器 (Synchronizer) 如 Lock, Semaphore, Latch, Barrier 等，它们都是基于 java.util.concurrent.locks.AbstractQueuedSynchronizer 这个类的框架实现的。 乐观锁/悲观锁 乐观锁 :乐观锁是一种乐观思想，认为 读多写少 ，遇到并发的可能性低，每次拿数据时候并 不会上锁 ，因为认为不会被别人修改。但是更新的时候会判断有没有人会更新这条数据，采取写的时候先 读取版本号然后加锁

本博客系列是学习并发编程过程中的记录总结。由于文章比较多，写的时间也比较散，所以我整理了个目录贴（传送门），方便查阅。 并发编程系列博客传送门 乐观锁和悲观锁 锁从宏观上来分类，可以分为悲观锁与乐观锁。注意，这里说的的锁可以是数据库中的锁，也可以是Java等开发语言中的锁技术。悲观锁和乐观锁其实只是一类概念（对某类具体锁的总称），不是某种语言或是某个技术独有的锁技术。 乐观锁 是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。java中的乐观锁基本都是通过CAS操作实现的，CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。数据库中的共享锁也是一种乐观锁。 悲观锁 是就是悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会block直到拿到锁。java中典型的悲观锁就是Synchronized,AQS框架下的锁则是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁，如ReentrantLock。数据库中的排他锁也是一种悲观锁。

乐观锁 乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。 　实现方式1：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。 举例：假设莫某个商品是有库存才能下单，有库存的状态是1，没有库存状态变为2，用状态status表示。 下单操作包括3步骤： 1.查询出商品信息 select (status,status,version) from t_goods where id=#{id} 2.根据商品信息生成订单 3.修改商品status为2 update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};

一、相关名词 |--表级锁（锁定整个表） |--页级锁（锁定一页） |--行级锁（锁定一行） |--共享锁（S锁，MyISAM 叫做读锁） |--排他锁（X锁，MyISAM 叫做写锁） |--悲观锁（抽象性，不真实存在这个锁） |--乐观锁（抽象性，不真实存在这个锁） 二、InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM 存储引擎，之后使用 InnoDB 。查看当前存储引擎： show variables like '%storage_engine%'; MyISAM 操作数据都是使用的表锁，你更新一条记录就要锁整个表，导致性能较低，并发不高。当然同时它也不会存在死锁问题。 而 InnoDB 与 MyISAM 的最大不同有两点：一是 InnoDB 支持事务；二是 InnoDB 采用了行级锁。也就是你需要修改哪行，就可以只锁定哪行。 在 Mysql 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。 InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁

原文： https://www.jb51.net/article/139113.htm MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁；BDB存储引擎采用的是页面锁，但也支持表级锁；InnoDB存储引擎既支持行级锁，也支持表级锁，但默认情况下采用行级锁。 MySQL这3种锁的特性可大致归纳如下： （1）表级锁 ：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 （2）行级锁 ：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 （3）页面锁 ：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 仅从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理系统。 一、MyISAM表锁 1. 查询表级锁争用情况 show status like 'table%'; 如果table_locks_waited 的值比较高，则说明存在着比较严重的表级锁争用情况。 2. MySQL表级锁的锁模式 MySQL 的表级锁有两种模式：表共享读锁和表独占写锁。 当一个session对某个表加了读锁之后

数据库锁 共享锁(Shared lock) 例1： ---------------------------------------- T1: select * from table (请想象它需要执行1个小时之久，后面的sql语句请都这么想象） T2: update table set column1='hello' 过程：T1运行 （加共享锁) T2运行等待T1运行完之后再运行T2 之所以要等，是因为T2在执行update前，试图对table表加一个排他锁，而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1执行完，释放了共享锁，才能加上排他锁，然后才能开始执行update语句。 例2： ---------------------------------------- T1: select * from table T2: select * from table 这里T2不用等待T1执行完，而是可以马上执行。 分析： T1运行，则table被加锁，比如叫lockA T2运行，再对table加一个共享锁，比如叫lockB。 两个锁是可以同时存在于同一资源上的（比如同一个表上）。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源，但阻止其它session update 例3： ---------------------------------

1. 数据库表锁定原理 1.1 目前的C/S,B/S结构都是多用户访问数据库,每个时间点会有成千上万个user来访问DB,其中也会同时存取同一份数据,会造成数据的不一致性或者读脏数据. 1.2 事务的ACID原则 1.3 锁是关系数据库很重要的一部分, 数据库必须有锁的机制来确保数据的完整和一致性. 1.3.1 SQL Server中可以锁定的资源: 1.3.2 锁的粒度: 1.3.3 锁的升级: 锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置. 1.3.4 锁的类型: (1) 共享锁: 共享锁用于所有的只读数据操作. (2) 修改锁: 修改锁在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象 (3) 独占锁: 独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。 (4) 架构锁 结构锁分为结构修改锁（Sch-M）和结构稳定锁（Sch-S）。执行表定义语言操作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。 (5) 意向锁 意向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。 (6) 批量修改锁 批量复制数据时使用批量修改锁 1.3.4 SQL Server锁类型 (1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束

【架构师技巧分享】程序员面试美团：面试官突然问Java “锁”你应该怎么回答？ Java提供了种类丰富的锁，每种锁因其特性的不同，在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码（本文中的源码来自JDK 8）、使用场景进行举例，为读者介绍主流锁的知识点，以及不同的锁的适用场景。 Java中往往是按照是否含有某一特性来定义锁，我们通过特性将锁进行分组归类，再使用对比的方式进行介绍，帮助大家更快捷的理解相关知识。下面给出本文内容的总体分类目录： 1.乐观锁 VS 悲观锁 乐观锁与悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。在Java和数据库中都有此概念对应的实际应用。 先说概念。对于同一个数据的并发操作，悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。Java中，synchronized关键字和Lock的实现类都是悲观锁。 而乐观锁认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）。 乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法

from:http://www.cnblogs.com/chenmh/p/3998614.html 标签： SQL SEERVER/MSSQL SERVER/SQL/事务隔离级别选项/设置数据库事务级别 SQL 事务隔离级别 概述 隔离级别用于决定如果控制并发用户如何读写数据的操作，同时对性能也有一定的影响作用。 步骤 事务隔离级别通过影响读操作来间接地影响写操作；可以在回话级别上设置事务隔离级别也可以在查询（表级别）级别上设置事务隔离级别。 事务隔离级别总共有6个隔离级别： READ UNCOMMITTED(未提交读,读脏),相当于(NOLOCK) READ COMMITTED(已提交读,默认级别) REPEATABLE READ(可以重复读),相当于(HOLDLOCK) SERIALIZABLE(可序列化) SNAPSHOT(快照) READ COMMITTED SNAPSHOT(已经提交读隔离) 对于前四个隔离级别：READ UNCOMMITTED<READ COMMITTED<REPEATABLE READ<SERIALIZABLE 隔离级别越高,读操作的请求锁定就越严格,锁的持有时间久越长;所以隔离级别越高,一致性就越高,并发性就越低,同时性能也相对影响越大. 获取事务隔离级别(isolation level) DBCC USEROPTIONS 设置隔离 设置回话隔离