数据库事务隔离与锁机制
1.事务有ACID 四个特性。 最难对付的是C I 即一致性和隔离性。  至于原子性和持久性好办。
2. 可能存在的三个问题是 脏读， 不可重读， 和幻读（虚读）
3。有四个隔离级别从低到高分别是：

   读未提交  |  READ UNCOMMITTED: 三个问题同时存在。

   读已提交  | READ COMMITTED:  解决了脏读问题。存在不可重读， 和幻读问题。

   可重复读  | REPEATABLE READ:存在幻读问题。但实际上很多数据库在这个级别都有自己的实现效果，
   并不是完全按SQL制定的标准实现的，我知道的 Mysql 默认就是这个级别的隔离，但也没有幻读问题。
   SQL Server类似。但是有一点要注意了虽然一个事务在两次读数据时保持一致， 但也只是一个可见性
   的问题，就是说另外的事务在这期间是可以对同一条数据做修改并提交的，这时数据已经更新到DB，只
   是先头这个事务没有读到而已。 解决办法除非是将隔离级别再升级到最高SERIALIZABLE ，这时在读记
   时是会锁定对应的记录的，其它事务不能对其修改的， 但是读永远都是可以的。  此时相当于在数据库
   上加了悲观锁， select * from where id = 2 for update;


   序列化    | SERIALIZABLE: 最高的隔离级别，没有任何并发修改的问题，但是会长时间锁住记录，可能
   是锁住整个表（select * from tb 不加where 条件的查询），性能太差，可能会造成死锁的。


建议你将乐观锁想成一种检测冲突的手段，而悲观锁是一种避免冲突的手段（严格来说，乐观锁其实不能
称之为“锁”，但是这个名字已经流传开了，那就继续使用吧）。一些老的版本控制系统，比如VSS   6.0
使用的是悲观锁的机制。而现代的版本控制系统一般两种都支持，默认使用乐观锁。
     
两种锁各有优缺点。。。很明显看出，乐观锁可以提高并发访问的效率，但是如果出现
了冲突只能向上抛出，然后重来一遍；悲观锁可以避免冲突的发生，但是会降低效率。

 

选择使用那一种锁取决于访问频率和一旦产生冲突的严重性。如果系统被并发访问的概率很低，或者冲突
发生后的后果不太严重（所谓后果应该指被检测到冲突的提交会失败，必须重来一次），可以使用乐观锁，
否则使用悲观锁。以Hibernate为例，可以通过为记录添加版本或时间戳字段来实现乐观锁。
可以用session.Lock()锁定对象来实现悲观锁（本质上就是执行了SELECT   *   FROM   t   FOR   UPDATE语句）。