事务隔离级别温习
脏读
一个事务读取到了另一个事务未提交的数据操作结果。这个未提交的事务有可能被回滚。
不可重复读
一个事务对同一行数据重复读取两次，但是却得到了不同的结果。
包括以下情况：
（1） 事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。
（2） 幻读（Phantom Reads）：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据（这里并不要求两次查询的SQL语句相同）。这是因为在两次查询过程中有另外一个事务插入数据造成的。
读未提交 如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。
读已提交 一个 SELECT 查询只能看到查询开始之前提交的数据，而无法看到未提交的数据或者是在查询执行时其他并行的事务提交做的改变。
可重复读取（Repeatable Read） 读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
序列化（Serializable） 它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。
| 脏读 | 不可重复读 | 幻读 | ||
| 未锁定 | 读未提交（Read uncommitted） | 可能 | 可能 | 可能 |
| 锁定1行 | 读已提交（Read committed） | 不可能 | 可能 | 可能 |
| 锁定几行 | 可重复读（Repeatable read） | 不可能 | 不可能 | 可能 |
| 锁定了表 | 可串行化（Serializable ） | 不可能 | 不可能 | 不可能 |
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。[因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，并发性能不好。
实现方式：
Select * from Account where ...(where condition).. for update. 当使用了for update语句后，每次在读取或者加载一条记录的时候，都会锁住被加载的记录，那么当其他事务如果要更新或者是加载此条记录就会因为不能获得锁而阻塞，这样就避免了不可重复读以及脏读的问题，但是其他事务还是可以插入和删除记录，这样也许同一个事务中的两次读取会得到不同的结果集，但是这不是悲观锁锁造成的问题，这是我们数据库隔离级别所造成的问题。
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。
实现方式： 大多是基于数据版本 （ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提 交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 假如系统中有一个Account的实体类，我们在Account中多加一个version字段，那么我们JDBC Sql语句将如下写： Select a.version....from Account as a where (where condition..)
Update Account set version = version+1.....(another field) where version =?...(another contidition) 这样以来我们就可以通过更新结果的行数来进行判断，如果更新结果的行数为0，那么说明实体从加载以来已经被其它事务更改了，所以就抛出自定义的乐观锁定异常（或者也可以采用Spring封装的异常体系）。
int rowsUpdated = statement.executeUpdate(sql);
If(rowsUpdated= =0){
throws new OptimisticLockingFailureException();
}
在使用JDBC API的情况下，我们需要在每个update语句中，都要进行版本字段的更新以及判断，因此如果稍不小心就会出现版本字段没有更新的问题，相反当前的 ORM框架却为我们做好了一切，我们仅仅需要做的就是在每个实体中都增加version或者是Date字段。