乐观锁与悲观锁

悲观锁和乐观锁是数据库用来保证数据并发安全防止更新丢失的两种方法,是一种思想:
乐观锁乐观锁是一种思想，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据 ,一种实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，需要再次查看该字段的值是否和第一次的一样。如果一样更新，反之拒绝。之所以叫乐观，因为这个模式没有从数据库加锁.也可以使用时间戳实现乐观锁.使用再查询实现乐观锁
使用版本控制实现乐观锁:我们先创建一个表（重要的是version字段）： 
create table account (
id int primary key auto_increment,
name char(4),
money double(10,2),
version int
); 
根据版本查询数据,已经实现了乐观锁.
update t_goods set status=2,version=version+1where id=#{id} and version=#{version};

当另一个请求去根据以前的version去更新 数据时候 ,自然更新不到因为version已经加1了,这样我们就认为实现了乐观锁
使用时间戳实现乐观锁:同样是在需要乐观锁控制的table中增加一个
字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在
更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果

一致则OK，否则就是版本冲突 .

使用再查询实现乐观锁:这方法是提取对比，这种方法不需要增加字段，先把要更新的内容读取一遍，更新
的时候再检查之前读到的内容和现在数据库中的内容是否一致，一致则进行更新

悲观锁:每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会等待直到它拿到锁 .
传统的关系型数据库里边就用到了很多这种悲观锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁 
悲观锁举例
//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为update t_goods set status=2;
//4.提交事务commit;/commit work;

两种锁各有优缺点:不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适 
悲观锁和乐观锁使用场景
1.响应速度：如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁
2.冲突频率：如果冲突频率非常高，建议采用悲观锁，保证成功率，如果冲突频率大，乐观锁会需要多次重试才能成功，代价比较大
3.重试代价：如果重试代价大，建议采用悲观锁