提到锁大家会想到Synchronized同步关键字，使用它确实可以解决一切并发问题，但是对于体统吞吐量要求更高，在这里提供了几个小技巧。帮助大家减少锁粒度。提高系统的并发能力

一、乐观锁

　　试用场景：读不会冲突、写会冲突、同时读的频率远远大于写

二、乐观锁

一、定义

1.悲观锁：即很悲观，每次拿数据的时候都觉得数据会被人更改，所以拿数据的时候就把这条记录锁掉，这样别人就没法改这条数据了，一直到你的锁释放。

2.乐观锁：即很乐观，查询数据的时候总觉得不会有人更改数据，等到更新的时候再判断这个数据有没有被人更改，有人更改了则本次更新失败。

 三、实现过程

2.悲观锁：悲观锁的实现采用的数据库内部的锁机制，一个典型的倚赖数据库的悲观锁调用：

select * from account where name=”张三” for update
  这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。也就是我们可以在查询数据的时候先用for update把这条数据锁住，然后更改完这条数据再提交。这样别的线程没法更新这条数据，也就保证了不会丢失更新。

.1.悲观锁带来的性能问题。我们试想一个场景：如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果？所以我们这个时候可以使用乐观锁

.乐观锁：乐观锁的实现可以通过在表里面加一个版本号的形式，下面是一个实例。

讲解：也就是每个人更新的时候都会判断当前的版本号是否跟我查询出来得到的版本号是否一致，不一致就更新失败，一致就更新这条记录并更改版本号。

四、使用场景

像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，

上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适