乐观锁，悲观锁，事务

乐观锁，悲观锁，事务

感觉这些东西好基础，好抽象，对不对？还是来和我一起弄明白吧。

     悲观锁和乐观锁本是数据库的概念，但是其实DB与应用并没有本质区别，数据库设计所是为了事物，而事物的核心是并发和锁，如今的环境下，哪个系统不需要支持成千上万的并发量，所以一个合格的系统必须支持事物，通常我们所说的事物指的是针对共享数据进行读写的软件事物。

     锁是一种作为并发访问共享数据时,保证数据一致性的工具。锁有多种实现方式.根据性质来分锁分为很多种,例如,自旋锁,阻塞锁,读写锁,互斥锁等等.从思想上分)乐观锁和悲观锁.

 

悲观锁:
      悲观锁在操作时很悲观，生怕数据被其他人更新掉，我就先将其先锁住，让别人用不了，我操作完成后再释放掉。
      个人理解就是悲观锁对修改数据这件事情持悲观状态,所以他必须要独占数据,让数据修改的过程中只有一个人在操作这个数据(原子操作).
      举例:传统型数据库中如表锁,行锁都是操作之前先上锁,都属于悲观锁,又如jdk中synchronized关键字也是悲观锁的一种.

乐观锁:
      乐观锁(Optimistic Locking)相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制.顾名思义就是对待数据是否被更改这件事持乐观态度,每次去查询数据的时候认为数据不会被修改,所以不会上锁,但是在更新的时候会去判断此数据是否被修改,判断的依据就是加在这个数据上面的某个状态,比如版本号,时间戳等，最后发现不行时就回滚。
      举例: redis中事务使用了乐观锁,mysql中有mvcc机制也是乐观锁的一种,jdk中各种原子类(cas实现).

总结:

        悲观锁需要数据库级别上的的实现，程序中是做不到的，如果在长事务环境中，数据会一直被锁住，导致并发性能大大地降低。而如果使用乐观锁的话，可以间接减少事物的长度，并发度相对高些。

       一般来说只有并发量很高，冲突非常严重的系统才需要悲观锁，否则的话就使用乐观锁。如果并发量很高时使用乐观锁的话，会导致很多的并发事务回滚、操作失败。