关于共享锁，排它锁，乐观锁，悲观锁

转自：http://blog.csdn.net/yuwei19840916/article/details/3245107

共享锁【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。

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了不少这种锁机制，好比行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。

 

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，因此不会上锁，可是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可使用版本号等机制。乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库若是提供相似于write_condition机制的其实都是提供的乐观锁。

 

两种锁各有优缺点，不可认为一种好于另外一种，像乐观锁适用于写比较少的状况下，即冲突真的不多发生的时候，这样能够省去了锁的开销，加大了系统的整个吞吐量。但若是常常产生冲突，上层应用会不断的进行retry，这样反却是下降了性能，因此这种状况下用悲观锁就比较合适。

深刻理解乐观锁和悲观锁：

在数据库的锁机制中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。

乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。

不管是悲观锁仍是乐观锁，都是人们定义出来的概念，能够认为是一种思想。其实不只仅是数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有相似的概念。

针对于不一样的业务场景，应该选用不一样的并发控制方式。因此，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库自己提供的锁机制来实现的。

悲观锁：

在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它能够阻止一个事务以影响其余用户的方式来修改数据。若是一个事务执行的操做都某行数据应用了锁，那只有当这个事务把锁释放，其余事务才可以执行与该锁冲突的操做。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其余事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，所以，在整个数据处理过程当中，将数据处于锁定状态。 悲观锁的实现，每每依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，不然，即便在本系统中实现了加锁机制，也没法保证外部系统不会修改数据）

悲观锁的流程：

在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。

若是加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际须要决定。

若是成功加锁，那么就能够对记录作修改，事务完成后就会解锁了。

其间若是有其余对该记录作修改或加排他锁的操做，都会等待咱们解锁或直接抛出异常。

悲观锁的优点与不足：

悲观并发控制其实是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。可是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增长产生死锁的机会；另外，在只读型事务处理中因为不会产生冲突，也不必使用锁，这样作只能增长系统负载；还有会下降了并行性，一个事务若是锁定了某行数据，其余事务就必须等待该事务处理完才能够处理那行数

乐观锁：

在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务可以在不产生锁的状况下处理各自影响的那部分数据。在提交数据更新以前，每一个事务会先检查在该事务读取数据后，有没有其余事务又修改了该数据。若是其余事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最先是由孔祥重（H.T.Kung）教授提出。

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据通常状况下不会形成冲突，因此在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，若是发现冲突了，则让返回用户错误的信息，让用户决定如何去作。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。通常的实现乐观锁的方式就是记录数据版本。

数据版本,为数据增长的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当咱们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，若是数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，不然认为是过时数据。

实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。

乐观锁的优点与不足：乐观并发控制相信事务之间的数据竞争(data race)的几率是比较小的，所以尽量直接作下去，直到提交的时候才去锁定，因此不会产生任何锁和死锁。但若是直接简单这么作，仍是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，通过修改之后写回数据库，这时就遇到了问题。