zoukankan      html  css  js  c++  java
  • 小心LinkedHashMap的get()方法(转)

    这是一个来自实际项目的例子,在这个案例中,有同事基于jdk中的LinkedHashMap设计了一个LRUCache,为了提高性能,使用了 ReentrantReadWriteLock 读写锁:写锁对应put()方法,而读锁对应get()方法,期望通过读写锁来实现并发get()。

       代码实现如下: 

    [java] view plain copy
     
     在CODE上查看代码片派生到我的代码片
    1. private ReentrantReadWriteLock  lock = new ReentrantReadWriteLock ();  
    2. lruMap = new LinkedHashMap<K, V>(initialCapacity, loadFactor, true)  
    3.   
    4. public V get(K key) {  
    5.         lock.readLock().lock();  
    6.         try {  
    7.                 return lruMap.get(key);  
    8.         } finally {  
    9.                 lock.readLock().unlock();  
    10.         }  
    11. }  
    12.   
    13. public int entries() {  
    14.         lock.readLock().lock();  
    15.         try {  
    16.                 return lruMap.size();  
    17.         } finally {  
    18.                 lock.readLock().unlock();  
    19.         }  
    20. }  
    21.   
    22. public void put(K key, V value) {  
    23.         ...  
    24.         lock.writeLock().lock();  
    25.         try {  
    26.         ...  
    27.                 lruMap.put(key, value);  
    28.         ...  
    29.         } finally {  
    30.                 lock.writeLock().unlock();  
    31.         }  
    32. }  


    在测试中发现问题,跑了几个小时系统就会hung up,无法接收http请求。在将把线程栈打印出来检查后,发现很多http的线程都在等读锁。有一个 runnable的线程hold了写锁,但一直停在LinkedHashMap.transfer方法里。线程栈信息如下:

    [plain] view plain copy
     
     在CODE上查看代码片派生到我的代码片
    1. "http-0.0.0.0-8081-178" daemon prio=3 tid=0x0000000004673000 nid=0x135 waiting on condition [0xfffffd7f5759c000]  
    2.    java.lang.Thread.State: WAITING (parking)  
    3.         at sun.misc.Unsafe.park(Native Method)  
    4.         - parking to wait for  <0xfffffd7f7cc86928> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)  
    5.         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)  
    6.         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)  
    7.         at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:941)  
    8.         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1261)  
    9.         at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594)  
    10.         ......  
    11. "http-0.0.0.0-8081-210" daemon prio=3 tid=0x0000000001422800 nid=0x155 runnable [0xfffffd7f5557c000]  
    12.    java.lang.Thread.State: RUNNABLE  
    13.         at java.util.LinkedHashMap.transfer(LinkedHashMap.java:234)  
    14.         at java.util.HashMap.resize(HashMap.java:463)  
    15.         at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:414)  
    16.         at java.util.HashMap.put(HashMap.java:385)  
    17.         ......  


    大家都知道HashMap不是线程安全的,因此如果HashMap在多线程并发下,需要加互斥锁,如果put()不加锁,就很容易破坏内部链表,造成get()死循 环,一直hung住。这里有一个来自淘宝的例子,有对此现象的详细分析:https://gist.github.com/1081908
        但是在MSDP的这个例子中,由于ReentrantReadWriteLock 读写锁的存在,put()和get()方法是互斥,不会有上述读写竞争的问题。
        Google后发现这是个普遍存在的问题,其根结在于LinkedHashMap的get()方法会改变数据链表。我们来看一下LinkedHashMap的实现代码:

    [java] view plain copy
     
     在CODE上查看代码片派生到我的代码片
    1. public V get(Object key) {  
    2.         Entry<K,V> e = (Entry<K,V>)getEntry(key);  
    3.         if (e == null)  
    4.                 return null;  
    5.         e.recordAccess(this);  
    6.         return e.value;  
    7. }  
    8.   
    9. void recordAccess(HashMap<K,V> m) {  
    10.         LinkedHashMap<K,V> lm = (LinkedHashMap<K,V>)m;  
    11.         if (lm.accessOrder) {  
    12.                 lm.modCount++;  
    13.                 remove();  
    14.                 addBefore(lm.header);  
    15.         }  
    16. }  
    17.   
    18. void transfer(HashMap.Entry[] newTable) {  
    19.         int newCapacity = newTable.length;  
    20.         for (Entry<K,V> e = header.after; e != header; e = e.after) {  
    21.                 int index = indexFor(e.hash, newCapacity);  
    22.                 e.next = newTable[index];  
    23.                 newTable[index] = e;  
    24.         }  
    25. }     

    前面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()方法。

    http://blog.csdn.net/wawmg/article/details/19482041

  • 相关阅读:
    101. Symmetric Tree(js)
    100. Same Tree(js)
    99. Recover Binary Search Tree(js)
    98. Validate Binary Search Tree(js)
    97. Interleaving String(js)
    96. Unique Binary Search Trees(js)
    95. Unique Binary Search Trees II(js)
    94. Binary Tree Inorder Traversal(js)
    93. Restore IP Addresses(js)
    92. Reverse Linked List II(js)
  • 原文地址:https://www.cnblogs.com/softidea/p/5488012.html
Copyright © 2011-2022 走看看