是否將ReentrantReadWriteLock實現爲自旋鎖？

ReentrantReadWriteLock如何工作？它是自旋鎖嗎？是否將ReentrantReadWriteLock實現爲自旋鎖？

的問題來自Elasticsearch，當它顯示

java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntry(Unknown Source) 
    java.lang.ThreadLocal$ThreadLocalMap.remove(Unknown Source) 
    java.lang.ThreadLocal$ThreadLocalMap.access$200(Unknown Source) 
    java.lang.ThreadLocal.remove(Unknown Source) 
    java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(Unknown Source) 
    java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(Unknown Source) 
    java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(Unknown Source)

熱線程

中的所有快照和CPU佔用率高的同時。它看起來像旋轉鎖。

來源

2016-02-26 cybersoft

與線程本地數據相關的成本。你在這裏看到的就是這個。你甚至可以看到的ReentrantReadWriteLock評論mentionning這一點，並通過緩存線程本地數據的數據對其進行優化：

評論：

/** 
    * The hold count of the last thread to successfully acquire 
    * readLock. This saves ThreadLocal lookup in the common case 
    * where the next thread to release is the last one to 
    * acquire. 
    * [...] 
    */ 
    private transient HoldCounter cachedHoldCounter;

的ReentrantReadWriteLock不使用自旋鎖。它使用來自AbstractQueueSynchronizer的使用wait/notify（由LockSupport.park（this）實現）的Sync對象。

來源

2016-03-23 23:47:22

謝謝你的回答！是的，我看到了它......但有些人公然聲稱，當他們在我的問題中看到這樣的堆棧跟蹤時，問題出現在自旋鎖定中。我在'ThreadLocal'中製作了'ReentrantReadWriteLock'副本，但是我沒有時間去測試，因爲改變GC已經解決了我們的問題，這聽起來很奇怪...... – cybersoft

你介意不用在ThreadLocal中保存計數器？我可能會用它來解決另一個我們正在努力解決的問題。 –

它沒有任何困難：http://pastebin.com/jXVyk1Db但它可能不起作用，因爲這些保持計數器上有一些邏輯。代碼與此僅被註釋掉，你可以看 – cybersoft

是否將ReentrantReadWriteLock實現爲自旋鎖？

回答

相關問題