1.问题场景
a. 用户A打开应用的界面，看到数据库的某条记录
b.用户B打开应用的界面，看到同样一条记录
c. 用户A对记录做了修改
d. 对于web应用而言[假设没有应用comet类似技术]，通常B不知道这个修改，这时B也对同样这条记录做修改，那B就有可能覆盖A做的修改;
这个问题在数据库中被称为丢失更新问题
2.我自己对这个问题的理解过程是这样的：
a. 不知道这个问题
我在做开发好长时间之后才意识到这个问题，意识到这个问题之后，我后来发现很长一段时间内都没真正搞明白为什么这是个问题-_- 而且我发现现在周围的很多同事，尤其是新毕业的学生，其实也一直过了很长时间都没明白这个问题，这说明吧不知道这个丢失更新问题是一个非常普遍的问题：)
b.用信号量以及操作之前再次验证的方法解决
最开始的时候，测试发现了这样一个问题，要求解决，我把操作系统的教科书搬来，对照着写了一个信号量semaphore类[那时候还是jdk 1.4.2，jdk里面没有concurrent包]，花了好长时间测试这个semaphore的实现是正确的[重复发明*的血泪史..]，
然后用来控制这个操作，每次操作前获取信号量，然后验证，再做真正的数据库操作。。。相当于在应用层每次都只做一件事。
c. 再次理解
再后来，我看了Tom的这本9i和10g的书，书中提到前面的丢失更新过程，大概有点明白为什么这是个问题
但是其实我有个疑问，对于数据库中的记录而言，A做的修改本来就有可能被B覆盖的，为什么这会是一个丢失更新问题呢? 正好项目里面又出现了类似的情况，我仔细观察了下，终于明白为什么这是个问题，以及为什么要使用对应的乐观锁悲观锁方案了。下面对此做详细说明
3. 一个比较清楚的场景
下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题：
假设当当网上用户下单买了本书，这时数据库中有条订单号为001的订单，其中有个status字段是’有效’,表示该订单是有效的;
后台管理人员查询到这条001的订单，并且看到状态是有效的
用户发现下单的时候下错了，于是撤销订单，假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;
后台管理人员由于在b这步看到状态有效的，这时，虽然用户在c这步已经撤销了订单，可是管理人员并未刷新界面，看到的订单状态还是有效的，于是点击”发货”按钮，将该订单发到物流部门，同时运行类似如下SQL，将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001
如果当当的系统这样实现，显然不对了，肯定要挨骂了，明明已经取消了订单，为什么还会发货呢?而且确实取消订单的操作发生在发货操作之前啊。 因为在这样的实现下，后台管理人员无论怎么做都有可能会出错，因为他打开系统看到有效的订单和他点发货之间肯定有个时间差，在这个时间差的时候总是存在用户取消订单的可能。
4. 当时的详细解决方法。几年前当测试人员告诉我系统存在这个问题的时候，我的解决方法是这样的， 首先，先把操作系统的教科书搬来，然后对照着了一个semaphore,然后反复测试各种情况证明写的是正确的; 然后，
1. 获取一个信号量，保证每次只能有一个线程进入下面的步骤
2. 检查数据库，看这条订单是否状态是有效的
a. 如果有效则继续，进入发货步骤 b) 如果无效则返回，释放信号量，告诉用户状态已经发生改变
3. 发货，释放信号量
看到这里，也许很多人要骂我蠢了，直接把SQL语句改成下面这样吧就可以了么? update order_table set status = ‘已发货’ where order_id = 001 and status = ‘有效’ 是的，的确是这样。虽然我当时的项目的情况比和这个稍微复杂一点，涉及到多张表格，不能直接这么做，但当时的确不知道这个更新丢失问题，也没想到合适的类似方式，于是就在应用层做了这么一个每次实际上只能有一个用户在做真正的更新这样一个方式来解决，这样做的结果是，在应用层单独做了类似这么一个锁的机制。我记得当时的项目毕业答辩的时候，老师问我同步的这个问题不直接用数据库的锁的方案来解决?我当时胡乱回答了下，后来想起来，其实压根没理解老师的意思-_- 而且这样做有一个问题，假设在特殊情况下，这条订单被DBA直接修改了，没有经过应用，那么应用做这个操作也会是错的，因为在2.a到3之前的这段时间，有可能正好是DBA直接修改的时候。那么3做的操作也是不对的。 而且，现实情况是在后来的几年开发过程中，我也的确在一些不同的项目代码中看到，其他很多人也在使用类似的代码解决测试人员告诉他们的这些同步问题-_-
5.正确而简洁的解决方法
问题清楚了，也说明了我曾经使用的解决方案也是一个简洁直接的解决方案，纯粹是把简单问题复杂化，下面说说实际有效的解决方案; 就这个丢失更新问题，可以通过数据库的锁来实现，基本两种思路，一种是悲观锁，另外一种是乐观锁; 简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败;另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作;
6. 乐观锁的方法
这里先说web开发中常用的乐观锁的方法：
1.很简单，就是使用前面所说的这样一条SQL，这其实是所谓使用”前镜像”的方式来保证需要更新的数据是符合要求的，
update order_table set status = ‘已发货’ where order_id = 001 and status = ‘有效’ Tom的书上举的例子是对所有列做更新，所以他的SQL大致如下 Update table set col1 = newcol1value, col2 = newcol2value…. where col1 = oldcol1value and col2 = oldcol2value…. 这个我觉得需要根据应用具体分析，如果需要判断所有的值，那就判断所有的值，如果只关心其中一个或部分值，那只需要取相关的值就好了，就比如这里的订单的状态
2.使用版本列[比如时间戳
这个方法比较简单，也最常用，就是在数据库表格中加一列last_modified_date，就是最后更新的时间，每次更新的时候都将这列设成systimestamp，当前系统时间;
然后每次更新的时候，就改成这样 Update table set col = newvalue where id = ** and last_modified_date = old last_modified_date 这样，就可以检验出数据库的值是否在上次查看和这次更新的时候发生了变化，如果发生了变化，那么last_modified_date就变化了，以后的更新就会返回更新了0行，系统就可以通知用户数据发生了变化，然后选择刷新数据或者其他流程。
至于这个last_modified_date的维护，可以选择让应用每次都维护这个值，或者是使用存储过程来包装更新的操作，或者是使用触发器来更新相关的值。几种方法各有利弊，比如应用维护需要保证每段相关代码都正确的维护了这个值;存储过程有一定的开销，通常很多开发对写存储过程可能也不熟练;触发器是简单的实现，但是也是有开销的。具体使用哪种方法需要根据实际情况具体取舍。
3.使用校验或Hash值
这种方法和前面的方法类似，无非是根据其他有实际意义的列来计算出一个虚拟的列，我个人觉得TOM在介绍这个纯粹是介绍了一种”奇技淫巧”，反正我是在实际过程中不知道哪里会需要这样的解决方案，或许也是因为我知道的太少了吧：)
4.使用Oracle 10g的ORA_ROWSCN
这个就是利用10g的一个ora_rowscn特性，可以对每行做精确追踪，不过这个要求在create table的时候就指定相关参数，表格如果创建了以后就不能用alter table来修改了，因为这依赖于物理的实际存储。 同样，我觉得这也可以归为”奇技淫巧”一类; 具体如果有兴趣了解详情的话，可以参考Tom的书
TechTarget中国原创内容，原文链接：http://www.searchdatabase.com.cn/showcontent_38801.htm
-------------------------------------------------------------------------------------------
丢失更新是数据中一个比较常见的经典问题，在做项目时我们有时可能会没有注意到这个问题，但这个问题相当重要，有时会带来比较严重的结果。下面我们就来讨论下这个丢失更新。
一、什么是丢失更新：
用一个操作过程来说明：
(1)会话Session1 中的一个事务获取(查询)一行数据，并显示给一个用户User1.
(2)会话Session2 中的另一个事务也获取这一行，但是将数据显示给另一个用户User2.
(3)User1 使用应用修改了这一行，让应用更新数据库并提交。会话Session1 的事务执行完毕。
(4)User2 也修改这一行，让应用更新数据库并提交。会话Session2 的事务执行完毕。
这个过程就叫做“丢失更新”，因为第(3)步做的操作会全部丢失(被第4步操作覆盖)，最终数据库只会保存第(4)步的更新结果。这个情况在有些系统中可能不会有影响，但在有些系统中可能就影响很大了，举个简单的例子：
财务系统加工资，若公司本次调薪决定给员工张三加1k人民币，财务部两名操作人员A和B，过程情况若是这样的：
1)A操作员在应用系统的页面上查询出张三的薪水信息，然后选择薪水记录进行修改，打开修改页面但A突然有事离开了，页面放在那没有做任何的提交。
2)这时候B操作员同样在应用中查询出张三的薪水信息，然后选择薪水记录进行修改，录入增加薪水额1000，然后提交了。
3)这时候A操作员回来了，在自己之前打开的薪水修改页面上也录入了增加薪水额1000，然后提交了。
其实上面例子操作员A和B只要一前一后做提交，悲剧就出来了。后台修改薪水的sql：update 工资表 set salary = salary + 增加薪水额 where staff_id = ‘员工ID’。这个过程走下来后结果是：张三开心了这次涨了2k，操作员A和B都郁闷了。
二、解决思路：
基本两种思路，一种是悲观锁，另外一种是乐观锁; 简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败;另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作。
三、解决方案1(悲观锁)
a)传统的悲观锁法(不推荐)：
以上面的例子来说明，在弹出修改工资的页面初始化时(这种情况下一般会去从数据库查询出来)，在这个初始化查询中使用select ……for update， 通过添加for update nowait语句，将这条记录锁住，避免其他用户更新，从而保证后续的更新是在正确的状态下更新的。然后在保持这个链接的状态下，在做更新提交。当然这个有个前提就是要保持链接，就是要对链接要占用较长时间，这个在现在web系统高并发高频率下显然是不现实的。
b)现在的悲观锁法(推荐优先使用)：
在修改工资这个页面做提交时先查询下，当然这个查询必须也要加锁(select ……for update nowait)，有人会说，在这里做个查询确认记录是否有改变不就行了吗，是的，是要做个确认，只是你不加for update就不能保证你在查询到更新提交这段时间里这条记录没有被其他会话更新过，所以这种方式也需要在查询时锁定记录，保证在这条记录没有变化的基础上再做更新，若有变化则提示告知用户。
四、解决方案2(乐观锁)
a)旧值条件(前镜像)法：
就是在sql更新时使用旧的状态值做条件，SQL大致如下 Update table set col1 = newcol1value， col2 = newcol2value…。 where col1 = oldcol1value and col2 = oldcol2value…。，在上面的例子中我们就可以把当前工资作为条件进行更新，如果这条记录已经被其他会话更新过，则本次更新了0行，这里我们应用系统一般会做个提示告知用户重新查询更新。这个取哪些旧值作为条件更新视具体系统实际情况而定。(这种方式有可能发生阻塞，如果应用其他地方使用悲观锁法长时间锁定了这条记录，则本次会话就需要等待，所以使用这种方式时最好统一使用乐观锁法。)
b)使用版本列法(推荐优先使用)：
其实这种方式是一个特殊化的前镜像法，就是不需要使用多个旧值做条件，只需要在表上加一个版本列，这一列可以是NUMBER或 DATE/TIMESTAMP列，加这列的作用就是用来记录这条数据的版本(在表设计时一般我们都会给每个表增加一些NUMBER型和DATE型的冗余字段，以便扩展使用，这些冗余字段完全可以作为版本列用)，在应用程序中我们每次操作对版本列做维护即可。在更新时我们把上次版本作为条件进行更新。
c)使用校验和法(不推荐)
d)使用ORA_ROWSCN法(不推荐)
五、结论：
综上所述，我们对丢失更新问题建议采取上面的悲观锁b方法或乐观锁b方法(蓝色字体已标注)，其实这两种方式的本质都一样，都是在更新提交时做一次查询确认在更新提交，我个人觉得都是乐观的做法，区别在于悲观锁b方法是通过select……for update方式，这个可能会导致其他会话的阻塞，而乐观锁b方法需要多一个版本列的维护。
个人建议：在用户并发数比较少且冲突比较严重的应用系统中选择悲观锁b方法，其他情况首先乐观锁版本列法。
原文出自【比特网】