DB2里那个乐观锁定的新玩意儿，感觉挺有意思，性能啥的可能会变好吧

行,那咱们就直接聊聊DB2里这个“乐观锁定”的新玩意儿，这事儿得从处理很多人同时改数据的老大难问题说起。

以前的老办法,悲观锁定”，就像个特别小心谨慎的图书管理员，你一说要借某本热门书（修改数据），他立马就把书从书架上抽走，锁进自己的抽屉里，在你把书还回来（提交事务）之前，其他所有人都只能干等着，眼巴巴地看着空书架，这种方法保证了你肯定能借到书（不会有人跟你抢），但代价是别人都得排队，系统整体速度就慢下来了，尤其是在人特别多（高并发）的时候。

DB2现在更推崇的这个“乐观锁定”，思路就完全不一样了，这个管理员变得很“乐观”，他觉得大部分时候不会那么巧，正好有好几个人同时要改同一本书，你借书的时候，他根本不会锁抽屉，他会大方地让你把书拿走，同时偷偷拿个小本本记下这本书当前的版本号（比如是第3版），等你回来还书的时候，他会先检查一下这本书的版本号还是不是他记下的那个“第3版”。

• 如果还是第3版，说明在你借走的这段时间里，没人动过这本书，管理员很开心，觉得世界果然如他所料般和谐，他痛快地收下你的书，完成归还操作，并且把小本本上的记录更新成“第4版”。
• 但如果他发现书变成了第4版（甚至第5版），那就坏事了，说明在你借走之后，已经有别人抢先一步把书还回来又借出去了一次（数据被其他事务修改了），这时候管理员就不会接受你的这次归还操作了，他会告诉你：“对不起，你手里的版本太旧了，有冲突，你得重新看看现在这本新书是啥样，再决定要不要借。”

这个过程,就是DB2里乐观锁定的核心，它默认冲突很少发生，所以它在读取数据的时候不加锁，大家都可以随便读，这极大地提高了系统的并发读取能力，只在最后真要更新数据的那一刻，才去检查一下数据版本有没有变化。

那DB2具体是怎么实现这个“版本检查”的呢？主要有两种招数：

第一招，靠一个专门的版本号字段。 这是最经典的办法，就是在需要做乐观锁定的表里，额外加一个字段，比如叫 VERSION 或者 UPDATE_TIMESTAMP，每次成功更新一条数据后，DB2都会自动把这个版本号字段的值加1，或者更新成当前最新的时间戳，当你发起更新时，你的SQL语句得这么写：“帮我更新这条数据，但前提是它的版本号必须还是我当初读出来的那个值（123）。” DB2在执行时，会去核对这个条件，如果匹配，就更新数据同时递增版本号；如果不匹配，就说明这条数据已经被别人改过了，你的更新会失败，DB2会抛出一个错误告诉你发生了“更新冲突”。

第二招，利用DB2自身的数据行变化信息。 这个方法更隐蔽，不需要你改表结构加字段，DB2内部其实会为每一行数据维护一些控制信息，当你用类似 SELECT ... FOR UPDATE WITH RS USE AND KEEP EXCLUSIVE LOCKS 这样的语句（这是一种悲观锁的方式）时，它会上锁，但如果是乐观模式，DB2可以利用这些内部信息来判断数据行自你读取后是否被更改，其本质和版本号是一样的，只是这个“版本号”由DB2在后台默默管理，对你是透明的。

这么搞，性能真的能变好吗？

在正确的场景下，答案是肯定的，而且提升会非常明显。

最大的好处就是“读不加锁”，想象一下一个新闻网站，成千上万人同时在浏览文章（读操作），只有极少数编辑在更新文章（写操作），用悲观锁的话，每个读者浏览时都可能（取决于隔离级别）加个共享锁，虽然不阻塞其他读者，但可能会等着写锁释放，或者阻塞写操作，而用乐观锁，所有读者都可以毫无阻碍地瞬间读到数据，系统吞吐量会飙升。

它也不是万能药,有很明显的“副作用”：

1. 冲突处理变麻烦了：悲观锁下，你基本不会遇到“更新冲突”，因为别人根本没法跟你同时改，但乐观锁下，冲突是被允许发生的，一旦发生，你的应用程序必须能优雅地处理这个错误，常见的做法是：捕获这个冲突异常，然后重新执行整个“读取-计算-更新”的流程，如果冲突非常频繁，反复重试反而会比简单的悲观锁性能更差。
2. 适用场景有讲究：乐观锁定最适合的是那种读非常多，写相对较少，并且写操作之间的冲突概率本身就很低的系统，比如论坛回帖、更新用户个人资料等，相反，像机票订票、秒杀商品这种，对同一条数据（比如剩余票数）的争用极其激烈，用乐观锁会导致大量更新失败和重试，可能还不如用悲观锁直接排队来得直接有效。

（根据IBM官方文档关于DB2并发控制及乐观锁定技术的说明）DB2提供这种机制，其实就是给了开发者一个更灵活的选择，它把“是否会发生冲突”这个赌注交给了应用程序的设计者，如果你赌对了（业务场景确实冲突少），就能用很小的代价换来并发性能的大幅提升，这需要你对自家的业务数据访问模式有很清晰的认识。

DB2里这个乐观锁定的新玩意儿,不是什么高深莫测的黑科技，而是一种“以空间换时间”（可能增加一个版本字段）或者说“以风险换吞吐量”的巧妙设计，用对了地方，它就是性能加速器；用错了场合，反而会添乱，关键就在于，你得看清楚自己的应用到底是个“谦谦君子林”，还是“修罗竞技场”。