1.概述
目的：多线程访问共享资源的时候，避免不了资源竞争而导致数据错乱的问题，所以我们通常为了解决这一问题，都会在访问共享资源之前加锁
2.互斥锁
互斥锁是一种独占锁，比如当线程A加锁成功后，此时互斥锁已经被线程A独占了，只要线程A没有释放手中的锁，线程B加锁就会失败，于是就是释放CPU让给其他线程，既然线程B释放掉了CPU，自然线程B的代码就会被阻塞。
当已经有一个线程加锁后，其他线程加锁就会失败；互斥锁加锁失败后，线程会释放CPU，给其他进程
对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的。
当加锁失败时，内核会将线程置为睡眠状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。如下图：
所以，互斥锁加锁失败时，会从用户态陷入到内核态，让内核帮我们切换线程，虽然简化了锁的难度，但是存在一定的性能开销成本
那这个开销成本是什么呢？会有两次线程上下文切换的成本：
- 当线程加锁失败时，内核会线程的状态从运行态设置为睡眠状态，然后把CPU切换给其他线程运行
- 接着，当锁被释放时，之前的睡眠状态的线程会变为就绪状态，然后内会在何时的时间，把CPU切换给该线程运行
3.自旋锁
如果你能确定你被所著的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁
自旋锁时通过CPU提供的CAS函数，在用户态完成加锁和解锁操作，不会主动产生线程上下文切换，所以互斥锁来说，会快一些，开销也小一些
加锁过程：
- 第一步，查看锁的状态，如果锁是空闲的，则执行第二步
- 第二步，将锁设置为当前线程持有
CAS函数就把两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次执行，要么都不执行
比如，设锁为变量 lock，整数 0 表示锁是空闲状态，整数 pid 表示线程 ID，那么 CAS(lock, 0, pid) 就表示自旋锁的加锁操作，CAS(lock, pid, 0) 则表示解锁操作。
使用自旋锁的时候，当发生多线程城竞争锁的情况，加锁失败的线程会忙等待,直到它拿到锁，这里的忙等待可以用while循环等待实现，不过最好时使用CPU提供的PAUSE指令来实现忙等待，因为可以减少循环等待时的耗电量
CPU的PAUSE指令是一种在多处理器系统中用于提高性能的指令。这个指令通常在自旋锁中使用，以减少不必要的功耗和提高线程调度的效率。当一个处理器执行PAUSE指令时，它会暂停当前线程的执行，并让其他线程或者处理器有机会执行，从而避免忙等待状态下产生过多的消耗。
自旋锁是最比较简单的一种锁，一直自旋，利用 CPU 周期，直到锁可用。需要注意，在单核 CPU 上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。
4.读写锁
读写锁从字面意思我们也可以知道，它由读锁和写锁两部分构成，如果只读取共享资源用读锁加锁，如果要修改共享资源则用写锁加锁；
所以，读写锁适用于能明确区分读操作和写操作的场景
读写锁的工作原理：
- 当写锁没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源的访问效率，因为读锁是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据
- 但是，一旦写锁被持有后，读线程的获取锁的操作会被阻塞，而且其他写线程的获取写锁的操作也会被阻塞
所以说：写锁是独占锁，因为任何时刻只能有一个线程持有写锁，类似互斥和自旋锁，而读锁是共享锁，因为读锁可以被多个线程同时持有
另外，根据实现的不同，读写锁可以分为读优先锁和写优先锁。
读优先锁期望的是，读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 仍然可以成功获取读锁，最后直到读线程 A 和 C 释放读锁后，写线程 B 才可以成功获取写锁。如下图：
而「写优先锁」是优先服务写线程，其工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 获取读锁时会失败，于是读线程 C 将被阻塞在获取读锁的操作，这样只要读线程 A 释放读锁后，写线程 B 就可以成功获取写锁。如下图：
读优先锁对于读线程并发性更好，但也不是没有问题。我们试想一下，如果一直有读线程获取读锁，那么写线程将永远获取不到写锁，这就造成了写线程「饥饿」的现象。
写优先锁可以保证写线程不会饿死，但是如果一直有写线程获取写锁，读线程也会被「饿死」。
既然不管优先读锁还是写锁，对方可能会出现饿死问题，那么我们就不偏袒任何一方，搞个「公平读写锁」。
公平读写锁比较简单的一种方式是：用队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。
5.悲观锁
互斥锁，自旋锁，读写锁都属于悲观锁
悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，要先上锁
6.乐观锁
乐观锁做事比较乐观，它假定冲突的概率很低；
乐观锁的工作方式是：先修改完共享资源，在验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作；
乐观锁全程并没有加锁，所以它也叫无锁编程
乐观锁虽然去除了加锁解锁的操作，但是一旦发生冲突，重试的成本非常高，所以只有在冲突概率非常低，且加锁成本非常高的场景时，才会考虑使用乐观锁
7.总结
互斥锁：开发过程中，最常见的就是互斥锁了，互斥锁加锁失败后，会用线程切换来应对，当加锁失败的线程再次加锁成功后的这一过程，会有两次的线程上下文切换，性能损耗比较大
自旋锁：如果我们明确知道被锁住的代码执行时间很短，那我们应该选择开销比较小的自旋锁，因为自旋锁加锁失败时，并不会在互动产生线程切换，而是一直忙等待，直到获取到锁，那么如果被锁住的代码执行时间很短，那么这个忙等待的时间对应也很短
读写锁：如果能区分读操作和写操作的场景，那读写锁就更合适了，它允许多个读线程同时持有读锁，提高了读的并发性，根据偏袒读方还是写方，可以分为读优先锁和写优先锁，读优先锁并发性很强但是写进程会被饿死；而写优先锁会优先服务写线程，读线程也可能会被饿死，那为了避免饥饿的问题，于是就有了公平读写锁，它是用队列请求锁的现车给排队，并保证先入先出的原则来对线程加锁，这样便保证了某种线程不会被饿死，通用性也好点
悲观锁：悲观锁认为并发访问共享资源时，冲突概率可能非常高，所以在访问共享资源前，都需要先加锁。
乐观锁：如果并发访问共享资源时，冲突概率非常低的话，就可以使用乐观锁，他的工作方式是：在访问共享资源时，不用先加锁，修改完共享资源后，在验证这段时间内有没有冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作；但是，一旦冲突概率上升，就不适合使用乐观锁了，因为他解决冲突的重试成本非常高