概述
几乎所有的企业应用程序都有多个用户和后台线程，它们可以同时更新数据库。两个数据库处理事务同时访问同一份数据的情形很常见，但是这样很可能导致数据库的不一致，或者引起应用程序行为异常。
大部分应用程序必须处理多个事务并发访问同一份数据的情况，而这会影响业务层和表示层的设计。
悲观锁
你可以利用事务的隔离级别实现悲观锁，一般用“可重复读”和“串行化”就可以满足悲观锁的要求。
从表面上看，这种方法看似非常简单，但是这类事务也存在问题，由于隔离事务如何实现完全由平台或数据库提供，因此有时他们会导致性能降低，令人无法接受 。鉴于此，许多应用程序都避免使用这类事务，转而采用乐观锁。
乐观锁
处理并发更新的另一种方式是使用乐观锁。乐观锁的工作原理是让应用程序检查它即将更新的数据是否已经被另一个事务修改过。实现乐观锁的一种常见做法是在每个表里添加一个版本字段，每次应用程序更新数据表记录时就增加这个版本字段。每个UPDATE语句中的WHERE子句会根据上次读取的值来判断这个版本号是否发生改变。如果这条记录已被另外一个事务更新或删除，应用程序可以回滚这个事务，并重新开始。
基本上所有的数据库访问框架都会封装乐观锁功能，比如：EntityFramework和Nhibernate。
乐观锁的名称源自如下假定，即并发更新的几率极小，此外应用程序并不阻止并发更新，而是检测并发更新，并从并发更新中恢复过来。
悲观离线锁
悲观离线锁使用如下方式处理跨越一系列数据库事务的并发更新：在编辑过程开始之初，就锁定共享数据，以防止其他用户编辑共享数据。这种方式与之前描述的悲观锁机制类似，只不过这里的锁是由应用程序而不是数据库提供。
乐观离线锁
乐观离线锁使用如下方式处理跨越一系列数据库事务的并发更新：乐观离线锁扩展了此前描述的乐观锁机制，在编辑过程的最后一个数据库事务中，检查数据库自最初读取后没有被改变。
由于乐观离线锁只在用户要保存修改后的数据时才进行检测，因此只有当重新开始对用户来说不是负担时，这种模式才有效。
常用并发决策
| 决策 | 选项 |
| 在线并发策略 | 乐观锁 悲观锁（必要时） |
| 离线并发策略 | 乐观离线锁模式 悲观离线锁模式（必要时） |
博客资源
.NET：在线悲观锁、在线乐观锁、离线悲观锁、离线乐观锁代码示例
图书资源
《POJO IN ACTION》（该文章就是从这本书上抄袭的）
《企业应用架构模式》