悲观锁和乐观锁

标签：读取   tran   zed   系统   算法   span   情况   场景   算法实现   

悲观锁

对数据的冲突采取一种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。【数据锁定：数据将暂时不会得到修改】，（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程），传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测【判断在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现】，如果发现冲突了，则让用户返回错误的信息。让用户决定如何去做。

使用场景

乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

实现

后续补充。

悲观锁和乐观锁

标签：读取   tran   zed   系统   算法   span   情况   场景   算法实现   

原文地址：https://www.cnblogs.com/ynhwl/p/9865471.html