乐观锁和悲观锁的使用场景悲观锁在所有操作前都上锁乐观锁总是假设最好的情况每次去拿数据的时候都认为别人不会修改所以不会上锁但是在更新的时候会判断一下在此期间别人有没有去更新这个数据可以使用版本号机制和 CAS 算法实现。乐观锁适用于写比较少的情况下多读场景即冲突真的很少发生的时候这样可以省去了锁的开销加大了系统的整个吞吐量。但如果是多写的情况一般会经常产生冲突这就会导致上层应用会不断的进行 retry 这样反倒是降低了性能所以一般多写的场景下用悲观锁就比较合适。死锁的解决方法死锁的产生是在这样一种环境中比如我们有两个进程 AB 他们都需要资源 1 和资源 2 当进程 A 持有资源 1 进线程 B 持有资源 2 的时候他们都需要对方手上的进程而一般操作系统又不允许抢占这个时候就发生了死锁。从这个例子中其实可以总结出死锁的几个必要条件1. 一个资源只能被一个进程所占有不能共享。2. 一个线程请求资源失败时它会等待而不是释放。3. 一个线程在释放资源之前其他进程不能抢夺资源。4. 循环等待从死锁产生的原因未明可以设计一些方法去避免死锁的发生1静态分配资源一开始就把一个进程所需的全部资源都分配给它但这样会降低资源的使用效率。2允许抢占需要设置进程的不同优先级高优先级的进程可以抢占低优先级的进程的资源。3把资源进行编号申请资源必须按照资源的编号顺序来申请。如果死锁已经发生了就需要去解开死锁其本质思想就是分配资源打破循环等待。1可以运行抢占从一个或多个进程中抢出资源来给其他进程。2也可以终止一些进程来达到释放资源的目的。