四、

一種代替最終化的選擇

在前面一節(jié)中的示例還存在一種不確定性可能：JVM并不能保證它在最終化隊(duì)列中調(diào)用對象的終結(jié)器的順序。而來自于所有類(應(yīng)用程序，庫，等等)的終結(jié)器都是被同等對待的。因此，一個(gè)占有大量內(nèi)存或一種稀有的本地資源的對象可能受阻于終結(jié)化隊(duì)列-它們排在那些終結(jié)器進(jìn)度緩慢的對象之后(不一定是惡意；也許由于懶惰的編程所致)。

看完上面達(dá)內(nèi)培訓(xùn)老師分享的的第一段內(nèi)容之后大家是不是已經(jīng)知道今天我們要為大家分享什么內(nèi)容了那？

為了避免這種類型的不確定性，你可以使用弱參考來代替最終化，例如使用死后鉤子(postmortem

hook)。如果用這種方式，你可以完全控制怎樣優(yōu)先化本地資源的回收問題，而代替依賴于JVM完成這件事情。下面的示例展示了這一技術(shù)：

final

class NativeImage3 extends WeakReference {

private

int nativeImg;//指向本地圖像數(shù)據(jù)

//它釋放本地圖像;隨后對它的調(diào)用將被忽略

private

native void disposeNative();

void

dispose() {

disposeNative();

refList.remove(this);

}

static

private ReferenceQueue refQueue;

static

private List refList;

static

ReferenceQueue referenceQueue() {return refQueue;}

NativeImage3(Image3

img) {

super(img,

refQueue);

refList.add(this);

}

}

public

class Image3 {

private

NativeImage3 nativeImg;

private

Point pos;

private

Dimension dim;

public

void dispose() { nativeImg.dispose(); }

}

Image3與Image2相同。NativeImage3相似于NativeImage2，但是它的最后清理依賴于弱參考而不是最終化。NativeImage3擴(kuò)展WeakReference，其參考是與之相關(guān)聯(lián)的Image3實(shí)例。請記住，當(dāng)一個(gè)參考對象的參考(此時(shí)是WeakReference)成為不可達(dá)的時(shí)，該參考對象就被添加到與之相關(guān)聯(lián)的參考隊(duì)列上。把nativeImg嵌入到參考對象本身就保證JVM會(huì)正確地把所需要的加入到隊(duì)列中(見圖6)。再強(qiáng)調(diào)一下，NativeImage3不應(yīng)該成為Image3的一個(gè)子類，這是基于前面所述原因。

圖6.把nativeImg嵌入到Reference對象本身

你可以決定是否一參考對象的參考物已經(jīng)被垃圾收集器以兩種方式回收：顯式地，在參考對象上調(diào)用get()方法；隱式地，通過觀察參考對象已經(jīng)在相關(guān)聯(lián)的參考隊(duì)列中排隊(duì)來實(shí)現(xiàn)。本示例中只使用了后者。

注意，參考對象僅能被垃圾收集器所發(fā)現(xiàn)并且被添加到它們的相關(guān)聯(lián)的參考隊(duì)列-只有它們本身是可達(dá)的時(shí)候。否則，它們就象任何其它不可達(dá)的對象一樣被簡單地回收。這就是為什么你把所有的NativeImage3實(shí)例添加到該靜態(tài)鏈表(實(shí)際上，任何數(shù)據(jù)結(jié)構(gòu)都會(huì)滿足)：為了確保它們保持為可達(dá)的并且當(dāng)它們的參考物成為不可達(dá)的時(shí)被處理。當(dāng)然，你還必須確保當(dāng)你釋放它們時(shí)(這是通過dispose()方法來實(shí)現(xiàn)的)你從該列表中刪除了它們。

當(dāng)在一個(gè)Image3實(shí)例上顯式地調(diào)用dispose()方法時(shí)，在該實(shí)例上不會(huì)發(fā)生隨后的最后清理；正確情況下也是這樣，因?yàn)檫@里不需要任何東西。這個(gè)dispose()方法從靜態(tài)列表中刪除NativeImage3實(shí)例，這樣當(dāng)它的相應(yīng)的Image3實(shí)例成為不可達(dá)的時(shí)它就是不可達(dá)的。并且，如前所述，不可達(dá)的參考對象并不被添加到它們相應(yīng)的參考隊(duì)列。相反，在所有前面的使用了最終化的示例中，可最終化的對象將總是被作最終化考慮-當(dāng)它們成為不可達(dá)的時(shí)候，無論你是否已顯式地釋放它們相關(guān)聯(lián)的本地資源。

JVM將保證，當(dāng)通過垃圾收集器發(fā)現(xiàn)一個(gè)Image3實(shí)例是不可達(dá)的時(shí)候，它會(huì)把它的相應(yīng)的NativeImage3實(shí)例添加到它的相關(guān)聯(lián)的參考隊(duì)列上去。然后，由你負(fù)責(zé)把它從隊(duì)列中刪除并釋放它的本地資源。這可以通過在一個(gè)"清理"線程中，用一個(gè)如下的循環(huán)來實(shí)現(xiàn)：

ReferenceQueue

refQueue =NativeImage3.referenceQueue();

while

(true) {

NativeImage3

nativeImg =(NativeImage3) refQueue.remove();

nativeImg.dispose();

}

這是一個(gè)過于簡單的實(shí)例。高級開發(fā)者能另外根據(jù)它們?nèi)绾涡枰獌?yōu)先化清理來確保不同參考對象關(guān)聯(lián)于不同的參考隊(duì)列。并且一個(gè)單個(gè)的"清理"線程可以查詢所有可用的參考隊(duì)列和根據(jù)要求的優(yōu)先級來從隊(duì)列中刪除對象。另外，你可以選擇展開(spread

out)回收資源，這樣它就會(huì)給應(yīng)用程序帶來更少的危險(xiǎn)性。

盡管用這種方式清理資源與使用最終化相比，明顯是更復(fù)雜些，但是這也是一種更為有力量和更為靈活的方式，而且可以最小化大量的與使用最終化相關(guān)的不確定性。另外，這種方式還十分相似于最終化實(shí)際在JVM內(nèi)實(shí)現(xiàn)的方式。對于那些顯式地使用很多本地資源并且需要更多控制的工程，我推薦對它們進(jìn)行清理時(shí)使用這一方法。而只要小心地使用最終化對于大多數(shù)另外的工程來說也就足夠了。

注意:本文僅討論了兩種類型的在使用最終化時(shí)產(chǎn)生的問題，也就是內(nèi)存和資源保留問題。最終化和參考類的使用也能帶來很微妙的同步問題。要想詳細(xì)了解這一點(diǎn)，可以參考Read

Hans-J.Boehm的《最終化，線程和基于Java技術(shù)的內(nèi)存模型》一文。

五、僅在必要時(shí)才使用最終化

本文簡短描述了最終化是怎樣在JVM中實(shí)現(xiàn)的。然后給出了有關(guān)內(nèi)存是怎樣不必被可最終化的對象所保留的示例并且概括了這種問題的解決方案。最后，我描述了一個(gè)方法-它使用弱參考來代替-這允許你用一種更為靈活和可預(yù)測的方式來執(zhí)行最后清理。

總結(jié)

以上是生活随笔為你收集整理的java 内存 四_java最终化的内存保留问题（4）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。