互斥锁、自旋锁、读写锁、乐观锁、悲观锁
比较底层的是互斥锁和自旋锁：
加锁的目的就是保证共享资源在任意时间里，只有一个线程访问，这样就可以避免多线程导致共享数据错乱的问题。当已经有一个线程加锁后，其他线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理方式是不一样的：
- 互斥锁：互斥锁加锁失败后，会释放CPU给其他线程
-
自旋锁：自旋锁加锁失败后会忙等待，知道拿到锁
互斥锁是一种独占锁，当线程a加锁之后，线程b加锁就会失败，释放cpu给其他线程，此时线程b加锁的代码就会阻塞。
线程加锁失败之后，会进入“睡眠”状态，在锁被释放之后，在合适的世界会被唤醒，当这个线程获取锁之后就可以继续执行了。
所以互斥锁加锁失败之后，会从用户态转换到内核态，让内核帮我们切换线程，虽然简化了使用所的难度，但是有一定的性能开销成本。主要为两次线程切换上下文的成本
- 当线程加锁失败之后，内核会把线程的状态从【运行】状态转换为【睡眠】状态，然后把cpu切换给其他线程。
- 当锁被释放时，线程就会从之前的【睡眠】状态转换为【就绪】状态，然后内核会在合适的时间里将cpu切换给该线程运行。
切换时切换的是什么？虚拟内存是线程共享的，所以需要切换私有数据，寄存器等不共享的数据。但这些切换是要耗时的。
所以，当能确定锁住的代码执行时间很短，就不应该用互斥锁，应该用自旋锁，否则使用互斥锁。
自旋锁是通过 CPU 提供的 CAS 函数（Compare And Swap），在「用户态」完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。
一般加锁的过程，包含两个步骤：
第一步，查看锁的状态，如果锁是空闲的，则执行第二步；
第二步，将锁设置为当前线程持有；
CAS 函数就把这两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次性执行完两个步骤，要么两个步骤都不执行。
使用自旋锁，当发生锁竞争加锁失败之后，加锁失败线程会进入【忙等待】状态，直到它拿到了锁。
忙等待可以使用while循环实现，但是使用cpu提供的PAUSE指令更好。
自旋锁在单核cpu上，需要抢占式调度器，否则无法使用（因为自旋锁不会放弃CPU）
自旋锁开销少，在多核系统下一般不会主动产生线程切换，适合异步、协程等在用户态切换请求的编程方式，但如果被锁住的代码执行时间过长，自旋的线程会长时间占用 CPU 资源，所以自旋的时间和被锁住的代码执行的时间是成「正比」的关系，我们需要清楚的知道这一点。
自旋锁与互斥锁使用层面比较相似，但实现层面上完全不同：当加锁失败时，互斥锁用「线程切换」来应对，自旋锁则用「忙等待」来应对。
它俩是锁的最基本处理方式，更高级的锁都会选择其中一个来实现，比如读写锁既可以选择互斥锁实现，也可以基于自旋锁实现。
读写锁适用于能明显区分读操作和写操作的场景
工作原理是：
当「写锁」没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源的访问效率，因为「读锁」是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。
但是，一旦「写锁」被线程持有后，读线程的获取读锁的操作会被阻塞，而且其他写线程的获取写锁的操作也会被阻塞。
所以说，写锁是独占锁，因为任何时刻只能有一个线程持有写锁，类似互斥锁和自旋锁，而读锁是共享锁，因为读锁可以被多个线程同时持有。
读写锁在读多写少的场景，能发挥出优势。
另外，根据实现的不同，读写锁可以分为「读优先锁」和「写优先锁」。
读优先锁期望的是，读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 仍然可以成功获取读锁，最后直到读线程 A 和 C 释放读锁后，写线程 B 才可以成功获取读锁。
而写优先锁是优先服务写线程，其工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 获取读锁时会失败，于是读线程 C 将被阻塞在获取读锁的操作，这样只要读线程 A 释放读锁后，写线程 B 就可以成功获取读锁。
问题：
读优先锁可能会导致写线程被饿死；
写优先锁可能会导致读线程被饿死。
既然不管优先读锁还是写锁，对方可能会出现饿死问题，那么我们就不偏袒任何一方，搞个「公平读写锁」。
公平读写锁比较简单的一种方式是：用队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。
互斥锁和自旋锁都是最基本的锁，读写锁可以根据场景来选择这两种锁其中的一个进行实现。
悲观锁和乐观锁
以上涉及到的都是悲观锁。
悲观锁：假定多线程同时修改共享变量的概率非常高，于是很容易出现冲突，所以访问共享变量前要先加锁
乐观锁：与悲观锁恰好相反，它假定多线程同时修改共享变量的概率非常小，所以工作方式是：对访问共享变量不加锁，而是先修改完共享变量，再去验证是否产生冲突。如果没有其他线程修改资源，那么操作完成；如果有，就放弃本次操作。放弃之后就要重试，虽然重试成本很高，但是在概率非常小的情况下，是可以接受的。
乐观锁全程没有加锁，也叫无锁编程
例子：在线文档编辑，服务器在每次修改之后会查询文档的版本号，如果两个线程修改之后的版本号是一致的，就修改成功，否则提交失败。
所以根据多线程同时修改共享变量的情况多或少，可以选择悲观锁或者乐观锁。
参考：
作者：码农小光
链接：https://www.jianshu.com/p/11ccabe13512
