Является ли ReentrantReadWriteLock реализованным как прямая блокировка?

Question

Как работает 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) 

в горячих нитях во всех снимках и использование центрального процессора является высоким в то же самое время. Это похоже на спин-замок.

Answer 1

Существует стоимость, связанная с локальными данными потока. То, что вы здесь видите, именно это. Вы даже можете увидеть комментарий в 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 не использует спин-блокировки. Он использует объект Sync, который использует wait/notify (реализуемый LockSupport.park (this)) из AbstractQueueSynchronizer.