前篇部落格LZ已經分析了ReentrantLock的lock()實作過程，我們了解到lock實作機制有公平鎖和非公平鎖，兩者的主要差別在于公平鎖要按照CLH隊列等待擷取鎖，而非公平鎖無視CLH隊列直接擷取鎖。但是對于unlock()而已，它是不分為公平鎖和非公平鎖的。
release(1)，嘗試在目前鎖的鎖定計數（state）值上減1。成功傳回true，否則傳回false。當然在release()方法中不僅僅隻是将state - 1這麼簡單，- 1之後還需要進行一番處理，如果-1之後的新state = 0 ，則表示目前鎖已經被線程釋放了，同時會喚醒線程等待隊列中的下一個線程，當然該鎖不一定就一定會把所有權交給下一個線程，能不能成功就看它是不是親爹生的了（看運氣）。
在release代碼中有一段代碼很重要：
對于這個LZ在前篇部落格已經較為詳細的闡述了。不懂或者忘記請再次翻閱：【Java并發程式設計實戰】-----“J.U.C”：ReentrantLock之二lock方法分析
waitStatus!=0表明或者處于CANCEL狀态，或者是置SIGNAL表示下一個線程在等待其喚醒。也就是說waitStatus不為零表示它的後繼在等待喚醒。
unparkSuccessor()方法：
<b>注：unlock最好放在finally中！！！！！！unlock最好放在finally中！！！！！！ unlock最好放在finally中！！！！！！ （重要的事說三遍）</b>
參考文獻：
1、Java多線程系列--“JUC鎖”04之 公平鎖(二)
PS:如果你覺得文章對你有所幫助，别忘了推薦或者分享，因為有你的支援，才是我續寫下篇的動力和源泉！
作者：chenssy。一個專注于【死磕 Java】系列創作的男人
出處：https://www.cnblogs.com/chenssy/p/4756437.html
作者個人網站：https://www.cmsblogs.com/。專注于 Java 優質系列文章分享，提供一站式 Java 學習資料
目前死磕系列包括：
1. 【死磕 Java 并發】：https://www.cmsblogs.com/category/1391296887813967872（已完成）
2.【死磕 Spring 之 IOC】：https://www.cmsblogs.com/category/1391374860344758272（已完成）
3.【死磕 Redis】：https://www.cmsblogs.com/category/1391389927996002304（已完成）
4.【死磕 Java 基礎】：https://www.cmsblogs.com/category/1411518540095295488
5.【死磕 NIO】：https://www.cmsblogs.com/article/1435620402348036096
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。