HR:请谈谈Hibernate悲观锁和乐观锁的原理和应用场景？

(ps:虽然现在很多企业都在用mybatis代替hibernate，但hibernate还是有一定地位的，此文仅供吐槽。吐吧。。。。)

锁

业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算

处理中，我们希望针对某个cut-off时间点的数据进行处理，而不希望在结算进行过程中

（可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机

制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓

的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。

hibernate之悲观锁和乐观锁

悲观锁：

1.场景：A和B都想上厕所，但是A先进去了，那么B你只有等等。

2.原理：基于数据库锁机制，并发很安全，但对于长事务而言，这样的数据库开销往往无法承受。（等你一个人处理完，别人都等死了）

乐观锁：

1.场景：操作员A和操作员B都在对同一个银行账户做扣款操作时，先操作的A操作时，更新数据的同时，也会更新表中加的字段数据库版本Version的值（一般都是递增），提交时，会比对version数据版本号，只有大于之前旧数据版本号，才允许操作成功，否则操作驳回。

2.原理：大多数情况是基于外部系统的数据存储逻辑，并发时，都可操作数据，但最后提交未必都成功，即提交更新等操作时基于版本号。但因基于外部应用系统，可能会有脏数据更新到数据库；解决办法即，对加了乐观锁的存储过程，对外部应用系统开发，都可调用，但是不要将存储过程中的表对外开放操作。

如果你没看懂，可以点以下链接，去看吧

http://blog.163.com/ainiyiwannian2046@126/blog/static/4910134020093221132298/