這是一個來自實際項目的例子，在這個案例中，有同事基于jdk中的LinkedHashMap設計了一個LRUCache，為了提高性能，使用了 ReentrantReadWriteLock 讀寫鎖：寫鎖對應put()方法，而讀鎖對應get()方法，期望通過讀寫鎖來實現并發get()。
代碼實現如下：
private ReentrantReadWriteLock lock = new ReentrantReadWriteLock ();
lruMap = new LinkedHashMap<K, V>(initialCapacity, loadFactor, true)
public V get(K key) {
lock.readLock().lock();
try {
return lruMap.get(key);
} finally {
lock.readLock().unlock();
}
}
public int entries() {
lock.readLock().lock();
try {
return lruMap.size();
} finally {
lock.readLock().unlock();
}
}
public void put(K key, V value) {
...
lock.writeLock().lock();
try {
...
lruMap.put(key, value);
...
} finally {
lock.writeLock().unlock();
}
}
在測試中發現問題，跑了幾個小時系統就會hung up，無法接收http請求。在將把線程棧打印出來檢查后，發現很多http的線程都在等讀鎖。有一個 runnable的線程hold了寫鎖，但一直停在LinkedHashMap.transfer方法里。線程棧信息如下:
"http-0.0.0.0-8081-178" daemon prio=3 tid=0x0000000004673000 nid=0x135 waiting on condition [0xfffffd7f5759c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xfffffd7f7cc86928> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:941)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1261)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594)
......
"http-0.0.0.0-8081-210" daemon prio=3 tid=0x0000000001422800 nid=0x155 runnable [0xfffffd7f5557c000]
java.lang.Thread.State: RUNNABLE
at java.util.LinkedHashMap.transfer(LinkedHashMap.java:234)
at java.util.HashMap.resize(HashMap.java:463)
at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:414)
at java.util.HashMap.put(HashMap.java:385)
......
大家都知道HashMap不是線程安全的，因此如果HashMap在多線程并發下，需要加互斥鎖，如果put()不加鎖，就很容易破壞內部鏈表，造成get()死循 環，一直hung住。這里有一個來自淘寶的例子，有對此現象的詳細分析：https://gist.github.com/1081908
但是在MSDP的這個例子中，由于ReentrantReadWriteLock 讀寫鎖的存在，put()和get()方法是互斥，不會有上述讀寫競爭的問題。
Google后發現這是個普遍存在的問題，其根結在于LinkedHashMap的get()方法會改變數據鏈表。我們來看一下LinkedHashMap的實現代碼：
public V get(Object key) {
Entry<K,V> e = (Entry<K,V>)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
void recordAccess(HashMap<K,V> m) {
LinkedHashMap<K,V> lm = (LinkedHashMap<K,V>)m;
if (lm.accessOrder) {
lm.modCount++;
remove();
addBefore(lm.header);
}
}
void transfer(HashMap.Entry[] newTable) {
int newCapacity = newTable.length;
for (Entry<K,V> e = header.after; e != header; e = e.after) {
int index = indexFor(e.hash, newCapacity);
e.next = newTable[index];
newTable[index] = e;
}
}
前面LRUCache的代碼中，是這樣初始化LinkedHashMap的：
lruMap = new LinkedHashMap<K, V>(initialCapacity, loadFactor, true)
LinkedHashMap構造函數中的參數true表明LinkedHashMap按照訪問的次序來排序。這里所謂的按照訪問的次序來排序的含義是:當調用LinkedHashMap 的get(key)或者put(key, value)時，如果key在map中被包含，那么LinkedHashMap會將key對象的entry放在線性結構的最后。正是因為LinkedHashMap提 供按照訪問的次序來排序的功能，所以它才需要改寫HashMap的get(key)方法（HashMap不需要排序）和HashMap.Entry的recordAccess(HashMap)方法。注 意addBefore(lm.header)是將該entry放在header線性表的最后。（參考LinkedHashMap.Entry extends HashMap.Entry 比起HashMap.Entry多了before, after兩個域，是雙向的）
在上面的LRUCache中，為了提供性能，通過使用ReentrantReadWriteLock讀寫鎖實現了并發get()，結果導致了并發問題。解決問題的方式很簡單， 去掉讀寫鎖，讓put()/get()都使用普通互斥鎖就可以了。當然，這樣get()方法就無法實現并發讀了，對性能有所影響。
總結，在使用LinkedHashMap時，請小心LinkedHashMap的get()方法。