乐观锁与悲观锁原理及实现 跟着小白一起整理

一、乐观锁和悲观锁的策略

1.悲观锁（一般都是通过锁机制来实现的）

（1）每次去拿数据都会认为别人会修改，所以每次拿数据的时候都会上锁。比如：行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

2.乐观锁

顾名思义，对每次的数据操作都保持乐观的态度，不担心数据会被修改，所以不会对数据进行上锁。由于数据没有上锁，这就存在数据会被多人读写的情况。所以每次修改数据的时候需要对数据进行判断是否被修改过。

（1）每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，如果发生冲突了，则返回用户的错误信息，让用户决定如何去做。（适用于多读的类型，并发大的情况。一般基于数据版本号实现）

（2）冲突检测和数据更新(version版本号机制或者timestamp时间戳字段实现)

在数据表中加上一个数据版本号version字段，表示数据被修改的次数，数据被修改时version值会加1，当更新数据时，刚才读到的version值和数据库中的version值相等才可以更新。

update table set x=x+1, version=version+1 where id=#{id} and version=#{version};

（3）CAS（compare and swap）实现

多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新值，其他的线程失败，但不会被挂起，而是被告知这次竞争失败，并可以再次尝试。
即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

CAS 操作原理:

CAS 操作中包含三个操作数 —— 需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。

适用场景

1.什么时候使用悲观锁？

写入频繁使用悲观锁，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

一旦通过悲观锁锁定一个资源，那么其他需要操作该资源的使用方，只能等待直到锁被释放，好处在于可以减少并发，但是当并发量非常大的时候，由于锁消耗资源，并且可能锁定时间过长，容易导致系统性能下降，资源消耗严重。

2.什么时候使用乐观锁？

读取频繁使用乐观锁，一般乐观锁只用在高并发、多读少写的场景。比如，GIT,SVN,CVS等代码版本控制管理器。

例如：A、B，同时从SVN服务器上下载了hello.java文件，当A完成提交后，此时B再提交，那么会报版本冲突，此时需要B进行版本处理合并后，再提交到服务器。这其实就是乐观锁的实现全过程。如果此时使用的是悲观锁，那么意味者所有程序员都必须一个一个等待操作提交完，才能访问文件，这是难以接受的。

共享锁和排他锁

1.首先说明：数据库的增删改操作默认都会加排他锁，而查询不会加任何锁。

共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。

排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。

|–共享锁：对某一资源加共享锁，自身可以读该资源，其他人也可以读该资源（也可以再继续加共享锁，即 共享锁可多个共存），但无法修改。要想修改就必须等所有共享锁都释放完之后。语法为：

select * from table lock in share mode

|–排他锁：对某一资源加排他锁，自身可以进行增删改查，其他人无法进行任何操作。语法为：

select * from table for update

参考资料

https://blog.csdn.net/shanxiyaofeng/article/details/85100131
https://blog.csdn.net/Michaeles/article/details/86222520
https://blog.csdn.net/localhost01/article/details/78720727