後端開發常常碰到多線程同步問題，也就會經常用到鎖，其中關於讀寫鎖，大家還爭論不休，主要是很多人會傾向於使用讀寫鎖，認爲讀寫鎖能比普通的互斥鎖能帶來性能的提升，這裏先把陳碩大佬總結的貼出來吧（摘自LINUX 多線程服務端編程，第二章，第三節，P23頁），大佬說的已經非常全面到位了：
=============================================================================================
=============================================================================================
讀寫鎖（Readers-Writer lock, 簡寫爲rwlock) 是個看上去很美的抽象，它明確區分了read 和 write 兩種行爲。
初學者常乾的一件事情是，一見到某個共享數據結構頻繁讀而很少寫，就把mutex替換爲rwlock。甚至首選rwlock來保護共享狀態，這不見得是正確的。
從正確性方面來說，一種典型的易犯錯誤是在持有read lock的時候修改了共享數據。這通常發生在程序的維護階段，爲了增加新功能，程序員不小心在原來read lock保護的函數中調用了會修改狀態的函數。這種錯誤的後果跟無保護併發讀寫共享數據是一樣的。
從性能方面說，讀寫鎖不見得比普通mutex更高效，無論如何reader lock 加鎖的開銷不會比mutex lock小，因爲它需要更新當前reader的數目。如果臨界區很小，鎖競爭不激烈，那麼mutex往往會更快。見$1.9的例子。
reader lock 可能允許提升（upgrade）爲writer lock, 也可能不允許提升。考慮$2.1.1的post()和traverse()示例，如果用讀寫鎖保護foos對象，那麼post() 應該持有讀寫鎖，而traverse() 應該持有讀鎖。如果允許吧讀鎖提升爲寫鎖，後果跟使用recursive mutex一樣，會造成迭代器失效，程序崩潰。如果不允許提升， 後果跟使用non-recursive mutex一樣，會造成死鎖。我寧願程序死鎖，留個“全屍”好查驗。
通常reader lock 是可重入的，writer lock是不可重入的。但是爲了防止writer飢餓，writer lock 通常會阻塞後來的reader lock，因此reader lock在重入的時候可能死鎖。另外，在追求低延遲讀取的場合也不適用讀寫鎖。
===========================================================================================
===========================================================================================
這裏我也總結下：
1，讀寫鎖一定比互斥鎖（普通鎖）單次加鎖開銷大，很容易理解，讀寫鎖要做額外的引用計數已加鎖讀寫性質判別，也做了benchmark，macbook pro i5 8g上，讀寫鎖20ns，普通鎖13ns左右
2，讀寫鎖容易誤用，例如加了讀鎖結果進行了寫操作
3，讀寫鎖的優勢在於可以讀併發，那麼如果加鎖粒度控制的比較小，那麼讀寫鎖依然麼有優勢，如果加鎖粒度比較大，那就是設計問題了。。
4，讀寫鎖重入會死鎖，比如讀鎖重入過程中被寫鎖搶佔，就很容易死鎖。
5，讀寫鎖的非對稱設計會造成延時的抖動，特殊場景不可接受。
6，讀寫鎖的優勢場景是 大量的讀，讀併發，多讀少寫，https://blog.csdn.net/myz123321/article/details/89048002 像博文中做的實驗，上面總結的第一點就解釋了，單純比較rw鎖和互斥鎖，沒有場景的比較沒有意義，讀寫鎖必定會慢，讀寫鎖必須用在讀併發且大量讀少量寫的場景，大量讀，讀併發，多讀少寫，這三個條件缺一不可，不然就沒必要用讀寫鎖，互斥鎖就好，具體解釋下就是：
a:讀併發+大量讀，但是沒有多讀少寫，比如讀寫差不多甚至讀比寫還少，這個場景顯然不需要讀寫鎖，這個是最明顯的，因爲讀寫差不多就得互斥鎖上了。
b:讀併發+多讀少寫，但是量不大，偶爾才併發一下就沒必要，量不大的時候讀寫鎖帶來的誤用，死鎖，性能開銷不如用互斥鎖，而且這裏隱含的場景是讀的時間比較集中才會造成讀併發但量不大，除了場景原因也有設計問題。
c:大量讀+多讀少寫，即使這種情況，如果大量的讀都是分散開的，沒有併發讀，或者讀的量和鎖的粒度還沒有上升到容易併發讀的程度，那麼也沒必要讀寫鎖，讀寫鎖的優勢完全沒發揮出來。