Dalvik虚拟机 Finalize 方法执行分析
毕业以后一直都在公司做虚拟机相关方面的开发，很多知识比较零碎，最近终于不用996了，可以空下来整理一下思路，写写博客做些总结。
Finalize 方法是java object在被heap完全回收之前，一定会被调用的方法。但是，虚拟机规范不保证该方法会在什么时候执行。前段时间，有个在native out of memory的bug，就是因为android的cts中有个leakmemory测试，会大量分分配native内存，然后在finalize中释放。但是由于lemur并没有及时的保证执行finalize方法导致虚拟地址用完程序crash。 所以建议，劲量不要依赖finalize方法去释放紧缺的资源。
一. Finalize方法
在虚拟机内部，对于有Finalize方法的object，其实是通过FinalizeReference来实现的。FinalizeReference类似与softReference，weakReference等，都派生自Reference类。
不同的是，softReference这些是在java代码中显式的new 出来的，比如：
private static final WeakReference<String> weakTest = new WeakReference<String>(new String("weak")); 但是，FinalizeReference不同，我们是不会显示的去new 一个Finalize reference的，换句话将对java层的程序员是透明的。
那么虚拟机是怎么处理的呢，是什么时候去new出Finalize reference的呢，并且怎样去执行finalize方法的呢？
这一切可以从虚拟机的class loader机制说起。虚拟机对class的load往细了说比较复杂，需要以后开专题讨论，但是概括的讲，就是几个过程：
FindClass->DefineClass->LoadClassFromDex->LoadMethod
在LoadMethod的阶段，虚拟机会去判断，该class的函数表中是否含有Finalize方法，如果存在Finalize方法就会给该class置一个标记位，对应与dalvik的代码 dalvik/vm/oo/class.cpp LoadMethodFromDex函数：
static void loadMethodFromDex(ClassObject* clazz, const DexMethod* pDexMethod,
Method* meth)
{
DexFile* pDexFile = clazz->pDvmDex->pDexFile;
const DexMethodId* pMethodId;
const DexCode* pDexCode;
pMethodId = dexGetMethodId(pDexFile, pDexMethod->methodIdx);
meth->name = dexStringById(pDexFile, pMethodId->nameIdx);
dexProtoSetFromMethodId(&meth->prototype, pDexFile, pMethodId);
meth->shorty = dexProtoGetShorty(&meth->prototype);
meth->accessFlags = pDexMethod->accessFlags;
meth->clazz = clazz;
meth->jniArgInfo = 0;
<span style="color:#FF0000;"> if (dvmCompareNameDescriptorAndMethod("finalize", "()V", meth) == 0) {
/*
* The Enum class declares a "final" finalize() method to
* prevent subclasses from introducing a finalizer. We don't
* want to set the finalizable flag for Enum or its subclasses,
* so we check for it here.
*
* We also want to avoid setting it on Object, but it's easier
* to just strip that out later.
*/
if (clazz->classLoader != NULL ||
strcmp(clazz->descriptor, "Ljava/lang/Enum;") != 0)
{
SET_CLASS_FLAG(clazz, CLASS_ISFINALIZABLE);
}
}</span> 这里有个问题，因为java/lang/object是含有finalize方法的，而其他的object包括class object都是继承自java/lang/object的，按理所，
<span style="color:#FF0000;"> dvmCompareNameDescriptorAndMethod("finalize", "()V", meth)
</span>
这个判断会永久成立，但是请注意，在dalvik中，loadMethodFromdex是在LinkClass之前做的，即这个时候，父类的method还没有被拷贝到当前load的class的函数表中。所以不存在以上问题。
完成标记以后，会需要在object从heap分配以后为该object执行add finalize reference操作，具体的时间点，可以根据虚拟机的实现选择
1. dalvik在执行java/lang/obect的init方法之前，代码在汇编解释器中, 代码在vm/mterp/out/InterpAsm-armv7-a.S
.L_OP_INVOKE_OBJECT_INIT_RANGE: /* 0xf0 */
/* File: armv5te/OP_INVOKE_OBJECT_INIT_RANGE.S */
/*
* Invoke Object.<init> on an object. In practice we know that
* Object's nullary constructor doesn't do anything, so we just
* skip it unless a debugger is active.
*/
FETCH(r1, 2) @ r1<- CCCC
GET_VREG(r0, r1) @ r0<- "this" ptr
cmp r0, #0 @ check for NULL
beq common_errNullObject @ export PC and throw NPE
ldr r1, [r0, #offObject_clazz] @ r1<- obj->clazz
ldr r2, [r1, #offClassObject_accessFlags] @ r2<- clazz->accessFlags
tst r2, #CLASS_ISFINALIZABLE @ is this class finalizable?
bne .LOP_INVOKE_OBJECT_INIT_RANGE_setFinal @ yes, go
.LOP_INVOKE_OBJECT_INIT_RANGE_setFinal:
EXPORT_PC() @ can throw
bl dvmSetFinalizable @ call dvmSetFinalizable(obj)
ldr r0, [rSELF, #offThread_exception] @ r0<- self->exception
cmp r0, #0 @ exception pending?
bne common_exceptionThrown @ yes, handle it
b .LOP_INVOKE_OBJECT_INIT_RANGE_finish
在dvmSetFinalizeable中，虚拟机会回调java层的libcore中FinalizeRerence中的add函数
void dvmSetFinalizable(Object *obj)
{
assert(obj != NULL);
Thread *self = dvmThreadSelf();
assert(self != NULL);
Method *meth = gDvm.methJavaLangRefFinalizerReferenceAdd;
assert(meth != NULL);
JValue unusedResult;
dvmCallMethod(self, meth, NULL, &unusedResult, obj);
}
FinalizeReference中add函数的实现在libcore/luni/src/main/java/java/lang/ref/Finalizereference.java中：
public static void add(Object referent) {
<span style="color:#FF0000;">FinalizerReference<?> reference = new FinalizerReference<Object>(referent, queue);</span>
synchronized (LIST_LOCK) {
reference.prev = null;
reference.next = head;
if (head != null) {
head.prev = reference;
}
head = reference;
}
}
在这里，终于看到在libcore中，我们new 出来了一个FinalizeReference，并且把含有Finalize的方法放到了新new出来的FinalizeReferce的referent域（具体实现可以去参看FinalizeReference的构造函数）。然后，以链表的形式串起来，head是FinalizeReferenc中的一个static域，
private static FinalizerReference<?> head = null;
用heap头引用住，可以确保Finalize reference可以在heap gc的mark阶段被mark到。
二 Finalize的 执行
上面我们详细的分析了一个含有finalize方法的object转化为一个Finalize reference的过程，下面我们分析，在Heap gc掉该object以后，finalize进行了那些操作，finalize方法又是怎么执行的。
Dalvik的garbage gc的算法使用的是CMS(Concurrent mark-sweep )的算法，即先通过root集mark所以live的object，然后sweep掉所有非mark过的object。Gc也是虚拟机里面很重要的一个模块，我们以后再讨论，在这里只是粗略的总结一下，以可以继续我们后面的讨论。典型的concurrent mark-sweep算法分为5个阶段：
1. initliaze phase
2. mark root
3. scan object
4. remark
5. reclaim
处理reference的主要在scan object， remark和reclaim阶段。
在scan object阶段，我们需要区分出所有的refence并且用链表把所有的相应的reference串起来，请注意这里串起来的是FinalizeReference，而不是含有finalize方法的object，但是object在该FinalizeReference的referent域中。具体的代码在vm/alloc/marksweep.cpp中：
static void scanDataObject(const Object *obj, GcMarkContext *ctx)
{
assert(obj != NULL);
assert(obj->clazz != NULL);
assert(ctx != NULL);
markObject((const Object *)obj->clazz, ctx);
scanFields(obj, ctx);
if (IS_CLASS_FLAG_SET(obj->clazz, CLASS_ISREFERENCE)) {
delayReferenceReferent((Object *)obj, ctx);
}
}
所有的reference都会进入delayReferencereferent中处理：
/*
* Process the "referent" field in a java.lang.ref.Reference. If the
* referent has not yet been marked, put it on the appropriate list in
* the gcHeap for later processing.
*/
static void delayReferenceReferent(Object *obj, GcMarkContext *ctx)
{
assert(obj != NULL);
assert(obj->clazz != NULL);
assert(IS_CLASS_FLAG_SET(obj->clazz, CLASS_ISREFERENCE));
assert(ctx != NULL);
GcHeap *gcHeap = gDvm.gcHeap;
size_t pendingNextOffset = gDvm.offJavaLangRefReference_pendingNext;
size_t referentOffset = gDvm.offJavaLangRefReference_referent;
Object *pending = dvmGetFieldObject(obj, pendingNextOffset);
Object *referent = dvmGetFieldObject(obj, referentOffset);
if (pending == NULL && referent != NULL && !isMarked(referent, ctx)) {
Object **list = NULL;
if (isSoftReference(obj)) {
list = &gcHeap->softReferences;
} else if (isWeakReference(obj)) {
list = &gcHeap->weakReferences;
<span style="color:#FF0000;"> } else if (isFinalizerReference(obj)) {
list = &gcHeap->finalizerReferences;</span>
} else if (isPhantomReference(obj)) {
list = &gcHeap->phantomReferences;
}
assert(list != NULL);
<span style="color:#FF6666;"> enqueuePendingReference(obj, list);</span>
}
}
至于isfinalizerReferenc(obj)的实现就很简单，只需要判断obj的clazz是否是java/lang/FinalizeReference即可。
enqueuPendingReference就是一个串链表的过程，这里就不贴代码了。
完成mark阶段以后，所有的reference都已经被被串在了一起，在remark完以后会真正的处理FinalizeReference中的object，把object取出来，mark 它然后把它从FinalizeReference中的引用中剥离出来，代码在： vm/alloc/marksweep.cpp中：
static void enqueueFinalizerReferences(Object **list)
{
assert(list != NULL);
GcMarkContext *ctx = &gDvm.gcHeap->markContext;
size_t referentOffset = gDvm.offJavaLangRefReference_referent;
size_t zombieOffset = gDvm.offJavaLangRefFinalizerReference_zombie;
bool hasEnqueued = false;
while (*list != NULL) {
<span style="color:#FF0000;"> Object *ref = dequeuePendingReference(list);
Object *referent = dvmGetFieldObject(ref, referentOffset);
if (referent != NULL && !isMarked(referent, ctx)) {
markObject(referent, ctx);
/* If the referent is non-null the reference must queuable. */
assert(isEnqueuable(ref));
dvmSetFieldObject(ref, zombieOffset, referent);
clearReference(ref);
enqueueReference(ref);
hasEnqueued = true;
}</span>
}
if (hasEnqueued) {
processMarkStack(ctx);
}
assert(*list == NULL);
}
有没有看到，红色的部分，正是从该FinalizeReference中取出了object，然后把referent从Referenct的referent域移到zombie域中，这两个域对对应于libcore FinalizeReference中的两个域。完了以后，还需要把该reference连到cleardReferences链表中：
/*
* Schedules a reference to be appended to its reference queue.
*/
static void enqueueReference(Object *ref)
{
assert(ref != NULL);
assert(dvmGetFieldObject(ref, gDvm.offJavaLangRefReference_queue) != NULL);
assert(dvmGetFieldObject(ref, gDvm.offJavaLangRefReference_queueNext) == NULL);
<span style="color:#FF0000;"> enqueuePendingReference(ref, &gDvm.gcHeap->clearedReferences);</span>
}
这个cleardReference是干嘛用的呢？ 答案看下面的函数：
void dvmEnqueueClearedReferences(Object **cleared)
{
assert(cleared != NULL);
if (*cleared != NULL) {
Thread *self = dvmThreadSelf();
assert(self != NULL);
<span style="color:#FF0000;"> Method *meth = gDvm.methJavaLangRefReferenceQueueAdd;</span>
assert(meth != NULL);
JValue unused;
Object *reference = *cleared;
<span style="color:#FF0000;">dvmCallMethod(self, meth, NULL, &unused, reference);</span>
*cleared = NULL;
}
} 是的，它正是用来将所有需要释放的Refernce返回到java 层用的。
至此，虚拟机内部对Finalize的处理已经结束，你是不是会很奇怪，因为搞了半天，貌似并没有地方真正地执行了object的finalize方法。
是的，真正的Finalize方法不是由虚拟机执行的，虚拟机只是把reference链接到需要处理的表中，真正的执行由Finalize Daemon进程来处理。 Finalize Daemon是一个守护进程，在那里监控Finalize Reference的queue中是否有新的reference进来，如果是，就去执行该object的finalize方法，代码在 libcore/libdvm/src/main/java/java/lang/Daemons.jav中：
@Override public void run() {
while (isRunning()) {
// Take a reference, blocking until one is ready or the thread should stop
try {
<span style="color:#FF0000;">doFinalize((FinalizerReference<?>) queue.remove());</span>
} catch (InterruptedException ignored) {
}
}
}
@FindBugsSuppressWarnings("FI_EXPLICIT_INVOCATION")
private void doFinalize(FinalizerReference<?> reference) {
<span style="color:#FF0000;"> FinalizerReference.remove(reference);
Object object = reference.get();</span>
reference.clear();
try {
finalizingStartedNanos = System.nanoTime();
finalizingObject = object;
synchronized (FinalizerWatchdogDaemon.INSTANCE) {
FinalizerWatchdogDaemon.INSTANCE.notify();
}
<span style="color:#FF0000;"> object.finalize();</span>
} catch (Throwable ex) {
// The RI silently swallows these, but Android has always logged.
System.logE("Uncaught exception thrown by finalizer", ex);
} finally {
finalizingObject = null;
}
}
} 但是又是谁来把reference放到Finalize Reference的queue中的呢，我从libcore中看到了两条路径，一条是从上面的cleard refernce queue中，它会被另一个daemon, ReferenceQueueDaemon处理，我们来看看它的处理过程：
@Override public void run() {
while (isRunning()) {
Reference<?> list;
try {
synchronized (ReferenceQueue.class) {
while (ReferenceQueue.unenqueued == null) {
ReferenceQueue.class.wait();
}
list = ReferenceQueue.unenqueued;
ReferenceQueue.unenqueued = null;
}
} catch (InterruptedException e) {
continue;
}
enqueue(list);
}
}
private void enqueue(Reference<?> list) {
while (list != null) {
Reference<?> reference;
// pendingNext is owned by the GC so no synchronization is required
if (list == list.pendingNext) {
reference = list;
reference.pendingNext = null;
list = null;
} else {
reference = list.pendingNext;
list.pendingNext = reference.pendingNext;
reference.pendingNext = null;
}
<span style="color:#FF0000;">reference.enqueueInternal();</span>
}
}
}
看最后的enqueuIntenal函数，该函数的在Reference类里面：
public final synchronized boolean enqueueInternal() {
if (queue != null && queueNext == null) {
<span style="color:#FF0000;"> queue.enqueue(this);</span>
queue = null;
return true;
}
return false;
}
对了，正是在该点，cleared queue中的Finalize Reference被转移到了Finalize 类中的queue中，然后被Finalize Daemon守护线程执行。
三 总结
我们从虚拟机和libcore的角度分析了Finalize方法的执行流程，到现在我们可以得出以下两点结论：
1. Finalize 方法被执行的时间不确定，所以不能依赖与它来释放紧缺的资源。时间不确定的原因是：
a. 虚拟机调用GC的时间不确定
b. Finalize daemon线程被调度到的时间不确定
2. Finalize方法只会被执行一次，即使对象被复活，如果已经执行过了Finalize方法，再次被gc时也不会再执行了，原因是：
含有Finalize方法的object是在new的时候由虚拟机生成了一个Finalize reference在来引用到该Object的，而在Finalize方法执行的时候，该object所对应的Finalize Reference会被释放掉，即使在这个时候把该object复活(即用强引用引用住该object)，再第二次被gc的时候由于没有了Finalize reference与之对应，所以Finalize方法不会再执行
3. 含有Finalize方法的object需要至少经过两轮GC才有可能被释放（所以在对内存回收速度有要求的情况下，）