面试官：你说说互斥锁、自旋锁、读写锁、悲观锁、乐观锁的应用场景

以下文章来源于小林coding ，作者小林coding
原文出处链接：http://blog.csdn.net/qq_34827674/article/details/108608566

最底层的两种就是会「互斥锁和自旋锁」，有很多高级的锁都是基于它们实现的，你可以认为它们是各种锁的地基，所以我们必须清楚它俩之间的区别和应用。
加锁的目的就是在任意的时候，共享的数据只有一个线程被访问，这样可以保证资源的正确性。最常见的就是 经典的 抢火车票的Java小案例，加锁才能保证资源的安全性。
加锁的目的：都是 当临界资源被加锁后，其他的线程访问的时间，都会加锁失败，但是互斥锁和自旋锁，在加锁失败后处理方式不同。
互斥锁：
当加锁失败，此时线程会 休眠，等待cpu进行唤醒操作，尝试再次获取锁。（会存在线程的上下文切换）
自旋锁：当加锁失败的时候，线程会一直等待，等待锁被释放。减少线程的上下文切换

上面说了上下文切换： 主要分为
互斥锁开销成本是什么呢？会有两次线程上下文切换的成本：

当线程加锁失败时，内核会把线程的状态从「运行」状态设置为「睡眠」状态，然后把 CPU 切换给其他线程运行；
接着，当锁被释放时，之前「睡眠」状态的线程会变为「就绪」状态，然后内核会在合适的时间，把 CPU 切换给该线程运行。

很简单假如，你的共享资源的访问是一个执行时间很短的操作，比如就是进行了一个++的操作（++操作是线程非安全的，比如ArrayList线程安全问题，就是因为 ++ 的安全问题）因为执行的时间很短，等待的成本远远小于对应的等待的时间。此时就不应该使用对应的互斥锁。而是选用自旋锁。
所以，如果你能确定被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁。

自旋锁： CPU 提供的 CAS 函数（Compare And Swap），在「用户态」完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。

一般加锁的过程，包含两个步骤：

第一步，查看锁的状态，如果锁是空闲的，则执行第二步；
第二步，将锁设置为当前线程持有；
对应的 JAVA中 可以使用 java.
提供一种 自旋锁实现：实现起来很简单
package stu.config;

import java.util.concurrent.atomic.AtomicInteger;

class LockTest {
public static int mbb = 0;
public static AtomicInteger lock = new AtomicInteger(0);
public static void main(String[] args) throws Exception {
test();
}
public static void test() throws InterruptedException {
Thread t1 = new Thread() {
@Override
public void run() {
for (int i = 0; i < 5000; i++) {
incTotal();
}
}
};

Thread t2 = new Thread() {
  @Override
  public void run() {
    for (int i = 0; i < 5000; i++) {
      incTotal();
    }
  }
};

t1.start();
t2.start();

t1.join();
t2.join();

System.out.println(mbb);

}

public static void incTotal() {
lock();
mbb ++;
unlock();
}

public static void lock() {
while(true) {
if (lock.get() == 1)
continue;
else if (lock.compareAndSet(0, 1)) {
break;
}
}
}

public static void unlock() {
lock.set(0);
}

}

需要注意，在单核 CPU 上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。
为什么 单CPU无法使用，因为 一直在等锁。。。CPU啥事不用干了。。。。

互斥锁的例子：
synchronized 不在写例子，lock也可以实现

读写锁：读和写还有优先级区分？

在Java 也有对应的读写锁；而且还有对应的优先级的说明。默认采用的是非公平的形式的，可以采用传入变量的形式，打破这种形式。变成公平的锁。也就是相应的队列锁。但是Java为什么要采用非公平形式的锁作为默认的锁呢？而不是采用，感觉更好的公平锁呢。因为要采用对应的公平锁，肯定要使用一个线程安全的队列 来保证公平性，而损耗性能。

读写锁从字面意思我们也可以知道，它由「读锁」和「写锁」两部分构成，如果只读取共享资源用「读锁」加锁，如果要修改共享资源则用「写锁」加锁。

读写锁的工作原理：

• 当写锁没有被占有的时候，此时多个线程能够并发的持有读锁，这会大大的提供共享资源的访问的效率，因为多个线程并发的持有读锁，不会破坏共享资源的数据
• 可当写线程持有锁之后，此时所有的读线程获取读锁都会被堵塞，而且其他的写线程获取写锁也会被堵塞。
  当知道了对应的读写锁后，我们知道这种锁的应用场景。读多写少的场景可以大大提供对应的效率。

而且对应的读写锁还可以再次细分，分为 读优先级锁和写优先级锁。

读优先级锁

读优先级锁的本意是想读线程能够更多的获得锁，从而便提高读线程的并发性。

工作原理：

当读线程获得锁之后，写线程就会获取锁失败，但是并不会堵塞其他的读线程获取锁，

读优先锁对于读线程并发性更好，但也不是没有问题。我们试想一下，如果一直有读线程获取读锁，那么写线程将永远获取不到写锁，这就造成了写线程「饥饿」的现象。

写优先锁可以保证写线程不会饿死，但是如果一直有写线程获取写锁，读线程也会被「饿死」。

既然不管优先读锁还是写锁，对方可能会出现饿死问题，那么我们就不偏袒任何一方，搞个「公平读写锁」。

乐观锁与悲观锁：做事的心态有何不同？
前面提到的互斥锁、自旋锁、读写锁，都是属于悲观锁。

悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，先要上锁。

那相反的，如果多线程同时修改共享资源的概率比较低，就可以采用乐观锁。

乐观锁做事比较乐观，它假定冲突的概率很低，它的工作方式是：先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。

放弃后如何重试，这跟业务场景息息相关，虽然重试的成本很高，但是冲突的概率足够低的话，还是可以接受的。

可见，乐观锁的心态是，不管三七二十一，先改了资源再说。另外，你会发现乐观锁全程并没有加锁，所以它也叫无锁编程。

这里举一个场景例子：在线文档。

我们都知道在线文档可以同时多人编辑的，如果使用了悲观锁，那么只要有一个用户正在编辑文档，此时其他用户就无法打开相同的文档了，这用户体验当然不好了。

那实现多人同时编辑，实际上是用了乐观锁，它允许多个用户打开同一个文档进行编辑，编辑完提交之后才验证修改的内容是否有冲突。

怎么样才算发生冲突？这里举个例子，比如用户 A 先在浏览器编辑文档，之后用户 B 在浏览器也打开了相同的文档进行编辑，但是用户 B 比用户 A 提交改动，这一过程用户 A 是不知道的，当 A 提交修改完的内容时，那么 A 和 B 之间并行修改的地方就会发生冲突。

服务端要怎么验证是否冲突了呢？通常方案如下：

由于发生冲突的概率比较低，所以先让用户编辑文档，但是浏览器在下载文档时会记录下服务端返回的文档版本号；
当用户提交修改时，发给服务端的请求会带上原始文档版本号，服务器收到后将它与当前版本号进行比较，如果版本号一致则修改成功，否则提交失败。
实际上，我们常见的 SVN 和 Git 也是用了乐观锁的思想，先让用户编辑代码，然后提交的时候，通过版本号来判断是否产生了冲突，发生了冲突的地方，需要我们自己修改后，再重新提交。

乐观锁虽然去除了加锁解锁的操作，但是一旦发生冲突，重试的成本非常高，所以只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。

总结
开发过程中，最常见的就是互斥锁的了，互斥锁加锁失败时，会用「线程切换」来应对，当加锁失败的线程再次加锁成功后的这一过程，会有两次线程上下文切换的成本，性能损耗比较大。

如果我们明确知道被锁住的代码的执行时间很短，那我们应该选择开销比较小的自旋锁，因为自旋锁加锁失败时，并不会主动产生线程切换，而是一直忙等待，直到获取到锁，那么如果被锁住的代码执行时间很短，那这个忙等待的时间相对应也很短。

如果能区分读操作和写操作的场景，那读写锁就更合适了，它允许多个读线程可以同时持有读锁，提高了读的并发性。根据偏袒读方还是写方，可以分为读优先锁和写优先锁，读优先锁并发性很强，但是写线程会被饿死，而写优先锁会优先服务写线程，读线程也可能会被饿死，那为了避免饥饿的问题，于是就有了公平读写锁，它是用队列把请求锁的线程排队，并保证先入先出的原则来对线程加锁，这样便保证了某种线程不会被饿死，通用性也更好点。

互斥锁和自旋锁都是最基本的锁，读写锁可以根据场景来选择这两种锁其中的一个进行实现。

另外，互斥锁、自旋锁、读写锁都属于悲观锁，悲观锁认为并发访问共享资源时，冲突概率可能非常高，所以在访问共享资源前，都需要先加锁。

相反的，如果并发访问共享资源时，冲突概率非常低的话，就可以使用乐观锁，它的工作方式是，在访问共享资源时，不用先加锁，修改完共享资源后，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。

但是，一旦冲突概率上升，就不适合使用乐观锁了，因为它解决冲突的重试成本非常高。

不管使用的哪种锁，我们的加锁的代码范围应该尽可能的小，也就是加锁的粒度要小，这样执行速度会比较快。再来，使用上了合适的锁，就会快上加快了。