乐观锁和悲观锁的使用场景

• 悲观锁：在所有操作前都上锁
• 乐观锁：总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和 CAS 算法实现。

乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。

但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行 retry ，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

死锁的解决方法

死锁的产生是在这样一种环境中：

比如我们有两个进程 AB ，他们都需要资源 1 和资源 2 ，当进程 A 持有资源 1 ，进线程 B 持有资源 2 的时候，他们都需要对方手上的进程，而一般操作系统又不允许抢占，这个时候就发生了死锁。

从这个例子中其实可以总结出死锁的几个必要条件：

1. 一个资源只能被一个进程所占有，不能共享。

2. 一个线程请求资源失败时，它会等待而不是释放。

3. 一个线程在释放资源之前其他进程不能抢夺资源。

4. 循环等待

从死锁产生的原因未明可以设计一些方法去避免死锁的发生：

（1）静态分配资源，一开始就把一个进程所需的全部资源都分配给它，但这样会降低资源的使用效率。

（2）允许抢占，需要设置进程的不同优先级，高优先级的进程可以抢占低优先级的进程的资源。

（3）把资源进行编号，申请资源必须按照资源的编号顺序来申请。

如果死锁已经发生了，就需要去解开死锁，其本质思想就是分配资源打破循环等待。

（1）可以运行抢占，从一个或多个进程中抢出资源来给其他进程。

（2）也可以终止一些进程，来达到释放资源的目的。