JAVA高级面试进阶训练营视频教程

admin

　　“……老手根本就不会照着指示去做，他边做边取舍，因此必须全神贯注于手上的工作，即使他没有刻意这样做，他的动作和机器之间也自然有一种和谐的感觉。他不需要遵照任何书面的指示，因为手中的机器给他的感觉决定他的思路和动作，同时也影响他手中的工作。所以机器和他的思想同时不断地改变，一直到把事情做好了，他的内心才真正地安宁下来。”
　　“听起来好像艺术一样。”
　　　　　　　　　　　　　　　　　　——罗伯特·M.波西格 《禅与摩托车维修艺术》

　　如果没有任何数据库隔离策略，在多用户（多事务）并发时，会产生下列问题：
　　- 丢失更新（lost update）：两个事务同时更新同一条数据时，会发生更新丢失。
　　　　例如：用户A读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
　　　　=> 用户B读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
　　　　=> 用户A把姓名更改为“王小明”（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户B把年龄更改为33（学号=107，姓名=“小明”，年龄=33）
　　　　=> 用户A提交（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户B提交（学号=107，姓名=“小明”，年龄=33）
　　　　用户A对学生姓名的更新丢失了。
　　- 脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。
　　　　例如：用户A读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
　　　　=> 用户A把姓名更改为“王小明”（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户B读取学号为107的学生（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户A撤销更改，事务回滚（学号=107，姓名=“小明”，年龄=28）
　　　　这样用户B相当于读取了一个从未存在过的数据“王小明”。如果涉及到金额的话问题更为严重，因为用户B读取了一个金额之后，很可能把这个金额与其它金额累加，再把结果保存到汇总数据之中，这样在月底对不上账的时候，由于用户A回滚了事务，数据库内不会有任何操作记录，这样用户B是何时、从哪里读取了错误数据根本无从查起。
　　- 不可重现的读取（nonrepeatable read）：同一查询在同一事务中多次进行，在此期间，由于其他事务提交了对数据的修改或删除，每次返回不同的结果。
　　　　例如：假设学生表里只有“小明”和“小丽”2条记录（小明.年龄=20，小丽.年龄=30）。如果用户A把“小明.年龄”更改为40、把“小丽.年龄”更改为50并提交事务。在用户A修改数据并提交前，学生的平均年龄为(20+30)/2=25；在用户A修改数据并提交后，学生的平均年龄为(40+50)/2=45。
现在考虑在用户A更新 2 名学生的年龄时，用户B执行了一个计算平均年龄的事务：

如前所述，在用户A修改数据并提交前，学生的平均年龄为(20+30)/2=25；在用户A修改数据并提交后，学生的平均年龄为(40+50)/2=45。用户B计算得出的平均年龄是 25 或 45 都是可以接受的，但是在上例中用户B计算得出的平均年龄 35 是从未出现在系统中的错误数值。
　　- 幻读（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，虽然查询条件相同，每次返回的结果集却不同。

事务B使用相同的条件进行了2次查询/筛选，一次是为了向费用结算表插入汇总数据，一次为了确定对费用明细表的更新范围。在这两次筛选之间，事务A提交了一条新的费用明细数据，导致两次筛选的结果不一致。

隔离级别

　　为避免上述并发问题，ANSI/ISO SQL92标准定义了一些隔离级别：

　　- 读取未提交数据（read uncommitted）

　　- 读取已提交数据（read committed）

　　- 可重现的读取（repeatable read）

　　- 序列化（serializable）

通过指定不同的隔离级别，可避免上述一种或多种并发问题，见下图。

细心的读者可能已经注意到上图不包括“丢失更新（lost update）”，这是因为“丢失更新”问题需要使用乐观锁或悲观锁来解决，超出本文范围，先不详述。

Oracle 的隔离级别

　　SQL92定义的隔离级别在理论上很完善，但是 Oracle 显然认为在实际实现的时候并不应该完全照搬SQL92的模型。 
　　- Oracle不支持 SQL92 标准中的“读取未提交数据（read uncommitted）”隔离级别，想要脏读都没可能。
　　- Oracle 支持 SQL92 标准中的“读取已提交数据（read committed）”隔离级别，（这也是Oracle默认的隔离级别）。
　　- Oracle不支持 SQL92 标准中的“可重现的读取（repeatable read）”隔离级别，要想避免“不可重现的读取（nonrepeatable read）”可以直接使用“序列化（serializable）”隔离级别。
　　- Oracle 支持 SQL92 标准中的“序列化（serializable）”隔离级别，但是并不真正阻塞事务的执行（这一点在后文还有详述）。
　　- Oracle 还另外增加了一个非SQL92标准的“只读(read-only)”隔离级别。

Oracle的序列化（serializable）隔离级别

　　序列化，顾名思义，是让并发的事务感觉上是一个挨一个地串行执行的。之所以说是“感觉上”，是因为当2个事务并发时，Oracle并不会阻塞其中一个事务去等待另一个事务执行完毕再执行，而是仍然让2个事务同时并行，那么如何能“感觉”是串行的呢？请看下图的实验。

用户B的事务因为指定了serializable隔离级别，所以虽然在查询费用明细表之前，用户A提交了对费用明细表的更改，但是因为用户A提交的更改是在用户B的事务开始之后才提交的，所以这个更改对用户B的事务不可见。也就是说，用户B的事务开始之后，其它事务提交的更改都不会再影响事务内的查询结果，这样感觉上用户A的事务好像是在用户B的事务结束之后才执行的似的。这本来是非常好的一个特性，极大地提高了并行性，但是也会造成问题。

　　问题1：Oracle的这种“假串行”会让严格依赖于时间的程序产生混乱。

　　请看下图这个例子，对费用结算的例子稍稍做了一点改动。

程序员的本意是统计2012-3-4这天从零点至运行程序之时的费用总额。如果他以为 Oracle 的 serializable 会像 C# 的 lock 一样阻塞其它事务的话，就会对结果非常吃惊：在2012-3-4 0:00 ~ 2012-3-4 10:02 实际有3条费用明细，总额为20+30+100=150，而不是用户B的事务统计得出的50。

　　问题2：ORA-08177 Can't serialize access for this transaction (无法序列化访问)错误。

　　如果你使用了 serialize 隔离级别，没准你的客户会经常抱怨这个随机出现的错误。兄弟，你并不孤独！
　　导致这个错误的原因有2个：
　　(1) 两个事务同时更新了同一条数据。你可以这样重现这个错误：事务B开始（使用serialize 隔离级别) => 事务A开始，更新 表1.RowA 但不提交 => 事务B更新表1.RowA，因为行锁定而被阻塞 => 事务A提交 => 事务B报 ORA-08177 错误。
　　(2) 事务所更新的表的 initrans 参数太小。Oracle 官方文档的说法是，如果使用了 serialize 隔离级别，表的 initrans 参数最小要设置成3（默认是1）。

alter table 费用明细表 initrans 3;

　　原文：“Oracle Database stores control information in each data block to manage access by concurrent transactions. Therefore, if you set the transaction isolation level to SERIALIZABLE, then you must use the ALTER TABLE command to set INITRANS to at least 3. This parameter causes Oracle Database to allocate sufficient storage in each block to record the history of recent transactions that accessed the block. Higher values should be used for tables that will undergo many transactions updating the same blocks.”
　　注意，人家说的是“最小是3”。我用自己笔记本里的 32 位 Oracle10g 测试的结果是设置成 3 也会频繁地报 ORA-08177 错误。后来改成5 和 10，都不行。改成50，终于不报错了。但是都说了这个错误是随机的，有时候3也没问题的——反过来说，设置成50也未必保险。坑爹啊！真坑爹！！这就像菜谱里面写的“放入适量的油……”，他喵的到底多少算是“适量”啊？！！！
　　有兴趣的读者可以使用下图的语句实际测试一下。

　　我的建议是，还是尽量不要用 serialize 隔离级别吧，用户是不会理解什么叫“无法序列化访问”的，他只会觉得你的“XX功能会随机地不好用”倒是真的。稍后我们再简单讨论一下不用 serialize 隔离级别如何避免幻读。现在先来看一下 Oracle 官方文档建议的适合使用 serialize 隔离级别的3种情况。

　　(1) With large databases and short transactions that update only a fewrows（大数据库、只更新几条数据的短事务）

　　(2) Where the chance that two concurrent transactions will modify thesame rows is relatively low（2个并发事务更新同一条数据的几率不大）

　　(3) Where relatively long-running transactions are primarily read only（相对运行时间较长的事务主要用来读取数据）

使用默认的 read committed 隔离级别，如何避免幻读产生的问题

　　使用默认的 read committed 隔离级别，如何编写程序才能避免幻读产生的问题呢？首先，无论是“不可重现的读取（nonrepeatable read）”还是“幻读（phantom read）”，都是因为程序反复读取数据产生的。所以首先需要做的是，在一个事务里确保只读取数据一次。最好用C#而不是存储过程实现业务逻辑，这样很容易做到只读取一次，然后把结果存放到IList或IDictionary里。比较难办的是需要更新数据的情况。回顾一下前面所举的幻读的例子。

事务B使用相同的条件进行了2次查询/筛选，一次是为了向费用结算表插入汇总数据，一次为了确定对费用明细表的更新范围。在这两次筛选之间，事务A提交了一条新的费用明细数据，导致两次筛选的结果不一致。要避免这个问题，还是要贯彻“只读取一次”的原则，或者更广义地说，是“只确定一次筛选范围”。大致有2种方法。
　　<法一> 可以先把符合条件的费用明细读取出来保存到一个列表里，然后无论统计还是更新，都局限于这个列表里的数据。下面的C#代码与上图的功能相同，但是没有幻读的问题。

// 用户B的事务开始

IList<费用明细> chargeList = 费用明细Repository.获取未结算列表();
费用结算 balance = new 费用结算 
{
    总金额 = chargeList.Sum(t => t.金额),
    结算编号 = "J122"
};
费用结算Repository.Save(balance);

// 这时候用户A提交了一条新的费用明细，不过没关系

foreach(费用明细 charge in chargeList)
{
    charge.是否已结算 = 1;
    charge.结算编号 = "J122";
    费用明细Repository.Update(charge);
}

这个方法的缺点是要对 chargeList 里的每个实体 Update 一次，如果数据量较大可能会有性能问题。这时候可以用<法二>。
注 本文为了表述的方便使用了中文和英文混杂的代码，实际编程的时候不要这样做。
　　<法二> 使用事务B独有的方法标识出操作数据的范围。

注 虽然上图是用SQL语句来演示的，使用C#（实体+ORM）同样可以用这种方法。

严格依赖时间的程序

严格来说这并不是幻读造成的问题——事务A还没提交呢。这种设计十分危险，无论使用 read committed 还是 serializable 隔离级别都不足以避免并发造成的不一致，应该尽量避免这样的设计。依赖时间很危险，因为系统时间是随时可能被系统管理员更改的，更别提有些国家和地区会实行夏时制，想想看，事务B提交了之后，系统时间被回拨了1小时！
　　然而世事往往不尽如人意，你可能不幸遇到了这样一个遗留系统，或者用户有很多其它的业务或与你交互的系统严格依赖于时间而逼得你不得不这么做的时候，该怎么办呢？
　　<法一> 在业务逻辑层面，可以把用户B和用户A的两个方法使用C#提供的线程同步技术串行化——理论上行的通，但是操作费用明细实体的方法那么多，很容易有所遗漏。
　　<法二> 在Repository层面，为费用明细实体设置一个令牌，并且可以设置是否进入令牌模式。在令牌模式下，费用明细Repository里面的所有持久化操作都必须拿到令牌才能操作，拿不到令牌直接抛异常。平时的业务操作都在非令牌模式下工作。在用户B想要进行结算操作时，事务开始之后，马上设置成令牌模式，然后获取令牌，这样就能确保此时只有用户B才能操作费用明细表了。此法虽然并发性很差，但是既简单又保险。而且很多时候像结算这样的操作一个月（或一天）只进行一次，并发性差一些也可以忍受。值得注意的是下面这种情况。

虽然发生的概率不高，但是让令牌法彻底失效了。综合考虑系统时间被管理员改变的可能性，仅仅在结算事务里独占令牌也是不够的，还必须在费用明细Repository.Save()方法里验证费用明细.创建时间必须大于最近一次的结算时间。