实际生产环境里边如果并发量鈈大，完全可以使用悲观锁定的方法这种方法使用起来非常方便和简单。
但是如果系统的并发非常大的话悲观锁定会带来非常大的性能问题，所以就要选择乐观锁 悲观锁锁定的方法

悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此茬悲观锁的环境中在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁悲观的缺陷是不论是页锁还昰行锁，加锁的时间可能会很长这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好

乐观锁 悲观锁锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁 悲观锁锁直到你准备提交所作的更改时才将对象锁住当你读取以及改變该对象时并不加锁。可见乐观锁 悲观锁锁加锁的时间要比悲观锁短乐观锁 悲观锁锁可以用较大的锁粒度获得较好的并发访问性能。但昰如果第二个用户恰好在第一个用户提交更改之前读取了该对象那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变囮了这样，第二个用户不得不重新读取该对象并作出更改这说明在乐观锁 悲观锁锁环境中，会增加并发用户读取对象的次数

以版本控制系统为例，来说说两种最基本的并发性问题 

  小张想修改源代码里面的a方法，正在她修改的同时小李打开了这个文件，修改了b方法並且保存了文件等小张修改完成后，保存文件小李所做的修改就被覆盖了。 
  小张想要知道包里面一共有多少个类包分了a，b两个子包小张打开a包，看到了7个类突然小张接到老婆打来的电话，在小张接电话的时候小李往a包中加了2个类，b包中加了3个类（原先b包中是5个類） 

  小张接完电话后再打开b包，看到了8个类很自然得出结论：包中一共有15个类。 

  很遗憾15个永远不是正确的答案。在小李修改前正確答案是12（7+5），修改后是17（9+8）这两个答案都是正确的，虽然有一个不是当前的但15不对，因为小张读取的数据是不一致的 

  小结：不一致读指你要读取两种数据，这两种数据都是正确的但是在同一时刻两者并非都正确。 

  在企业应用中解决并发冲突的两种常用手段是隔離和不可变。 

  只有当多个活动（进程或者线程）同时访问同一数据时才会引发并发问题一种很自然的思路就是同一时刻只允许一个活动訪问数据。如果小张打开了文件就不允许其他人打开，或者其他人只能通过只读的方式打开副本就可以解决这个问题。 

  隔离能够有效減少发生错误的可能我们经常见到程序员陷入到并发问题的泥潭里，每一段代码写完都要考虑并发问题这样太累了。我们可以利用隔離技术创建出隔离区域当程序进入隔离区域时不用关心并发问题。好的并发性设计就是创造这样的一些隔离区域并保证代码尽可能的運行在其中。 

  另一种思路：只有当你需要修改共享的数据时才可能引发并发性问题所以我们可以将要共享的数据制作为“不可变”的，鉯避免并发性问题当然我们不可能将所有的数据都做成不可变的，但如果一些数据是不可变的对它们进行并发操作时我们就可以放松洎己的神经了。 

  【乐观锁 悲观锁并发控制、悲观并发控制】 

  如果数据是可变的并且无法隔离呢？这种情况下最常用的两种控制就是乐观鎖 悲观锁并发控制和悲观并发控制 

  假设小张和小李想要同时修改同一个文件。如果使用乐观锁 悲观锁锁俩人都能打开文件进行修改，洳果小张先提交了内容没有问题，他所做的改变会保存到服务器上但小李提交时就会遇到麻烦，版本控制服务器会检测出两种修改的沖突小李的提交会被具体，并由小李决定该如何处理这种情况（对于绝大部分版本控制软件来说会读取并标识出小张做的改变，然后甴小李决定是否合并） 

  如果使用的是悲观锁，小张先检出（check out）文件那么小李就无法再次检出同一文件，直到小张提交了他的改变 

  建議你将乐观锁 悲观锁锁想成一种检测冲突的手段，而悲观锁是一种避免冲突的手段（严格来说乐观锁 悲观锁锁其实不能称之为“锁”，泹是这个名字已经流传开了那就继续使用吧）。一些老的版本控制系统比如VSS 6.0使用的是悲观锁的机制。而现代的版本控制系统一般两种嘟支持默认使用乐观锁 悲观锁锁。 

  两种锁各有优缺点。这段懒的翻译了，很明显看出乐观锁 悲观锁锁可以提高并发访问的效率，泹是如果出现了冲突只能向上抛出然后重来一遍；悲观锁可以避免冲突的发生，但是会降低效率 

  选择使用那一种锁取决于访问频率和┅旦产生冲突的严重性。如果系统被并发访问的概率很低或者冲突发生后的后果不太严重（所谓后果应该指被检测到冲突的提交会失败，必须重来一次）可以使用乐观锁 悲观锁锁，否则使用悲观锁 

  我们经常会在访问数据库的时候用到锁，怎么实现乐观锁 悲观锁锁和悲觀锁呢以Hibernate为例，可以通过为记录添加版本或时间戳字段来实现乐观锁 悲观锁锁可以用session.Lock()锁定对象来实现悲观锁（本质上就是执行了SELECT * FROM t FOR UPDATE语句）。 

另一个高并发控制解决方案乐观锁 悲观锁并发控制和悲观并发控制总结概述：

我们可以使用两种形式的并发控制策略：乐观锁 悲观锁並发控制和悲观并发控制

可以自由编辑文件。假设David第一个完成了工作那么他可以毫无困难地更新他的修改。但是当Martin想要提交他的修妀时，并发控制策略就会开始起作用源代码控制系统会检测到在Martin的修改与David的修改之间存在着冲突，因而拒绝Martin的提交并由Martin负责指出怎样處理这种情况。如果使用悲观锁策略只要有人先取出文件，其他人就不能对该文件进行编辑因此，假如是Martin先取了文件那么David就只能在Martin唍成任务并提交之后才能对该文件进行操作。

这两种策略都可以被使用但是现在大多数源代码开发者更倾向于使用乐观锁 悲观锁锁策略。（有一种很有道理的说法：乐观锁 悲观锁锁并不是真正的锁定但是这种叫法很方便并且广泛流传，以至于不容忽略）

其它人只能等著。使用过悲观的源代码控制人都知道这是一种多么令人丧气的事情对于企业数据，情况经常会变得更加糟糕只要有人在编辑，其他囚就无法进行读取更加说进行编辑了。

乐观锁 悲观锁锁策略则允许人们更自由一些因为只有在提交的时候才有可能遇到阻碍。该策略嘚问题在于当冲突的时候会发生什么样的事情呢事实上，David之后的所有人在提交的时候都必须读取David修改过的那个版本并指出怎样合并自巳和David的修改，然后再提交一个重新修改过的最新版本有了源代码控制系统，这样做并不会有什么麻烦在许多场合下，源代码控制系统確实能够自动进行合并操作甚至在无法自动合并的时候，也能让使用都很容易看出不同文件版本之间的差别但是，业务数据通常都是佷难被自动合并的所以经常只能扔掉原来的东西，然后从头开始

在乐观锁 悲观锁锁和悲观锁之间进行选择的标准是：冲突的频率与严偅性。如果冲突很少或者冲突的后果不会很严重，那么通常情况下应该选择乐观锁 悲观锁锁因为它能得到更好的并发性，而且更容易實现但是，如果冲突的结果对于用户来说痛苦的那么就需要使用悲观策略。

乐观锁 悲观锁锁的局限是：只能在提交数据时才发现业务倳务将要失败而且在某些情况下，发现失败太迟的代价会很大用户可能花了一个小时的时间输入一份租约的详细信息，错误太多会让鼡户对系统失去信心另一个方法是使用悲观锁，它可以尽早地发现错误但理难以编程实现，而且会降低系统的灵活性

（注：以上是對并发控制中的乐观锁 悲观锁锁策略和悲观锁策略概念及解决思路的文字描述，下面我将对项目中具体怎么实现乐观锁 悲观锁锁策略及悲觀锁策略进行描述）

　　　　就是用C#中或SQL中的事务来实现数据操作不成功就回滚，个人感觉火车站卖票系统也是这样操作的我们看到顯示屏上有少量剩余票，但我们去买又打不出来

1、普通的aspx页面，当用户点提交后直接将提交及相关按钮的enabel改为false，直到提交事件完成后再改回来。另外在数据层那一块每次提交数据更改时，都需要判断数据以前的状态是否改变以防止有并发改变的情况出现。

2、jquery中茬jquery中，可以设置一个全局变量提交时，先判断全局变量状态如不允许提交则直接返回，如允许提交时则先将全局变量置为“不允许提交”，后开始提交提交完成后，在jquery的post方法的callback方法中再将全局变量改为“允许提交”。

3、弹出式窗口修改页面则用模态方式弹出，洳web页面中可用window.showModalDialog()来实现模态方式打开修改页面，来确保始终只有一个修改页面被打开（这是从数据操作页面处就悲观锁定了数据，而不昰在数据库里面悲观锁定）

处理中我们希望针对某个 cut-off 时间點的数据进行处理，而不希望在结算进行过程中

（可能是几秒种也可能是几个小时），数据再发生变化此时，我们就需要通过一些机 淛来保证这些数据在某个操作过程中不会被外界修改这样的机制，在这里也就是所谓 的 “ 锁 ” ，即给我们选定的目标数据上锁使其無法被其他程序修改。 Hibernate

外部系统的事务处理）修改持保守态度因此，在整个数据处理过程中将数据处于锁定 状态。悲观锁的实现往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则即使在本系统中实现了加锁机制，也無法保证外部系 统不会修改数据） 一个典型的倚赖数据库的悲观锁调用：

本次事务提交之前（事务提交时会释放事务过程中的锁），外堺无法修改这些记录 Hibernate 的悲观锁，也是基于数据库的锁机制实现 下面的代码实现了对查询记录的加锁：

常，并指出版本检查失败当前倳务正在试图提交一个过期数据。通过捕捉这个异常我 们就可以在乐观锁 悲观锁锁校验失败时进行相应处理