悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

最常用的就是 select … for update，它是一种行锁，会把select出来的结果行锁住，在本事务提交或者回滚之前，不允许其他事务对这些行做update、delete、for update操作。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，期间该数据可以随便被其他人读取，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。

版本号机制是乐观锁最常用的方式，就是在表中增加一个版本号的字段，更新前先查一遍获取版本号，再作为更新语句的where条件进行更新，如果数据在获取版本号之后，在更新之前已经改变了，那就会更新失败，因为最后更新了0条数据，java后台拿到更新数如果为0，则说明更新失败，出现了并发问题，然后做具体的处理。

例如有两个人同时对某条数据做修改，过程如下：

操作员A操作如下：

1

select id, balance, version from table where id=“1”;

查询结果：id=1, balance=1000, version=1

1

update table set balance=balance+100, version=version+1 where id=“1” and version=1;

执行后，返回的更新结果是1，说明更新了一条，数据库里的结果是：id=1, balance=1100, version=2

操作员B操作如下：

1

select id, balance, version from table where id=“1”;

查询结果：id=1, balance=1000, version=1, 说明操作员A还没修改。

1

update table set balance=balance-50, version=version+1 where id=“1” and version=1 ;

查的时候，操作员A还没修改，当要更新时，操作员A已经先修改成功，所以数据库里实际值是id=1, balance=1100, version=2，

操作员B也将版本号加一(version=2)试图向数据库提交数据(balance=950)，但此时查不到where id=“1” and version=1 的数据，

所以update就失败了，执行结果是0，说明没有对任何数据更新成功。

现在再去查一下，结果还是操作员A操作完成之后的结果

select id, balance, version from table where id=“1”;

查询结果：id=1, balance=1100, version=2

以上是自己实现版本号机制的原理，真正使用的版本号机制是数据库本身带有的机制，一旦发现更新的版本号不是最新的就会被驳回。