前言

若干年前看了Java的四种引用类型,只是简单知道了不同类型的作用,但对其实现原理一直未能想明白,本文尝试结合jdk,openjdk6的部分源码分析弱引用实现的原理,供大家参考,部分技术细节没有仔细研究,如有疑问欢迎留言讨论

 实例分析

我们以WeakHashMap的处理过程为例介绍一个weak reference的生命周期,首先我们调用WeakHashMap的put方法放入对象到Map中,WeakHashMap的Entry继承了WeakReference

 

 
  
  1. private static class Entry<K,V> extends WeakReference<K> implements Map.Entry<K,V> { 
  2.         private V value; 
  3.         private final int hash; 
  4.         private Entry<K,V> next; 

下面是put的部分代码

 
  
  1. Entry<K,V> e = tab[i]; 
  2.         tab[i] = new Entry<K,V>(k, value, queue, h, e); 
  3.         if (++size >= threshold) 
  4.             resize(tab.length * 2); 
  5.         return null; 
  6.     } 

注意new Entry传递了一个reference queue到构造函数中,此构造函数最终会调用Reference的构造函数

 
  
  1. Reference(T referent, ReferenceQueue<? super T> queue) { 
  2.     this.referent = referent; 
  3.     this.queue = (queue == null) ? ReferenceQueue.NULL : queue; 
  4.     } 

referent是我们之前传入的hashmap的key对象,queue的作用是用来读取referent被回收的weak reference,生产者是谁后续介绍,此时WeakHashMap中已经存在了一个对象,先将key对象的strong ref制空并尝试触发gc,比如使用System.gc()来显式的触发gc,然后调用WeakHashMap的size方法返回集合的个数,绝大多数情况下会是0,这个过程中发生了什么呢?

第一步,key没有可达的strong ref,仅仅存在一个weak reference的referent变量仍然指向了key,触发GC时,以openjdk6的parNew为例,jvm在young generation gc时会尝试获取Reference对象里的静态全局锁

 

 
  
  1. /* Object used to synchronize with the garbage collector.  The collector 
  2.      * must acquire this lock at the beginning of each collection cycle.  It is 
  3.      * therefore critical that any code holding this lock complete as quickly 
  4.      * as possible, allocate no new objects, and avoid calling user code. 
  5.      */ 
  6.     static private class Lock { }; 
  7.     private static Lock lock = new Lock(); 

在openjdk6里的部分源代码,完整代码请参考instanceRefKlass.cpp文件

 
  
  1. void instanceRefKlass::acquire_pending_list_lock(BasicLock *pending_list_basic_lock) { 
  2.   // we may enter this with pending exception set 
  3.   PRESERVE_EXCEPTION_MARK;  // exceptions are never thrown, needed for TRAPS argument 
  4.   Handle h_lock(THREAD, java_lang_ref_Reference::pending_list_lock()); 
  5.   ObjectSynchronizer::fast_enter(h_lock, pending_list_basic_lock, false, THREAD); 
  6.   assert(ObjectSynchronizer::current_thread_holds_lock( 
  7.            JavaThread::current(), h_lock), 
  8.          "Locking should have succeeded"); 
  9.   if (HAS_PENDING_EXCEPTION) CLEAR_PENDING_EXCEPTION; 

 此处代码在parNew gc时执行,目的就是尝试获取全局锁,在gc完成后,jvm会将key被回收的weak reference组成一个queue并赋值到Reference的pending属性然后释放锁,参考方法:

 
  
  1. void instanceRefKlass::release_and_notify_pending_list_lock( 
  2.   BasicLock *pending_list_basic_lock) { 
  3.   // we may enter this with pending exception set 
  4.   PRESERVE_EXCEPTION_MARK;  // exceptions are never thrown, needed for TRAPS argument 
  5.   // 
  6.   Handle h_lock(THREAD, java_lang_ref_Reference::pending_list_lock()); 
  7.   assert(ObjectSynchronizer::current_thread_holds_lock( 
  8.            JavaThread::current(), h_lock), 
  9.          "Lock should be held"); 
  10.   // Notify waiters on pending lists lock if there is any reference. 
  11.   if (java_lang_ref_Reference::pending_list() != NULL) { 
  12.     ObjectSynchronizer::notifyall(h_lock, THREAD); 
  13.   } 
  14.   ObjectSynchronizer::fast_exit(h_lock(), pending_list_basic_lock, THREAD); 
  15.   if (HAS_PENDING_EXCEPTION) CLEAR_PENDING_EXCEPTION; 

在一次gc后,Reference对象的pending属性不再为空,让我们看看Reference的部分代码

首先是pending属性的说明:

 
  
  1. /* List of References waiting to be enqueued.  The collector adds 
  2.  * References to this list, while the Reference-handler thread removes 
  3.  * them.  This list is protected by the above lock object. 
  4.  */ 
  5. private static Reference pending = null

接下来是Reference中的内部类ReferenceHandler,它继承了Thread,看看run方法的代码

 
  
  1. public void run() { 
  2.         for (;;) { 
  3.  
  4.         Reference r; 
  5.         synchronized (lock) { 
  6.             if (pending != null) { 
  7.             r = pending; 
  8.             Reference rn = r.next; 
  9.             pending = (rn == r) ? null : rn; 
  10.             r.next = r; 
  11.             } else { 
  12.             try { 
  13.                 lock.wait(); 
  14.             } catch (InterruptedException x) { } 
  15.             continue
  16.             } 
  17.         } 
  18.  
  19.         // Fast path for cleaners 
  20.         if (r instanceof Cleaner) { 
  21.             ((Cleaner)r).clean(); 
  22.             continue
  23.         } 
  24.  
  25.         ReferenceQueue q = r.queue; 
  26.         if (q != ReferenceQueue.NULL) q.enqueue(r); 
  27.         } 
  28.     } 
  29.     } 

一旦jvm notify了前面提到的锁,这个线程就被激活并开始执行,作用是将之前jvm赋值过来的pending对象中的WeakReference对象enqueue到指定的队列中,比如WeakHashMap内部定义的ReferenceQueue属性

此时map的queue中保存了referent已经被回收的WeakReference队列,也就是map的Entry对象,当调用size方法时,内部首先调用expungStaleEntries方法清除被回收掉的Entry,代码如下

 

 
  
  1. private void expungeStaleEntries() { 
  2.     Entry<K,V> e; 
  3.         while ( (e = (Entry<K,V>) queue.poll()) != null) { 
  4.             int h = e.hash; 
  5.             int i = indexFor(h, table.length); 
  6.  
  7.             Entry<K,V> prev = table[i]; 
  8.             Entry<K,V> p = prev; 
  9.             while (p != null) { 
  10.                 Entry<K,V> next = p.next; 
  11.                 if (p == e) { 
  12.                     if (prev == e) 
  13.                         table[i] = next; 
  14.                     else 
  15.                         prev.next = next; 
  16.                     e.next = null;  // Help GC 
  17.                     e.value = null//  "   " 
  18.                     size--; 
  19.                     break
  20.                 } 
  21.                 prev = p; 
  22.                 p = next; 
  23.             } 
  24.         } 
  25.     } 

ok,就这样map的废弃Entry被clear,size返回为0

经过简单的测试程序发现:

一次gc未必能完全回收所有的weak ref

weak对象也可能会出现在old generation

 

参考:

 

http://weblogs.java.net/blog/2006/05/04/understanding-weak-references

 http://stackoverflow.com/questions/154724/when-would-you-use-a-weakhashmap-or-a-weakreference