使用Syschronized 關鍵字 同步代碼塊(同步方法)都是使用到對象的內置鎖
java在設計上每個對象都有一個內置鎖,只是為了免去需要時顯示的創建鎖對象
對于包含多個變量的不變形條件,所有變量使用同一個鎖來保護,可以保證一致性
內置鎖中,會出現死鎖問題:出現不一致的鎖順序(相互等待),解決的方法只能重啟應用
Lock接口中定義的 tryLock()、tryLock(long timeout,TimeUnit unit)方法,可以實現可輪詢、可定時的獲取鎖操作, 在獲取不到鎖,或超時,可以輪詢重試,或者超時退出獲取請求,這樣可以有效的避免死鎖
Lock 接口定義的方法 lockInterruptibly()阻塞獲取鎖,能響應線程中斷請求,同步代碼塊則不能響應中斷,只能一直阻塞或者成功獲取到鎖
同步代碼塊的加鎖、釋放鎖都是基于synchronized同步關鍵字的代碼塊,自動獲取鎖、釋放鎖,使用簡單,可以避免忘記釋放鎖的編程錯誤; 但這樣的加鎖規則不靈活,不能自己控制獲取和釋放
公平鎖:
線程按照獲取鎖的請求順序獲取到鎖,一個線程發出獲取鎖時,如果鎖已經由另一線程持有或者有其他線程在隊列等待獲取鎖,那么這個新請求的線程將放入到隊列中
非公平鎖:
線程獲取到鎖的順序與請求鎖的順序不能保證,存在線程直接“插隊”獲取鎖的情況:一個線程發出獲取鎖時,如果當前鎖的狀態變為可獲取,那么這個新請求鎖的線程將直接跳過等待隊列并獲取到鎖
非公平鎖比公平鎖提供更好的性能: 公平鎖在掛起線程和恢復線程時存在的開銷降低了性能,在鎖競爭激烈的情況下,恢復一個被掛起的線程與該線程真正開始運行存在嚴重的延遲,舉個公平鎖例子:A線程持有一個鎖,此時B線程請求這個鎖,則B被掛起、放入等待隊列,當A釋放鎖時,B將被喚醒,恢復運行再次嘗試獲取鎖;喚醒B并等待恢復運行是有時間消耗的; 假設A釋放鎖時,線程C也請求這個鎖,非公平鎖情況下,C可能會在B喚醒前直接獲得并使用這個鎖,更加充分的使用到了鎖的時間,因此吞吐量會更高
默認ReentrantLock與synchronized內置鎖都是非公平鎖,ReentrantLock也提供了非公平鎖的實現,一般情況下,非公平鎖時可以符合使用要求,java語言規范沒有要求內置鎖要實現公平,ReentrantLock也沒有降低公平性;
ReentrantLock擁有內置鎖沒有的特性:鎖等待(超時,輪詢)、可中斷的鎖等待阻塞、公平性鎖、更加靈活可以實現非塊結構加鎖; 而內置鎖的使用更加簡單明了,自動獲取鎖和釋放鎖,比ReentrantLock更加安全,不會因為忘記釋放鎖導致不可知問題; 在性能方法,java6后兩者實際相差不大。當內置鎖不能滿足使用需求是,可以考慮使用ReentrantLock,即還是優先使用內置鎖
以上只是基于對比說明了內置鎖和ReentranLock,沒有具體詳細的例子,如有不對或不能理解,還請評論交流
新聞熱點
疑難解答