java中的引用對象

時間 2019-11-07

標籤 java 引用對象欄目 Java 简体版

原文原文鏈接

參考reference 詳解java

java中使用Reference對象來描述全部的引用對象算法

referent表示被引用的對象。一個Reference可能有4種狀態：Active、Pending、Enqueued、Inactive

在構造Reference時能夠決定是否指定 ReferenceQueue，會有不一樣的狀態變動，另一旦狀態變成Inactive,狀態就不會再作任何變動

ReferenceQueue 與 Reference 之間的合做

當GC發生時，被回收的對象會添加到Pending列表中，經過Reference的next字段來構建Pending鏈表。在Reference的靜態代碼塊，則會啓動RefenrenceHandler數組

static {
    ...
 Thread handler = new ReferenceHandler(tg, "Reference Handler");
   /* If there were a special system-only priority greater than
    * MAX_PRIORITY, it would be used here
    */
   handler.setPriority(Thread.MAX_PRIORITY);
   handler.setDaemon(true);
   handler.start();
    ...
}
複製代碼

並設置爲最大的優先級，它負責將pending中的元素添加到ReferenceQueue，緩存

private static class ReferenceHandler extends Thread {
     public void run() {
           for (;;) {
               Reference r;
               synchronized (lock) {
                   if (pending != null) {
                       r = pending;
                       Reference rn = r.next;
                       pending = (rn == r) ? null : rn;
                       r.next = r;
                   } else {
                       try {
                           lock.wait();
                       } catch (InterruptedException x) { }
                       continue;
                   }
               }
               // Fast path for cleaners
               if (r instanceof Cleaner) {
                   ((Cleaner)r).clean();
                   continue;
               }
               //存在ReferenceQueue時，將pending中的元素入隊列
               ReferenceQueue q = r.queue;
               if (q != ReferenceQueue.NULL) q.enqueue(r);
           }
       }
   }
複製代碼

ReferenceQueue提供對列的功能，出隊和入隊，當ReferenceQueue做爲參數被提供時，這意味着用戶一旦從ReferenceQueue中獲取到元素，也就能夠知道，這個對象要被回收了，以此達到一種通知的效果bash

強引用、軟引用、弱引用與虛引用

強引用。好比經過 new 生成的對象，這類可確保不會被GC回收掉
軟引用。一旦內存即將溢出，就把這類對象都回收掉,適用於內存敏感的緩存使用
弱引用。每次垃圾回收均可以回收這些引用對象
虛引用。與對象的生存無關，僅提供通知機制

虛引用必定要提供ReferenceQueue,由於它沒法返回引用爲null，若是不提供，那麼連通知的機制都沒法實現了網絡

軟引用回收策略細節

軟引用不只考慮內存，還會考慮referent的使用狀況和建立時間來決定是否該回收。Hotspot會讀取當前堆剩餘的內存，以及配置參數XX:SoftRefLRUPolicyMSPerMB(每M數據應該存活的毫秒數)函數

void LRUMaxHeapPolicy::setup() {
  size_t max_heap = MaxHeapSize;
  max_heap -= Universe::get_heap_used_at_last_gc();
  max_heap /= M;
  //剩餘空間可以存的以M爲單位的數據應該存活的時間
  _max_interval = max_heap * SoftRefLRUPolicyMSPerMB;
  assert(_max_interval >= 0,"Sanity check");
}

// The oop passed in is the SoftReference object, and not
// the object the SoftReference points to.
bool LRUCurrentHeapPolicy::should_clear_reference(oop p,
                                                  jlong timestamp_clock) {
  jlong interval = timestamp_clock - java_lang_ref_SoftReference::timestamp(p);
  assert(interval >= 0, "Sanity check");

  // The interval will be zero if the ref was accessed since the last scavenge/gc.
 
  if(interval <= _max_interval) {
    return false;
  }

  return true;
}
複製代碼

軟引用自身攜帶timestamp和clock,其中clock由GC更新，timestamp每次get的時候，若是和clock不一致則更新oop

public T get() {
    T o = super.get();
    if (o != null && this.timestamp != clock)
        this.timestamp = clock;
    return o;
}
複製代碼

若是再上一次GC以後，有過訪問記錄，那麼當前的GC確定不會回收軟引用，這也就意味着，軟引用若是一直沒有回收，升級到老年代，在OOM以前，有可能出現頻繁的Full GCui

WeakHashMap 對弱引用的使用

weakHashMap在 get/put/remove/resize等方法中均使用了expungeStaleEntries,去掉多餘的信息this

private final ReferenceQueue<Object> queue = new ReferenceQueue<>();
...
 private void expungeStaleEntries() {
    //從註冊的隊列中拿到了值
    for (Object x; (x = queue.poll()) != null; ) {
        synchronized (queue) {
            Entry<K,V> e = (Entry<K,V>) x;
          ...
          if (p == e) {
             e.value = null; // Help GC
             size--;
              ...
            }
        }
    }
}
複製代碼

若是從註冊的隊列中拿到了對應的元素，那麼就自動刪掉，這裏就是利用了ReferenceQueue承擔通知的角色，以及弱引用的GC就回收性質

Cleaner與native內存回收

在ReferenceHandler中注意到，若是pending中的Reference是一個Cleaner,則直接執行clean

public void clean() {
    if (!remove(this))
        return;
    ...
    //以前沒有執行過要clean的，如今執行
    thunk.run();
    ...
}
}
複製代碼

以DirectByteBuffer爲例，在使用時，就會建立一個Cleaner

DirectByteBuffer(int cap) { 
    ...
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}
private static class Deallocator
    implements Runnable
{
    public void run() {
        if (address == 0) {
            // Paranoia
            return;
        }
        unsafe.freeMemory(address);
        address = 0;
        Bits.unreserveMemory(size, capacity);
    }
}
複製代碼

java中經過ByteBuffer.allocateDirect就能夠建立，若是DirectByteBuffer被回收，此時惟一引用DirectByteBuffer的是一個虛引用，因爲垃圾回收的做用，DirectByteBuffer會處於pending狀態，觸發Native內存的回收釋放

參考直接內存

延伸一點網絡讀寫過程非直接內存轉換成直接內存的行爲，javaNio中寫數據IOUtil.write實現中能夠看到

static long write(FileDescriptor fd, ByteBuffer[] bufs, int offset, int length,
                      NativeDispatcher nd){
     ...
      if (!(buf instanceof DirectBuffer)) {
         //分配直接內存
         ByteBuffer shadow = Util.getTemporaryDirectBuffer(rem);
         shadow.put(buf);
         shadow.flip();
         vec.setShadow(iov_len, shadow);
         buf.position(pos);  // temporarily restore position in user buffer
         buf = shadow;
         pos = shadow.position();
     }
     ...
     
 }
複製代碼

會發現若是要將一個byte數組對象傳給native，會先轉換成直接內存再操做，這是由於native代碼訪問數組必須保證訪問的時候，byte[]對象不能移動，也就是被"pin"釘住，此時要麼是暫停GC（GC算法有可能要移動對象），要麼是假設換成native的消耗是可接受的，並且I/O操做都很慢，這裏就選擇了後者

Finalizer

Finalizer自身會啓動一個線程，它本身的工做就是一直從ReferenceQueue中拉取對應的元素並執行它的runFinalizer方法

private static class FinalizerThread extends Thread {
        FinalizerThread(ThreadGroup g) {
            super(g, "Finalizer");
        }
        public void run() {
            for (;;) {
                try {
                    Finalizer f = (Finalizer)queue.remove();
                    f.runFinalizer();
                } catch (InterruptedException x) {
                    continue;
                }
            }
        }
    }

    static {
        ThreadGroup tg = Thread.currentThread().getThreadGroup();
        for (ThreadGroup tgn = tg;
             tgn != null;
             tg = tgn, tgn = tg.getParent());
        Thread finalizer = new FinalizerThread(tg);
        finalizer.setPriority(Thread.MAX_PRIORITY - 2);
        finalizer.setDaemon(true);
        finalizer.start();
    }
複製代碼

值得注意的是，Finalizer它自己的構造函數是private,只能經過虛擬機自身來執行register操做,具體的時機根據RegisterFinalizersAtInit參數來決定，若是值爲true,那麼在構造函數返回以前調用註冊

//vmSymbols.hpp
...
template(object_initializer_name,                   "<init>") 
...
do_intrinsic(_Object_init,              java_lang_Object, object_initializer_name, void_method_signature,        F_R)   \

//c1_GraphBuilder.cpp
void GraphBuilder::method_return(Value x) {
//RegisterFinalizersAtInit爲true
  if (RegisterFinalizersAtInit &&
      method()->intrinsic_id() == vmIntrinsics::_Object_init) {
    call_register_finalizer();
 }
複製代碼

不然在分配好空間對象以後，再註冊

instanceOop instanceKlass::allocate_instance(TRAPS) {
  assert(!oop_is_instanceMirror(), "wrong allocation path");
  bool has_finalizer_flag = has_finalizer(); // Query before possible GC
  int size = size_helper();  // Query before forming handle.

  KlassHandle h_k(THREAD, as_klassOop());

  instanceOop i;

  i = (instanceOop)CollectedHeap::obj_allocate(h_k, size, CHECK_NULL);
  if (has_finalizer_flag && !RegisterFinalizersAtInit) {
   //RegisterFinalizersAtInit爲false
    i = register_finalizer(i, CHECK_NULL);
  }
  return i;
}
複製代碼

註冊執行以下

instanceOop instanceKlass::register_finalizer(instanceOop i, TRAPS) {
  if (TraceFinalizerRegistration) {
    tty->print("Registered ");
    i->print_value_on(tty);
    tty->print_cr(" (" INTPTR_FORMAT ") as finalizable", (address)i);
  }
  instanceHandle h_i(THREAD, i);
  // Pass the handle as argument, JavaCalls::call expects oop as jobjects
  JavaValue result(T_VOID);
  JavaCallArguments args(h_i);
  //finalizer_register_method即經過Finalizer找到的register
  methodHandle mh (THREAD, Universe::finalizer_register_method());
  JavaCalls::call(&result, mh, &args, CHECK_NULL);
  return h_i();
}
複製代碼

runFinalizer執行以下

private void runFinalizer() {
    synchronized (this) {
        if (hasBeenFinalized()) return;
        remove();
    }
    try {
        Object finalizee = this.get();
        if (finalizee != null && !(finalizee instanceof java.lang.Enum)) {
            invokeFinalizeMethod(finalizee);
            /* Clear stack slot containing this variable, to decrease
               the chances of false retention with a conservative GC */
            finalizee = null;
        }
    } catch (Throwable x) { }
    super.clear();
}
複製代碼

則是先看是否是已經執行過，執行過就返回，這裏能夠獲得以下三點信息

對象的finalize()方法只會執行一次。
若是在第一次執行finalize的時候讓對象強行恢復引用，則能夠逃過第一次的GC，可是因爲第二次不會再執行，此時則會被回收掉
對於Finalizer對象自己，因爲它存在內部的unfinalized對象構建的強引用，第一次GC執行，只是在等待runFinalizer的執行，若是執行了，而且以前沒有執行過纔會從 unfinalized列表中進行刪掉，從而不可達，再第二次GC的時候回收了Finalizer自己

執行finalize()方法具體細節以下

JNIEXPORT void JNICALL
Java_java_lang_ref_Finalizer_invokeFinalizeMethod(JNIEnv *env, jclass clazz,
                                                  jobject ob)
{
    jclass cls;
    jmethodID mid;

    cls = (*env)->GetObjectClass(env, ob);
    if (cls == NULL) return;
    mid = (*env)->GetMethodID(env, cls, "finalize", "()V");
    //沒有finalize什麼都不作
    if (mid == NULL) return;
    //執行
    (*env)->CallVoidMethod(env, ob, mid);
}
複製代碼