共享锁

本人免费整理了Java高级资料，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G，需要自己领取。传送门： https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q 作为一名开发人员，在日常的工作中会难以避免地接触到数据库，无论是基于文件的 sqlite 还是工程上使用非常广泛的 MySQL、PostgreSQL，但是一直以来也没有对数据库有一个非常清晰并且成体系的认知，所以最近两个月的时间看了几本数据库相关的书籍并且阅读了 MySQL 的官方文档，希望对各位了解数据库的、不了解数据库的有所帮助。 本文中对于数据库的介绍以及研究都是在 MySQL 上进行的，如果涉及到了其他数据库的内容或者实现会在文中单独指出。 数据库的定义 很多开发者在最开始时其实都对数据库有一个比较模糊的认识，觉得数据库就是一堆数据的集合，但是实际却比这复杂的多，数据库领域中有两个词非常容易混淆，也就是 数据库 和 实例 ： 数据库：物理操作文件系统或其他形式文件类型的集合； 实例：MySQL 数据库由后台线程以及一个共享内存区组成； 对于数据库和实例的定义都来自于 MySQL 技术内幕：InnoDB 存储引擎 一书，想要了解 InnoDB 存储引擎的读者可以阅读这本书籍。

项目常见面试问题 阅读目录 项目常见面试问题 回到目录 项目常见面试问题 一、你的项目中缓存粒度是如何选择的? 缓存粒度一共分为4种. 1.缓存某个数值:一个键只保存一个值,性价比较低,使用率低,如果存储的话我们使用redis的String 2.缓存数据对象:数据库记录对应的具体数据,优点是可以多次复用,String,hash 3.缓存数据集合:数据库查询对应的结果集,可以和数据对象配合使用,方便数据对象的重用,hash,list,set,zset,String(zset,String) 4.缓存试图响应:试图返回的相应数据,复用性比较差,String 所以我们项目中主要对数据集合+数据对象进行缓存,他们的优点是复用性强,节省内存空间. 二、使用过redis的那些格式做过缓存,其他应用场景和优缺点是什么? 包括list,zset,set,hash和json字符串 其中我们使用过json字符串和zset set用来存放无序去重的数据, 如果有判断是否存在的需求 zset有排序的需要list,如果说是按时间查询, 查询的结果固定, 不需要分页的情况下,我们使用list因为查询的比较快 但如果有额外排序要求, 而且需要分页, 我们使用zset(查询时间跟查询的长度和数据量有关,跟查询区别无关, 查询速度比较均衡), 增加数据效率和存储的数据量负相关,数据量越大,添加时间越长

oracle查看被锁的表和解锁 --以下几个为相关表 SELECT * FROM v$lock; SELECT * FROM v$sqlarea; SELECT * FROM v$session; SELECT * FROM v$process ; SELECT * FROM v$locked_object; SELECT * FROM all_objects; SELECT * FROM v$session_wait; --查看被锁的表 select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; --查看那个用户那个进程照成死锁 select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time; --查看连接的进程 SELECT sid, serial#, username, osuser FROM v$session; --3.查出锁定表的sid, serial#,os_user_name,

原文链接： http://blog.csdn.net/soonfly/article/details/70238902 锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。 Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。 MySQL锁概述 相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

共享锁和排它锁 MySQL的锁系统：shared lock和exclusive lock（共享锁和排他锁，也叫读锁和写锁，即read lock和write lock） 读锁是共享的，或者说是相互不阻塞的 写锁是排他的，一个写锁会阻塞其他的写锁和读锁 在实际的数据库系统中，每时每刻都发生锁定，当某个用户在修改某部分数据时，mysql会通过锁定阻止其他用户对同一数据的读取 共享锁【S锁】 又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。 这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。 排他锁【X锁】 又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。 这保证了其他事务在T释放A上的锁之前不能再读取和修改A。 锁的粒度和锁的策略MySQL 有三种锁的级别：页级、表级、行级。 MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MySQL这3种锁的特性可大致归纳如下： 表级锁：开销小

Locking read（ SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE ）， UPDATE 以及 DELETE 语句通常会在他扫描的索引所有范围上加锁，忽略没有用到索引的那部分where语句。 举个例子： CREATE TABLE `test` ( `id` int(11) NOT NULL DEFAULT '0', `name` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 select * from test where id > 3 and name <'A' for update; 这条SQL语句的会将所有 id>3 的记录进行加锁，而不是 id>3 and name <'A' 进行加锁，因为name上面没有索引。 如果一个SQL通过二级索引进行扫描，并且在二级索引上设置了一个锁，那么innodb将会在对应的聚簇索引记录上也加上一把锁。 如果一个SQL语句无法通过索引进行 Locking read ， UPDATE ， DELETE ，那么MySQL将扫描整个表，表中的每一行都将被锁定（在RC级别，通过 semi-consistent read ，能够提前释放不符合条件的记录，在RR级别

引言 大家在面试中有没遇到面试官问你下面六句Sql的区别呢 select * from table where id = ? select * from table where id < ? select * from table where id = ? lock in share mode select * from table where id < ? lock in share mode select * from table where id = ? for update select * from table where id < ? for update 如果你能清楚的说出，这六句sql在不同的事务隔离级别下，是否加锁，加的是共享锁还是排他锁，是否存在间隙锁，那这篇文章就没有看的意义了。 之所以写这篇文章是因为目前为止网上这方面的文章太片面，都只说了一半，且大多没指明隔离级别，以及 where 后跟的是否为索引条件列。在此，我就不一一列举那些有误的文章了，大家可以自行百度一下，大多都是讲不清楚。 OK，要回答这个问题，先问自己三个问题 当前事务隔离级别是什么 id列是否存在索引 如果存在索引是聚簇索引还是非聚簇索引呢？ OK，开始回答 正文 本文假定读者，看过我的 《MySQL(Innodb)索引的原理》 。如果没看过，额，你记得三句话吧 innodb一定存在聚簇索引

  锁主要是为了保持数据库数据的一致性，可以阻止用户修改一行或整个表，一般用在并发较高的数据库中。   在多个用户异步访问数据库时，如果不对其进行限制可能会出现读取数据和存储数据的不一致性。   数据库中有两种基本的锁： 共享锁 （SHARE）、 排它锁 （EXCLUSIVE）。 如果数据对象加上 排它锁 ，则其他的事务 不能 对它 读取 和 修改 。 如果加上 共享锁 ，则该数据库对象 可以 被其他事务 读取 ，但 不能修改 。   锁的基本语法：LOCK [ TABLE ] name IN lock_mode   即以某种模式去锁定某张表，lock_mode有ACCESS SHARE，ROW SHARE， ROW EXCLUSIVE， SHARE UPDATE EXCLUSIVE， SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE，ACCESS EXCLUSIVE等，具体格式可参考： Postgresql锁模式   获得锁之后，锁一般情况下都会继续保持，并且总是在事务结束时释放（包括事务提交和事务回滚）。   上述参考自菜鸟教程： PostgreSQL LOCK（锁）   上述介绍通常是用于表级锁，下面简单介绍一下行级锁。   与表级锁不同的是，行级锁不阻塞对于数据的查询，行级锁只是阻塞对同一行的写入。   要在不修改某行的前提下请求一个 排斥行级锁 ，用

MySQL中的锁 https://www.cnblogs.com/chenqionghe/p/4845693.html 锁是计算机协调多个进程或纯线程并发访问某一资源的机制。在数据库中，除传统的计算资源（CPU、RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所在有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。 概述 相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。 MySQL大致可归纳为以下3种锁： 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般 表级锁 MySQL表级锁有两种模式：表共享锁（Table Read Lock）和表独占写锁（Table Write Lock） 对MyISAM的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求 对MyISAM的写操作，则会阻塞其他用户对同一表的读和写操作 MyISAM表的读操作和写操作之间，以及写操作之间是串行的

分布式共享锁：InterProcessSemaphoreMutex完全分布的全局同步锁，意味着在任何快照时间，没有两个客户端认为他们拥有相同的锁，继承上一篇分布式锁-zookeeper的AbstractZookeeperLock。细节与注意事项请看 分布式锁-基于zookeeper客户端curator实现锁机制（一）锁基础 package com.miku.common.util.lock.zookeeper; import com.miku.common.util.lock.support.AbstractZookeeperLock; import org.apache.curator.framework.recipes.locks.InterProcessSemaphoreMutex; /** * 分布式共享锁 * * @author :panw. */ public class SharedLock extends AbstractZookeeperLock < InterProcessSemaphoreMutex > { private final String lockKey = "shared-lock" ; /** * Shared Lock * * 获取排他锁，阻塞直到可用，单实例{ @code InterProcessSemaphoreMutex} <br> *