参考链接：
http://www.digpage.com/lock.html
http://blog.csdn.net/hongchangfirst/article/details/26004335
乐观锁 (Optimistic Lock)
顾名思义，就是很乐观，假设数据一般情况下不会造成冲突，只有在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。一般使用数据版本、timespan来实现。
何谓数据版本？即为数据增加一个版本号。在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，并加1，提交更新时，先将待提交数据的版本号与数据库表中对应记录的版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
如：数据库的版本号是0， 读取0，然后加1，得到1.
提交的时候， 和数据库对比， 此时如果数据库中仍然是0， 则1>0， 可以更新， 如果库中版本号大于0， 则不允许更新。
乐观锁失效
乐观锁存在失效的情况，属小概率事件，需要多个条件共同配合才会出现。如：
- 应用采用自己的策略管理主键ID。如，常见的取当前ID字段的最大值＋1作为新ID。
- 版本号字段 ver 默认值为 0 。
- 用户A读取了某个记录准备修改它。该记录正好是ID最大的记录，且之前没被修改过， ver 为默认值 0。
- 在用户A读取完成后，用户B恰好删除了该记录。之后，用户C又插入了一个新记录。
- 此时，阴差阳错的，新插入的记录的ID与用户A读取的记录的ID是一致的， 而版本号两者又都是默认值 0。
- 用户A在用户C操作完成后，修改完成记录并保存。由于ID、ver均可以匹配上， 因此用户A成功保存。但是，却把用户C插入的记录覆盖掉了。
乐观锁此时的失效，根本原因在于应用所使用的主键ID管理策略， 正好与乐观锁存在极小程度上的不兼容。
悲观锁
悲观锁，正如其名，它指的是对数据被其他事务修改持悲观态度，因此，在事务A处理数据的过程中，一直将数据锁定，这样其他想拿这个数据就会block住，直到事务A放开锁。
悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）