锁：根据业务场景选择合适的锁

互斥锁能够满足各类功能性要求，特别是被锁住的代码执行时间不可控时，它通过内核执行线程切换及时释放了资源，但它的性能消耗最大。需要注意的是，协程的互斥锁实现原理完全不同，它并不与内核打交道，虽然不能跨线程工作，但效率很高。

如果能够确定被锁住的代码取到锁后很快就能释放，应该使用更高效的自旋锁，它特别适合基于异步编程实现的高并发服务。

如果能区分出读写操作，读写锁就是第一选择，它允许多个读线程同时持有读锁，提高了并发性。读写锁是有倾向性的，读优先锁很高效，但容易让写线程饿死，而写优先锁会优先服务写线程，但对读线程亲和性差一些。还有一种公平读写锁，它通过把等待锁的线程排队，以略微牺牲性能的方式，保证了某种线程不会饿死，通用性更佳。

另外，读写锁既可以使用互斥锁实现，也可以使用自旋锁实现，我们应根据场景来选择合适的实现。

以上都是 悲观锁（需要事先拿到锁才能修改数据）

当并发访问共享资源，冲突概率非常低的时候，可以选择无锁编程（乐观锁：全程并没有加锁）。它在 Web 和数据库中有广泛的应用。然而，一旦冲突概率上升，就不适合使用它，因为它解决冲突的重试成本非常高。

总之，不管使用哪种锁，锁范围内的代码都应尽量的少，执行速度要快。在此之上，选择更合适的锁能够大幅提升高并发服务的性能！

---

思考

协程中也有各种锁，你觉得协程中可以用自旋锁或者互斥锁吗？如果不可以，那协程中的锁是怎么实现的？

协程是用户态运行的，所以减少内核切换。而自旋锁和互斥锁其实都是有内核控制线程的访问，所以协程肯定不是使用互斥锁Mutex和自旋锁SpinLock实现的。

我想，协程之间的互相协作肯定也是有一种协商机制，之前在一篇博客看到好像是使用yield实现的，从而共享CPU使用权。