共享锁

SQL SERVER锁的机制 SQL server的所有活动都会产生锁。锁定的单元越小，就越能越能提高并发处理能力，但是管理锁的开销越大。如何找到平衡点，使并发性和性能都可接受是SQL Server的难点。 SQL Server有如下几种琐： 1、 共享锁 用于只读操作(SELECT)，锁定共享的资源。共享锁不会阻止其他用户读，但是阻止其他的用户写和修改。 2、 更新锁 更新锁是一种意图锁，当一个事务已经请求共享琐后并试图请求一个独占锁的时候发生更新琐。例如当两个事务在几行数据行上都使用了共享锁，并同时试图获取独占锁以执行更新操作时，就发生了死锁：都在等待对方释放共享锁而实现独占锁。更新锁的目的是只让一个事务获得更新锁，防止这种情况的发生。 3、 独占锁 一次只能有一个独占锁用在一个资源上，并且阻止其他所有的锁包括共享缩。写是独占锁，可以有效的防止’脏读’。 4、 意图缩 在使用共享锁和独占锁之前，使用意图锁。从表的层次上查看意图锁，以判断事务能否获得共享锁和独占锁，提高了系统的性能，不需从页或者行上检查。 5、 计划锁 Sch-M,Sch-S。对数据库结构改变时用Sch-M，对查询进行编译时用Sch-S。这两种锁不会阻塞任何事务锁，包括独占锁。 读是共享锁，写是排他锁，先读后更新的操作是更新锁，更新锁成功并且改变了数据时更新锁升级到排他锁。锁的类型有： DB-----数据库，由于

如何并发的访问数据库呢？答案就是 加锁 。 接下来说一下， 数据库的锁机制，数据库中都有哪些锁？ 　　 首先呢，锁是一种 并发控制技术 ，锁是用来在多个用户同时访问同一个数据的时候保护数据的。 有2种基本的锁类型： 　　 共享（S）锁： 多个事务可封锁一个共享页；任何事务都不能修改该页；通常是该页被读取完毕，S锁立即被释放。在执行select语句的时候需要给操作对象（表或一些记录）加上共享锁，但加锁之前需要检查是否有排他锁，如果没有，则可以加共享锁（一个对象上可以加N个共享锁），否则不行。共享锁通常在执行完select语句之后被释放，当然也可能是在事务结束（包括正常结束和异常结束）的时候被释放，主要取决与数据库所设置的事务隔离级别。 　　 排它（X）锁： 仅允许一个事务封锁此页；其他任何事务必须等到X锁被释放才能对该页进行访问；X锁一直到事务结束才能被释放。执行insert、update、delete语句的时候需要给操作的对象加排它锁，在加排他锁之前必须确认该对象上没有其他任何锁，一旦加上排它锁之后，就不能再给这个对象加其他任何锁。排它锁的释放通常是在事务结束的时候（当然也有例外，就是在数据库事务隔离级别被设置为Read Uncommitted（读未提交数据）的时候，这种情况下排他锁会在执行完更新操作之后被释放，而不是在事务结束的时候）。 按锁的机制 既然使用了锁

MySQL事务 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在一个商城系统中，用户执行购买操作，那么用户订单中应该加一条，库存要减一条，如果这两步由于意外只进行了其中一步那么就会发生很大的问题。而事务可以很好的解决这个问题。 事务是数据库处理操作，其中执行就好像它是一个单一的一组有序的工作单元。换言之在组内每个单独的操作是成功的，那么一个事务才是完整的。如果事务中的任何操作失败，整个事务将失败。 事务性质： 原子性：确保工作单位中所有操作都成功完成；否则，事务被中止，在失败时会回滚到事务操作以前的状态。 一致性：可确保数据库在正确的更改状态进行一个成功的提交事务。 隔离性：使事务相互独立的操作。 持久性：确保了提交事务的结果或系统故障情况下仍然存在作用。 TCL(事务控制语言)： begin; 操作; commit; BEGIN或START TRANSACTION; #显式地开启一个事务 COMMIT;或COMMIT WORK; #二者等阶。COMMIT会提交事务并使已对数据库进行的所有修改成为永久性的。未COMMIT的操作都存放在内存中，仅当前客户端可以查看到，其他客户端看不到，当前客户端关闭后就清空了 ROLLBACK;或ROLLBACK WORK; #二者等阶。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改 SET AUTOCOMMIT=0

2.2.1 并发一致性问题 常见并发并发一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。 2.2.1.1 丢失修改 下面我们先来看一个例子，说明并发操作带来的数据的不一致性问题。 考虑飞机订票系统中的一个活动序列: 甲售票点（甲事务）读出某航班的机票余额A,设A=16. 乙售票点（乙事务）读出同一航班的机票余额A,也为16. 甲售票点卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库. 乙售票点也卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库. 结果明明卖出两张机票，数据库中机票余额只减少1。 归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（2.1.4数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是： 2.2.1.2 不可重复读 不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况： 事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200

3 月，跳不动了？>>> AbstractQueuedSynchronizer AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包 AQS的核心思想 是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态，如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。 CLH（Craig，Landin，and Hagersten）队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例，仅存在节点之间的关联关系。 用大白话来说，AQS就是基于CLH队列，用volatile修饰共享变量state，线程通过CAS去改变状态符，成功则获取锁成功，失败则进入等待队列，等待被唤醒。 CAS(Compare and Swap) 科普 ​ 如字面意思，就是先比较再替换， ​ cas方法有三个重要参数 : 待比较的值、预期值、要修改的新值， 如果预期值是待比较的值一致，那么就把 要修改的值赋值给待比较的值 ​ 伪代码如下: Object old; // 待比较的值 Object new; // 预期值 Object update;// 要修改的新值 if(old == new)

CountDownLatch是倒数，doneSignal = new CountDownLatch(LATCH_SIZE);赋初值后，在主线程中等待doneSignal.await();其它线程中，每完成一个就减一doneSignal.countDown();减到0时主线程继续。 CyclicBarrier是正数，cb = new CyclicBarrier(SIZE);主线程中开启各子线程，子线程调用cb.await()进行等待;cb计数count会加一，等于SIZE时会继续所有等待线程。 Semaphore是信号灯，Semaphore sem = new Semaphore(SEM_MAX);主线程中开启各子线程，子线程调用sem.acquire(count);每调用一次，sem计数会减相应数值，减为0时其它线程再调用acquire时会阻塞，线程结束后记得要sem.release(count); CountDownLatch和Semaphore用的是共享锁，而CyclicBarrier是独占锁。 CountDownLatch只能赋值一次，而CyclicBarrier可赋值多次。 概要 前面对" 独占锁 "和" 共享锁 "有了个大致的了解；本章，我们对CountDownLatch进行学习。 和ReadWriteLock.ReadLock一样

互斥锁(线程锁) 1.为什么要使用互斥锁? 线程之间共享资源,这就导致了多个线程之间资源竞争的问题 2.好处和坏处? 好处:保证了同一时间只允许一个线程的完整执行 坏处:阻止了线程的并发执行,效率降低 由于可以存在多个锁,不同的线程持有不同的锁,并获取对方的锁,可能会造成死锁 import threading # 创建锁 mutex = threading.Lock() # 锁定 mutex.acquire() #释放 mutex.release() 死锁 在线程间共享多个资源时,如果两个线程分别占有一部分资源,并且同时等待对方的资源,就会造成死锁 避免死锁 程序设计时尽量避免(银行家算法) 添加超时时间 乐观锁 乐观锁是相对悲观锁而言的,乐观锁假设数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测 乐观锁实现流程: 我们在更新之前，先查询一下库存表中当前库存数（quantity），然后在做update的时候，以库存数作为一个修改条件。 当我们提交更新的时候，判断数据库表对应记录的当前库存数与第一次取出来的库存数进行比对，如果数据库表当前库存数与第一次取出来的库存数相等，则予以更新，否则认为是过期数据。 悲观锁 当我们要对数据库的一条数据进行修改时,为了避免同时被其他人修改,最好的办法就是对该数据进行加锁以防止并发.这种借助数据库锁机制

本文源码： GitHub·点这里 || GitEE·点这里 一、锁概念简介 1、基础描述 锁机制核心功能是用来协调多个会话中多线程并发访问相同资源时，资源的占用问题。锁机制是一个非常大的模块，贯彻MySQL的几大核心难点模块：索引，锁机制，事务。这里是基于MySQL5.6演示的几种典型场景，对面MySQL这几块问题时，有分析流程和思路是比较关键的。在MySQL中常见这些锁概念：共享读锁、排它写锁 ; 表锁、行锁、间隙锁。 2、存储引擎和锁 MyISAM引擎：基于读写两种模式，支持表级锁 ; InnoDB引擎：支持行级别读写锁，跨行的间隙锁,InnoDB也支持表锁 ; 3、锁操作API LOCK TABLE name [READ,WRITE] ;加表锁 UNLOCK TABLES ; 释放标所 二、MyISAM锁机制 1、基础描述 MySQL的表级锁有两种模式：共享读锁（Read-Lock）和排它写锁（Write-Lock）。针对MyISAM表的读操作，不会阻塞其他线程对同一表的读请求，但阻塞对同一表的写请求；针对MyISAM表的写操作，会阻塞其他线程对同一表的读和写操作；MyISAM引擎读写操作之间，以及写与写操作之间是串行化。当一次会话线程获取表的写锁后，只有当前持有锁的会话线程可以对表进行操作。其它线程的读、写操作都会等待，直到锁被释放为止。 2、验证案例

3 月，跳不动了？>>> 这几天项目中遇到了数据库锁的问题，还在解决中，找到了一篇原理性的文章，分享一下。 在现代的多用户多任务系统中，必然会出现多个用户同时访问共享的某个对象，这个对象可能是表，行，或者内存结构，为了解决多个用户并发性访问带来的数据的安全性，完整性及一致性问题，必须要有一种机制，来使对这些共享资源的并发性访问串行化，oracle中的锁就可以提供这样的功能，当事务在对某个对象进行操作前，先向系统发出请求，对其加相应的锁，加锁后该事务就对该数据对象有了一定的控制权限，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作（可以做select动作，但select 利用的是undo中的前镜像数据了）. Oracle锁的分类 Oracle锁基本上可以分为二类 a：共享锁（share locks） 也称读锁，s锁 b：排它锁 (exclusive locks) 也称写锁，x锁 在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。 按锁保护的内容分类 oracle提供多粒度封锁机制，按保护对象来分，据此又可以分为 a：dml锁， data

2017年6月5日，天气——雨。 前两天整理之前的学习笔记时，发现对事务并发产生的问题——脏读、幻读、不可重复读和丢失更新这些概念有点模糊，于是又重新温习了一遍，现在把自己的一些理解归纳整理如下，方便大家学习。 锁就是防止其他事务访问指定资源的手段。锁是实现并发控制的主要方法，是多个用户能够同时操纵同一个 数据库 中的数据而不发生数据不一致现象的重要保障。 一般来说，锁可以防止脏读、不可重复读和幻读。 1. 脏读(Dirty Read) ——一个事务读取到了另外一个事务没有提交的数据。 详细解释：当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。 事务T1：更新一条数据 -->事务T2：读取事务T1更新的记录 事务T1：调用commit进行提交 此时事务T2读取到的数据是保存在数据库内存中的数据，称为脏数据，这个过程称为脏读。 脏读发生在一个事务A读取了被另一个事务B修改，但是还未提交的数据。假如B回退，则事务A读取的是无效的数据。这跟不可重复读类似，但是第二个事务不需要执行提交。 解决脏读问题：修改时加排他锁，直到事务提交后才释放，读取时加共享锁，读取完释放事务1读取数据时加上共享锁后