互斥锁
互斥锁（mutex）又叫互斥量，从本质上说是一把锁，在访问共享资源之前对互斥锁进行上锁，在访问完成后释放互斥锁（解锁）；对互斥锁进行上锁之后，任何其它试图再次对互斥锁进行加锁的线程都会被阻塞，直到当前线程释放互斥锁。如果释放互斥锁时有一个以上的线程阻塞，那么这些阻塞的线程会被唤醒，它们都会尝试对互斥锁进行加锁，当有一个线程成功对互斥锁上锁之后，其它线程就不能再次上锁了，只能再次陷入阻塞，等待下一次解锁。
在我们的程序设计当中，只有将所有线程访问共享资源都设计成相同的数据访问规则，互斥锁才能正常工作。如果允许其中的某个线程在没有得到锁的情况下也可以访问共享资源，那么即使其它的线程在使用共享资源前都申请锁，也还是会出现数据不一致的问题。互斥锁使用 pthread_mutex_t 数据类型表示，在使用互斥锁之前，必须首先对它进行初始化操作。
自旋锁
自旋锁与互斥锁很相似，从本质上说也是一把锁，在访问共享资源之前对自旋锁进行上锁，在访问完成后释放自旋锁（解锁）；事实上，从实现方式上来说，互斥锁是基于自旋锁来实现的，所以自旋锁相较于互斥锁更加底层。
如果在获取自旋锁时，自旋锁处于未锁定状态，那么将立即获得锁（对自旋锁上锁）；如果在获取自旋锁时，自旋锁已经处于锁定状态了，那么获取锁操作将会在原地"自旋"，直到该自旋锁的持有者释放了锁。由此介绍可知，自旋锁与互斥锁相似，但是互斥锁在无法获取到锁时会让线程陷入阻塞等待状态；而自旋锁在无法获取到锁时，将会在原地"自旋"等待。"自旋"其实就是调用者一直在循环查看该自旋锁的持有者是否已经释放了锁，"自旋"一词因此得名。
自旋锁的不足之处在于：自旋锁一直占用的 CPU，它在未获得锁的情况下，一直处于运行状态（自旋），所以占着 CPU，如果不能在很短的时间内获取锁，这无疑会使 CPU 效率降低。
试图对同一自旋锁加锁两次必然会导致死锁，而试图对同一互斥锁加锁两次不一定会导致死锁，原因在于互斥锁有不同的类型，当设置为PTHREAD_MUTEX_ERRORCHECK 类型时，会进行错误检查，第二次加锁会返回错误，所以不会进入死锁状态。
因此我们要谨慎使用自旋锁，自旋锁通常用于以下情况：需要保护的代码段执行时间很短，这样就会使得持有锁的线程会很快释放锁，而"自旋"等待的线程也只需等待很短的时间；在这种情况下就比较适合使用自旋锁，效率高！
自旋锁与互斥锁之间的区别
- 实现方式上的区别：互斥锁是基于自旋锁而实现的，所以自旋锁相较于互斥锁更加底层；
- 开销上的区别：获取不到互斥锁会陷入阻塞状态（休眠），直到获取到锁时被唤醒；而获取不到自旋锁会在原地"自旋"，直到获取到锁；休眠与唤醒开销是很大的，所以互斥锁的开销要远高于自旋锁、自旋锁的效率远高于互斥锁；但如果长时间的"自旋"等待，会使得 CPU 使用效率降低，故自旋锁不适用于等待时间比较长的情况。
- 使用场景的区别：自旋锁在用户态应用程序中使用的比较少，通常在内核代码中使用比较多；因为自旋锁可以在中断服务函数中使用，而互斥锁则不行，在执行中断服务函数时要求不能休眠、不能被抢占（内核中使用自旋锁会自动禁止抢占），一旦休眠意味着执行中断服务函数时主动交出了CPU使用权，休眠结束时无法返回到中断服务函数中，这样就会导致死锁！
- 最底层的两种就是「互斥锁和自旋锁」，有很多高级的锁都是基于它们实现，可以认为它们是各种锁的地基，所以得清楚它俩之间的区别和应用。加锁的目的是保证共享资源在任意时间里
读写锁
互斥锁或自旋锁要么是加锁状态、要么是不加锁状态，而且一次只有一个线程可以对其加锁。读写锁有3 种状态：读模式下的加锁状态（以下简称读加锁状态）、写模式下的加锁状态（以下简称写加锁状态）和不加锁状态（见），一次只有一个线程可以占有写模式的读写锁，但是可以有多个线程同时占有读模式的读写锁。因此可知，读写锁比互斥锁具有更高的并行性！
读写锁有如下两个规则：
- 当读写锁处于写加锁状态时，在这个锁被解锁之前，所有试图对这个锁进行加锁操作（不管是以读模式加锁还是以写模式加锁）的线程都会被阻塞。
- 当读写锁处于读加锁状态时，所有试图以读模式对它进行加锁的线程都可以加锁成功；但是任何以写模式对它进行加锁的线程都会被阻塞，直到所有持有读模式锁的线程释放它们的锁为止。
虽然各操作系统对读写锁的实现各不相同，但当读写锁处于读模式加锁状态，而这时有一个线程试图以写模式获取锁时，该线程会被阻塞；而如果另一线程以读模式获取锁，则会成功获取到锁，对共享资源进行读操作。
所以，读写锁非常适合于对共享数据读的次数远大于写的次数的情况。当读写锁处于写模式加锁状态时，它所保护的数据可以被安全的修改，因为一次只有一个线程可以在写模式下拥有这个锁；当读写锁处于读模式加锁状态时，它所保护的数据就可以被多个获取读模式锁的线程读取。所以在应用程序当中，使用读写锁实现线程同步，当线程需要对共享数据进行读操作时，需要先获取读模式锁（对读模式锁进行加锁），当读取操作完成之后再释放读模式锁（对读模式锁进行解锁）；当线程需要对共享数据进行写操作时，需要先获取到写模式锁，当写操作完成之后再释放写模式锁。
读写锁也叫做共享互斥锁。当读写锁是读模式锁住时，就可以说成是共享模式锁住。当它是写模式锁住时，就可以说成是互斥模式锁住。
文件锁
现象一下，当两个人同时编辑磁盘中同一份文件时，其后果将会如何呢？在 Linux 系统中，该文件的最后状态通常取决于写该文件的最后一个进程。多个进程同时操作同一文件，很容易导致文件中的数据发生混乱，因为多个进程对文件进行 I/O 操作时，容易产生竞争状态、导致文件中的内容与预想的不一致！
对于有些应用程序，进程有时需要确保只有它自己能够对某一文件进行 I/O 操作，在这段时间内不允许其它进程对该文件进行 I/O 操作。为了向进程提供这种功能，Linux 系统提供了文件锁机制。
前面学习过互斥锁、自旋锁以及读写锁，文件锁与这些锁一样，都是内核提供的锁机制，锁机制实现用于对共享资源的访问进行保护；只不过互斥锁、自旋锁、读写锁与文件锁的应用场景不一样，互斥锁、自旋锁、读写锁主要用在多线程环境下，对共享资源的访问进行保护，做到线程同步。
而文件锁，顾名思义是一种应用于文件的锁机制，当多个进程同时操作同一文件时，我们怎么保证文件数据的正确性，linux 通常采用的方法是对文件上锁，来避免多个进程同时操作同一文件时产生竞争状态。譬如进程对文件进行 I/O 操作时，首先对文件进行上锁，将其锁住，然后再进行读写操作；只要进程没有对文件进行解锁，那么其它的进程将无法对其进行操作；这样就可以保证，文件被锁住期间，只有它（该进程）可以对其进行读写操作。
一个文件既然可以被多个进程同时操作，那说明文件必然是一种共享资源，所以由此可知，归根结底，文件锁也是一种用于对共享资源的访问进行保护的机制，通过对文件上锁，来避免访问共享资源产生竞争状态
乐观锁与悲观锁
前面提到的互斥锁、自旋锁、读写锁，都是属于悲观锁。悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，先要上锁。
相反的，如果多线程同时修改共享资源的概率比较低，就可以采用乐观锁。乐观锁做事比较乐观，它假定冲突的概率很低，它的工作方式是：先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。
放弃后如何重试，这跟业务场景息息相关，虽然重试的成本很高，但是冲突的概率足够低的话，还是可以接受的。可见，乐观锁的心态是，不管三七二十一，先改了资源再说。另外，你会发现乐观锁全程并没有加锁，所以它也叫无锁编程。
举个例子
在线文档是可以同时多人编辑，如果使用了悲观锁，只要有一个用户正在编辑文档，此时其他用户就无法打开相同的文档，用户体验当然不好。
实现多人同时编辑，实际上是用了乐观锁，它允许多个用户打开同一个文档进行编辑，编辑完提交之后才验证修改的内容是否有冲突。
怎么样才算发生冲突？这里举个例子，比如用户 A 先在浏览器编辑文档，之后用户 B 在浏览器也打开了相同的文档进行编辑，但是用户 B 比用户 A 提交改动，这一过程用户 A 是不知道的，当 A 提交修改完的内容时，那么 A 和 B 之间并行修改的地方就会发生冲突。
服务端是如何解决这种冲突的
由于发生冲突的概率比较低，所以先让用户编辑文档，但是浏览器在下载文档时会记录下服务端返回的文档版本号；当用户提交修改时，发给服务端的请求会带上原始文档版本号，服务器收到后将它与当前版本号进行比较，如果版本号一致则修改成功，否则提交失败。
实际上，常见的 SVN 和 Git 也是用了乐观锁的思想，先让用户编辑代码，然后提交的时候，通过版本号来判断是否产生了冲突，发生了冲突的地方，需要我们自己修改后，再重新提交。
乐观锁虽然去除了加锁解锁的操作，但一旦发生冲突，重试的成本非常高，所以只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。
总结
互斥锁、自旋锁和读写锁用于解决多线程同步的问题
文件锁适用于多个进程同时操作同一文件，这时很容易导致文件中的数据发生混乱