Wenn der Ressourcenwettbewerb nicht sehr hart ist, ist die Leistung von Synchronized besser als die von ReetrantLock, aber wenn der Ressourcenwettbewerb hart ist, sinkt die Leistung von Synchronized um ein Dutzend Mal, aber die Leistung von ReetrantLock kann normal bleiben
(1) Warum ist das so?
(2) Ist ReentrantLock eine leichte Sperre? Was sind leichte Schlösser? Von diesem Namen habe ich nur gehört, aber noch nie eine konkrete Umsetzung gesehen
Wenn bei der Verwendung von synchronisiert das Programm fehlerhaft ausgeführt wird, wird eine Ausnahme ausgelöst, es werden jedoch keine Bereinigungsarbeiten durchgeführt. Durch die Verwendung von ReentrantLock können Sie versuchen, eine Sperre zu erwerben, diese aber letztlich nicht erwerben, sodass Sie, wenn jemand anderes die Sperre erworben hat, andere Dinge tun können (aber was ich jetzt tun möchte, ist, bestimmte Vorgänge nach dem Erwerb der Sperre auszuführen ) scheint es wenig Sinn zu machen, jetzt auf andere Dinge umzusteigen, anstatt zu warten, bis die Sperre aufgehoben wird.
首先你说的这个情况，是在java 1.5刚引入ReentrantLock的时候才有，java1.6对Synchronized的实现算法进行了改造，与ReentrantLock的实现基本一致，所以俩者的性能差异已经很小了。
关于轻量级锁，这是java1.6引入的提升锁性能的一种方式，属于jvm层级的，不存在什么具体实现。
如果希望等待直到这个锁被释放，可以使用Lock.lock()获得的方式获得锁，使用Lock.tryLock()才是在尝试获取可能获取不到锁。
可以简单一点的理解，synchronized 的读写页都是互斥的，但是 ReentrantLock 有读写锁，读锁可以共享，写锁才互斥，如果从这里看的话 ReentrantLock 在读多，写少的情况下性能会高不少，但是代码比 synchronized 的复杂，如果控制不好也容易出问题。