共享锁

转载： https://www.cnblogs.com/nickup/p/9804020.html 共享锁（S锁）：共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。 如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。 排他锁（X锁）：用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。 如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。 我们在操作数据库的时候，可能会由于并发问题而引起的数据的不一致性（数据冲突） 乐观锁 乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。 通常实现是这样的：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作

1. Oracle跟SQL Server 2005的区别？ 宏观上： 1). 最大的区别在于平台，oracle可以运行在不同的平台上，sql server只能运行在windows平台上，由于windows平台的稳定性和安全性影响了sql server的稳定性和安全性 2). oracle使用的脚本语言为PL-SQL，而sql server使用的脚本为T-SQL 微观上： 从数据类型, 数据库 的结构等等回答 2. 如何使用Oracle的游标？ 1). oracle中的游标分为显示游标和隐式游标 2). 显示游标是用cursor...is命令定义的游标，它可以对查询语句(select)返回的多条记录进行处理；隐式游标是在执行插入 (insert)、删除(delete)、修改(update)和返回单条记录的查询(select)语句时由PL/SQL自动定义的。 3). 显式游标的操作：打开游标、操作游标、关闭游标；PL/SQL隐式地打开SQL游标，并在它内部处理SQL语句，然后关闭它 3. Oracle中function和procedure的区别？ 1). 可以理解函数是存储过程的一种 2). 函数可以没有参数,但是一定需要一个返回值，存储过程可以没有参数,不需要返回值 3). 函数return返回值没有返回参数模式，存储过程通过out参数返回值, 如果需要返回多个参数则建议使用存储过程

一、锁 　　1、数据库和操作系统一样，是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并 发控制的一个非常重要的技术。在实际应用中经常会遇到的与锁相关的异常情况，当两个事务需要一组有冲突的锁，而不能将事务继续下去的话，就会出现死锁，严重影响应用的正常执行。 　　2、在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两 种基本的锁类型来对数据库的事务进行并发控制。 　　3、死锁 　　　　（1）死锁的第一种情况 一个用户A 访问表A(锁住了表A),然后又访问表B；另一个用户B 访问表B(锁住了表B)，然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。 　　　　（2）死锁的第二种情况 用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A 有共享锁存在所以必须等A释放掉共享锁

首先需要知道几个名词： 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁 公平锁/非公平锁： 公平锁是指多个线程按照申请锁的顺序来获取锁。 非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。 可重入锁： 可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。 独享锁/共享锁： 独享锁是指该锁一次只能被一个线程所持有。 共享锁是指该锁可被多个线程所持有。 互斥锁/读写锁 上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。 乐观锁/悲观锁 乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。 悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。 乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。 从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。 悲观锁在Java中的使用

MySQL 数据库 锁机制简介 数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序所设计的一种规则。 对于任何一种数据库来说都需要有相应的锁定机制 ，所以 MySQL 自然也不能例外。 MySQL 数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计， 所以各存储引擎的锁定机制也有较大区别。 一、MySQL有三种锁的级别：页级、表级、行级。 MyISAM 和MEMORY 存储引擎采用的是表级锁； BDB 存储引擎采用的是页面锁，但也支持表级锁； InnoDB 存储引擎既支持行级锁，也支持表级锁，但默认情况下是采用行级锁。 MySQL 这3 种锁的特性可大致归纳如下： 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高, 并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低, 并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 二、死锁 死锁是指两个或者两个以上的事务在执行过程中，因争夺资源而造成的一种相互等待的现象。解决死锁最简单的一种方式是超时，即当两个事务相互等待是

原文地址： http://www.jianshu.com/p/1161d33fc1d0 搞清楚AQS独占锁的实现原理之后，再看共享锁的实现原理就会轻松很多。两种锁模式之间很多通用的地方本文只会简单说明一下，就不在赘述了，具体细节可以参考我的上篇文章 深入浅出AQS之独占锁模式 一、执行过程概述 获取锁的过程： 当线程调用acquireShared()申请获取锁资源时，如果成功，则进入临界区。 当获取锁失败时，则创建一个共享类型的节点并进入一个FIFO等待队列，然后被挂起等待唤醒。 当队列中的等待线程被唤醒以后就重新尝试获取锁资源，如果成功则 唤醒后面还在等待的共享节点并把该唤醒事件传递下去，即会依次唤醒在该节点后面的所有共享节点 ，然后进入临界区，否则继续挂起等待。 释放锁过程： 当线程调用releaseShared()进行锁资源释放时，如果释放成功，则唤醒队列中等待的节点，如果有的话。 二、源码深入分析 基于上面所说的共享锁执行流程，我们接下来看下源码实现逻辑： 首先来看下获取锁的方法acquireShared()，如下 public final void acquireShared ( int arg) { //尝试获取共享锁，返回值小于0表示获取失败 if (tryAcquireShared(arg) < 0 ) //执行获取锁失败以后的方法 doAcquireShared

一、基本概念 　　从操作的类型上来看，分为读锁和写锁： 　　　　读锁：共享锁，对同一份数据，多个读操作可以同时进行且相互间不影响 　　　　写锁：排它锁，独占资源。在当前操作未完成之前，其他写操作必须等待。读操作不影响。 　　　　　　　排它锁作用于innodb，且必须在事务块中执行。在进行事务操作时，for update会对结果集中的每一行数据加排它锁，其他线程对于结果集中的数据进行修改操作，全部阻塞。 　　从锁数据的细粒度上来看，分为行锁和表锁。 二、测试 　　测试环境：mysql 5.5.6、Navicat for mysql。 　　新建表： CREATE TABLE `tb_user` ( `id` int(10) NOT NULL AUTO_INCREMENT, `name` varchar(10) DEFAULT NULL, `password` varchar(10) DEFAULT NULL, `sex` char(1) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 　　开启两个查询会话，模拟多请求。 　　1、表锁 　　　　锁的粒度偏大，开销小，锁表快，但是发生锁竞争的概率特别高，并发度低。 　　　　对于更新update、delete

场景： 进入搜狗，输入搜索关键字进行搜索 利用多进程分布式实现 from multiprocessing import Pool import os, time from selenium import webdriver from selenium.webdriver.common.keys import Keys from multiprocessing import Manager, current_process import traceback #定义测试行为函数：此处为打开搜狗搜索内容 def node_task(name, lock, arg, successTestCases, failTestCases): """ :param name: 执行进程名 :param lock:进程间的共享资源锁 :param arg:node节点计算机、浏览器字典 ，如：{"node": "http://127.0.0.1:6666/wd/hub", "browserName": "chrome"} :param successTestCases:成功执行用例列表 :param failTestCases:失败用例列表 :return:返回成功执行、失败执行的用例列表 """ procName = current_process().name print("当前进程名:"

一.前言 　　 最近项目遇到多线程并发的情景（并发抢单&恢复库存并行），代码在正常情况下运行没有什么问题，在高并发压测下会出现：库存超发/总库存与sku库存对不上等各种问题。 　　 在运用了 限流/加锁等方案后，问题得到解决。 　　限流方案见本人另一篇博客： Guava-RateLimiter实现令牌桶限流 二.乐观锁 & 悲观锁 　　1.乐观锁 　　 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号(version)等机制。 　　 例如：mybatis-plus 自带插件OptimisticLockerInterceptor，在数据库表加上一个version字段，每次更新完数据库mp会自动在version字段上加1，如果在更新提交的时候发现version字段的值与数据库中最新的值不一致，则提交失败。 　　2.悲观锁 　　 悲观锁 总是假设会出现最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。 　　 传统的MySQL关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 　　 Java的同步synchronized关键字的实现就是典型的悲观锁。 　　3.总结 　　

表总体上分为三种： 　　1、表锁 Myisam　　开销小，并发低，加锁快，不会出现死锁问题；锁粒度大，发生锁冲突的概率最高。 　　3、页面锁　　　　　 开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。（不常用） 共享锁（读锁）/排它锁（写锁） 　　共享锁又叫读锁，是读取操作创建的锁。其他用户可以同步读取数据，但是不能够写数据。 　　排它锁又叫写锁，是更新操作创建的锁。其他用户不可以同步读取数据更不能写数据。 MyIsam锁模式： 　　MyIsam引擎在执行查询语句前，会自动给涉及到的表添加读锁；在更新操作前会自动给涉及到的表加写锁。 　　a、对MyIsam中的表进行读取操作，其他用户可以进行读取，但是不能修改； 　　b、对MyIsam中的表进行更新操作，其他用户不能进行读取，更不能进行操作。 InnoDb锁模式： 　　对于insert、update、delete，InnoDB会自动给涉及的数据加排他锁（X）；对于一般的Select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。 共享锁： SELECT ... LOCK IN SHARE MODE; 排他锁： SELECT ... FOR UPDATE; InnoDb是根据索引加行锁的，如果没有索引的话依然是加表锁。因此如果多行数据都使用同一个索引，会出现锁冲突