悲观锁/乐观锁

乐观锁和悲观锁是并发控制主要采用的技术手段。为什么有了事务这东西，还需要乐观锁悲观锁？

比如抢票，假设余票只有1张；隔离级别可以保证事务A和事务B不能读到对方的数据，也不能更新对方正在更新的数据，但是事务A和事务B都认为还有1张余票，于是出票，并更新为0。但是事务B读取的是过时数据，依据过时数据做了业务处理。所以需要乐观锁或者悲观锁，来记录一个信息：当前已经读取的数据，是不是已经过时了。事务可以保证一组操作的原子性和隔离级别，悲观锁/乐观锁用来保证并发性。
将事务隔离级别设置为串形化也可以保证数据在多事务并发处理下不存在数据不一致的问题，但串行执行使得数据库的处理性能大幅度地下降。一般来说，数据库的隔离级别都会设置为read committed（MySQL为RR），然后由应用程序使用乐观锁/悲观锁来弥补数据不一致的问题。

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

乐观锁(Optimistic Lock)，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号,最后更新时间等机制。如果其他事务有更新的话，正在提交的事务会进行回滚。一般通过程序实现。

悲观锁：
要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。

    set autocommit=0;

使用select…for update的方式，就通过数据库实现了悲观锁（MySQL MVCC的当前读，加了排它锁）。此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。在事务中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，一般的SELECT ... 则不受此影响。

    //0.开始事务
    begin;/begin work;/start transaction; (三者选一就可以)
    //1.查询出商品信息
    select status from t_goods where id=1 for update;
    //2.根据商品信息生成订单
    insert into t_orders (id,goods_id) values (null,1);
    //3.修改商品status为2
    update t_goods set status=2;
    //4.提交事务
    commit;/commit work;

MySQL InnoDB默认Row-Level Lock，只有「明确」地指定主键或索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。

乐观锁：
使用版本号实现乐观锁：
使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。

    1.查询出商品信息
    select (status,status,version) from t_goods where id=#{id}
    2.根据商品信息生成订单
    3.修改商品status为2
    update t_goods 
    set status=2,version=version+1
    where id=#{id} and version=#{version};

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去验证，不会产生任何锁和死锁。如果大量回滚也会影响效率。