問題描述

在資源競爭不是很激烈的情況下，Synchronized的性能要優(yōu)于ReetrantLock，但是在資源競爭很激烈的情況下，Synchronized的性能會下降幾十倍，但是ReetrantLock的性能能維持常態(tài)

（1）這個(gè)是為啥？（2）ReentrantLock是不是輕量級鎖？ 輕量級鎖有哪些？ 只聽過這個(gè)名字，沒見過有具體實(shí)現(xiàn)

用synchronized時(shí)候,如果程序運(yùn)行出錯(cuò),就會拋出異常,但是不會去做清理工作。使用ReentrantLock允許你嘗試著獲取但最終未獲取的鎖,這樣如果其他人已經(jīng)獲得這個(gè)鎖,那你就可以離開去執(zhí)行別的事情(但是我現(xiàn)在想做的事情的是獲取鎖之后進(jìn)行某些操作，現(xiàn)在轉(zhuǎn)而去執(zhí)行其他事情好像意義不太大呀),而不是等待直到這個(gè)鎖被釋放。

問題解答

首先你說的這個(gè)情況，是在java 1.5剛引入ReentrantLock的時(shí)候才有，java1.6對Synchronized的實(shí)現(xiàn)算法進(jìn)行了改造，與ReentrantLock的實(shí)現(xiàn)基本一致，所以倆者的性能差異已經(jīng)很小了。關(guān)于輕量級鎖，這是java1.6引入的提升鎖性能的一種方式，屬于jvm層級的，不存在什么具體實(shí)現(xiàn)。如果希望等待直到這個(gè)鎖被釋放，可以使用Lock.lock()獲得的方式獲得鎖，使用Lock.tryLock()才是在嘗試獲取可能獲取不到鎖。

可以簡單一點(diǎn)的理解，synchronized 的讀寫頁都是互斥的，但是 ReentrantLock 有讀寫鎖，讀鎖可以共享，寫鎖才互斥，如果從這里看的話 ReentrantLock 在讀多，寫少的情況下性能會高不少，但是代碼比 synchronized 的復(fù)雜，如果控制不好也容易出問題。