2 回答

TA貢獻(xiàn)1802條經(jīng)驗(yàn) 獲得超5個(gè)贊
根據(jù)您的評(píng)論:
我正在嘗試了解內(nèi)存泄漏,所以我正在做的是打算......我正在尋找關(guān)于這兩種情況的解釋,以及第一種情況是否表示內(nèi)存泄漏而第二種情況不
簡(jiǎn)單來(lái)說,兩個(gè)錯(cuò)誤都表明JVM內(nèi)存不足,現(xiàn)在JVM是否因?yàn)閮?nèi)存泄漏而耗盡內(nèi)存是另一回事。
現(xiàn)在,來(lái)到你的第一個(gè)案例 - 是的,存在內(nèi)存泄漏(盡管是故意的),因?yàn)閮?nèi)部類持有封閉類的引用,因此使用創(chuàng)建的對(duì)象new LeakFactory()
有資格進(jìn)行 GC,但它們沒有被 GC,因?yàn)?code>Leak內(nèi)部類持有他們。
要更清楚地看到這一點(diǎn),請(qǐng)更改您的public class Leak{
to public static class Leak{
,您會(huì)注意到 JVM 將運(yùn)行更長(zhǎng)的時(shí)間,并且與您原來(lái)的非靜態(tài)Leak
內(nèi)部類相比,OOM 將在幾秒鐘后出現(xiàn)。

TA貢獻(xiàn)1876條經(jīng)驗(yàn) 獲得超6個(gè)贊
內(nèi)存泄漏是程序員無(wú)意中將內(nèi)存保留的時(shí)間超過應(yīng)有的時(shí)間的結(jié)果,這種無(wú)意的內(nèi)存使用會(huì)慢慢累積,直到?jīng)]有任何可分配的內(nèi)存為止。
在 Java 中,考慮到垃圾收集的性質(zhì)以及它實(shí)際上如何查看對(duì)象被引用的強(qiáng)度(或弱),泄漏內(nèi)存很難做到。
鑒于您必須自己有意識(shí)地啟動(dòng)所有這些類,因此沒有任何關(guān)于泄漏的爭(zhēng)論;你是故意這樣做的。您已經(jīng)創(chuàng)建了足夠多的引用,以至于耗盡了自己的內(nèi)存限制。
Java 中的內(nèi)存泄漏通常以比這更狡猾的方式表現(xiàn)出來(lái);一些引用保存在一個(gè)finalize()
方法中,該方法在類實(shí)際被垃圾收集之前不會(huì)被釋放,并且只有 VM 知道實(shí)際發(fā)生的時(shí)間(它可能永遠(yuǎn)不會(huì)發(fā)生)。值得慶幸的是,該方法很快就會(huì)消失,因此使用該方法看到泄漏的可能性至少會(huì)降低一點(diǎn)。
您也可能非常邪惡并Unsafe
使用該語(yǔ)言做事,但這足以表明大多數(shù)明智的 IDE 和工具集會(huì)在您手上出現(xiàn)重大內(nèi)存泄漏之前警告您這種用法。
所有這些都是為了說......不。您看到的異常表明您的內(nèi)存不足。它并不直接表示內(nèi)存泄漏。
添加回答
舉報(bào)