内存溢出异常
Java堆
存儲對象實(shí)例，我們只要不斷創(chuàng)建對象，并且保證GC Roots到對象之間有可達(dá)路徑來避免垃圾回收機(jī)制清除這些對象，就會(huì)在對象達(dá)到最大堆容量限制后產(chǎn)生內(nèi)存溢出異常。 java.lang.OutOfMemoryError：Java heap space. 原因分析：確認(rèn)內(nèi)存中對象是否是必要的。也就是首先要分清楚到底是出現(xiàn)了內(nèi)存泄露還是內(nèi)存溢出。 內(nèi)存映像分析工具，檢查是否是內(nèi)存泄露，還是內(nèi)存溢出。
?
2.4.2?虛擬機(jī)棧和本地方法棧溢出
?????????本地變量表。StackOverflowError異常。（棧幀太大）
?
2.4.3?方法區(qū)?+?運(yùn)行時(shí)常量池溢出
?????????運(yùn)行時(shí)常量池：字符串常量池?String.intern()
方法區(qū)溢出
?????????存放Class的相關(guān)信息，如類名、訪問修飾符、常量池、字段描述、方法描述等。
?????????思路：運(yùn)行時(shí)產(chǎn)生大量的類去填滿方法區(qū)，直到溢出。
?
???????? JVM上的動(dòng)態(tài)語言。
?
2.4.4?本機(jī)直接內(nèi)存溢出
???????? NIO相關(guān)。明顯的特征：Heap Dump文件中不會(huì)看見明顯的異常，即OOM后Dump文件很小。
?
?
| java.lang.OutOfMemoryError: PermGen space |
? ? ? ? 但問題是為什么這些王牌的開源會(huì)出現(xiàn)同一個(gè)問題呢，那么是不是更基礎(chǔ)的原因呢？tomcat在Q&A很隱晦的回答了這一點(diǎn)，我們知道這個(gè)問題，但這個(gè)問題是由一個(gè)更基礎(chǔ)的問題產(chǎn)生。?
? ? ? ? 于是有人對更基礎(chǔ)的JVM做了檢查，發(fā)現(xiàn)了問題的關(guān)鍵。原來SUN 的JVM把內(nèi)存分了不同的區(qū)，其中一個(gè)就是permenter區(qū)用來存放用得非常多的類和類描述。本來SUN設(shè)計(jì)的時(shí)候認(rèn)為這個(gè)區(qū)域在JVM啟動(dòng)的時(shí)候就固定了，但他沒有想到現(xiàn)在動(dòng)態(tài)會(huì)用得這么廣泛。而且這個(gè)區(qū)域有特殊的垃圾收回機(jī)制，現(xiàn)在的問題是動(dòng)態(tài)加載類到這個(gè)區(qū)域后，gc根本沒辦法回收！ ?
原因：
? ? ? ? PermGen space的全稱是Permanent Generation space,是指內(nèi)存的永久保存區(qū)域，這塊內(nèi)存主要是被JVM存放Class和Meta信息的,Class在被Loader時(shí)就會(huì)被放到PermGen space中，它和存放類實(shí)例(Instance)的Heap區(qū)域不同,GC(Garbage Collection)不會(huì)在主程序運(yùn)行期對PermGen space進(jìn)行清理，所以如果你的應(yīng)用中有很CLASS的話,就很可能出現(xiàn)PermGen space錯(cuò)誤，這種錯(cuò)誤常見在web服務(wù)器對JSP進(jìn)行pre compile的時(shí)候。如果你的WEB APP下都用了大量的第三方j(luò)ar, 其大小超過了jvm默認(rèn)的大小(4M)那么就會(huì)產(chǎn)生此錯(cuò)誤信息了。
解決方法：
1. 手動(dòng)設(shè)置MaxPermSize大小?
修改TOMCAT_HOME/bin/catalina.bat（Linux下為catalina.sh），在
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：?
? ? ? ? set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m?
catalina.sh下為：?
? ? ? ? JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m" ?| java.lang.OutOfMemoryError: Java heap space |
?
解釋：
Heap size 設(shè)置
? ? ? ? JVM堆的設(shè)置是指java程序運(yùn)行過程中JVM可以調(diào)配使用的內(nèi)存空間的設(shè)置.JVM在啟動(dòng)的時(shí)候會(huì)自動(dòng)設(shè)置Heap size的值，其初始空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項(xiàng)可進(jìn)行設(shè)置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。?
? ? ? ? 提示：在JVM中如果98％的時(shí)間是用于GC且可用的Heap size 不足2％的時(shí)候?qū)伋龃水惓Ｐ畔ⅰ?
? ? ? ? 提示：Heap Size 最大不要超過可用物理內(nèi)存的80％，一般的要將-Xms和-Xmx選項(xiàng)設(shè)置為相同，而-Xmn為1/4的-Xmx值。
?
解決方法：
手動(dòng)設(shè)置Heap size?
修改TOMCAT_HOME/bin/catalina.bat，在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：?
或修改catalina.sh?在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：?
? ? ? ? JAVA_OPTS="$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m"?【JVM內(nèi)存分析及導(dǎo)致內(nèi)存溢出的不健壯代碼及解決辦法】http://my.oschina.net/flynewton/blog/7773 ?
一、JVM內(nèi)存區(qū)域組成?
java把內(nèi)存分四種：?
1、棧區(qū)（stack segment）— 由編譯器自動(dòng)分配釋放,存放函數(shù)的參數(shù)值，局部變量的值等，具體方法執(zhí)行結(jié)束之后，系統(tǒng)自動(dòng)釋放內(nèi)存資源?
2、堆區(qū)（heap segment） — 一般由程序員分配釋放，存放由new創(chuàng)建的對象和數(shù)組，jvm不定時(shí)查看這個(gè)對象，如果沒有引用指向這個(gè)對象就回收?
3、靜態(tài)區(qū)（data segment）— 存放全局變量，靜態(tài)變量和字符串常量，不釋放?
4、代碼區(qū)（code segment）— 存放程序中方法的二進(jìn)制代碼，而且是多個(gè)對象 共享一個(gè)代碼空間區(qū)域?
在方法（代碼塊）中定義一個(gè)變量時(shí)，java就在棧中為這個(gè)變量分配內(nèi)存空間，當(dāng)超過變量的作用域后，java會(huì)自動(dòng)釋放掉為該變量所分配的內(nèi)存空間；在堆中分配的內(nèi)存由java虛擬機(jī)的自動(dòng)垃圾回收器來管理，堆的優(yōu)勢是可以動(dòng)態(tài)分配內(nèi)存大小，生存期也不必事先告訴編譯器，因?yàn)樗窃谶\(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存的。缺點(diǎn)就是要在運(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存，存取速度較慢；棧的優(yōu)勢是存取速度比堆要快，缺點(diǎn)是存在棧中的數(shù)據(jù)大小與生存期必須是確定的無靈活性。?
java堆由Perm區(qū)和Heap區(qū)組成，Heap區(qū)則由Old區(qū)和New區(qū)組成，而New區(qū)又分為Eden區(qū), From區(qū), To區(qū)，Heap = {Old + NEW = { Eden, From, To } }，見圖1所示。
Heap區(qū)分兩大塊，一塊是 NEW Generation, 另一塊是Old Generation. 在New Generation中，有一個(gè)叫Eden的空間，主要是用來存放新生的對象，還有兩個(gè)Survivor Spaces（from,to）, 它們用來存放每次垃圾回收后存活下來的對象。在Old Generation中，主要存放應(yīng)用程序中生命周期長的內(nèi)存對象，還有個(gè)Permanent Generation，主要用來放JVM自己的反射對象，比如類對象和方法對象等。?
在New Generation塊中，垃圾回收一般用Copying的算法，速度快。每次GC的時(shí)候，存活下來的對象首先由Eden拷貝到某個(gè)Survivor Space, 當(dāng)Survivor Space空間滿了后, 剩下的live對象就被直接拷貝到Old Generation中去。因此，每次GC后，Eden內(nèi)存塊會(huì)被清空。在Old Generation塊中，垃圾回收一般用mark-compact的算法，速度慢些，但減少內(nèi)存要求.?
垃圾回收分多級，0級為全部(Full)的垃圾回收，會(huì)回收OLD段中的垃圾；1級或以上為部分垃圾回收，只會(huì)回收NEW中的垃圾，內(nèi)存溢出通常發(fā)生于OLD段或Perm段垃圾回收后，仍然無內(nèi)存空間容納新的Java對象的情況。?
根據(jù)GC的機(jī)制，程序的運(yùn)行會(huì)引起系統(tǒng)運(yùn)行環(huán)境的變化，增加GC的觸發(fā)機(jī)會(huì)。為了避免這些問題，程序的設(shè)計(jì)和編寫就應(yīng)避免垃圾對象的內(nèi)存占用和GC的開銷。顯示調(diào)用System.GC()只能建議JVM需要在內(nèi)存中對垃圾對象進(jìn)行回收，但不是必須馬上回收，一個(gè)是并不能解決內(nèi)存資源耗空的局面，另外也會(huì)增加GC的消耗。?
當(dāng)一個(gè)URL被訪問時(shí)，內(nèi)存申請過程如下：?
A. JVM會(huì)試圖為相關(guān)Java對象在Eden中初始化一塊內(nèi)存區(qū)域?
B. 當(dāng)Eden空間足夠時(shí)，內(nèi)存申請結(jié)束。否則到下一步?
C. JVM試圖釋放在Eden中所有不活躍的對象（這屬于1或更高級的垃圾回收）, 釋放后若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區(qū)?
D. Survivor區(qū)被用來作為Eden及OLD的中間交換區(qū)域，當(dāng)OLD區(qū)空間足夠時(shí)，Survivor區(qū)的對象會(huì)被移到Old區(qū)，否則會(huì)被保留在Survivor區(qū)?
E. 當(dāng)OLD區(qū)空間不夠時(shí)，JVM會(huì)在OLD區(qū)進(jìn)行完全的垃圾收集（0級）?
F. 完全垃圾收集后，若Survivor及OLD區(qū)仍然無法存放從Eden復(fù)制過來的部分對象，導(dǎo)致JVM無法在Eden區(qū)為新對象創(chuàng)建內(nèi)存區(qū)域，則出現(xiàn)"out of memory錯(cuò)誤"?
二、內(nèi)存溢出類型?
1、java.lang.OutOfMemoryError: PermGen space?
JVM管理兩種類型的內(nèi)存，堆和非堆。堆是給開發(fā)人員用的，是在JVM啟動(dòng)時(shí)創(chuàng)建；非堆是留給JVM自己用的，用來存放類的信息的。它和堆不同，運(yùn)行期內(nèi)GC不會(huì)釋放空間。如果web app用了大量的第三方j(luò)ar或者應(yīng)用有太多的class文件而恰好MaxPermSize設(shè)置較小，超出了也會(huì)導(dǎo)致這塊內(nèi)存的占用過多造成溢出，或者tomcat熱部署時(shí)侯不會(huì)清理前面加載的環(huán)境，只會(huì)將context更改為新部署的，非堆存的內(nèi)容就會(huì)越來越多。?
2、java.lang.OutOfMemoryError:?Java?heap space?
這種內(nèi)存溢出是最常見的情況之一，主要體現(xiàn)在Old區(qū)的溢出，產(chǎn)生的原因可能是：1) 設(shè)置的內(nèi)存參數(shù)過小(ms/mx, NewSize/MaxNewSize)；2) 程序問題。Heap space其默認(rèn)空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4。如果內(nèi)存剩余不到40％，JVM就會(huì)增大堆到Xmx設(shè)置的值，內(nèi)存剩余超過70％，JVM就會(huì)減小堆到Xms設(shè)置的值。所以服務(wù)器的Xmx和Xms設(shè)置一般應(yīng)該設(shè)置相同避免每次GC后都要調(diào)整虛擬機(jī)堆的大小。假設(shè)物理內(nèi)存無限大，那么JVM內(nèi)存的最大值跟操作系統(tǒng)有關(guān)，一般32位機(jī)是1.5g到3g之間，而64位的就不會(huì)有限制了。?
注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來。?
3、java.lang.OutOfMemoryError: c heap space?
系統(tǒng)對C Heap沒有限制，故C Heap發(fā)生問題時(shí)，Java進(jìn)程所占內(nèi)存會(huì)持續(xù)增長，直到占用所有可用系統(tǒng)內(nèi)存?
4、其他?
JVM有2個(gè)GC線程。第一個(gè)線程負(fù)責(zé)回收Heap的Young區(qū)。第二個(gè)線程在Heap不足時(shí)，遍歷Heap，將Young 區(qū)升級為Older區(qū)。Older區(qū)的大小等于-Xmx減去-Xmn，不能將-Xms的值設(shè)的過大，因?yàn)榈诙€(gè)線程被迫運(yùn)行會(huì)降低JVM的性能。?
為什么一些程序頻繁發(fā)生GC？有如下原因：?
a、程序內(nèi)調(diào)用了System.gc()或Runtime.gc()。?
b、一些中間件軟件調(diào)用自己的GC方法，此時(shí)需要設(shè)置參數(shù)禁止這些GC。?
c、Java的Heap太小，一般默認(rèn)的Heap值都很小。?
d、頻繁實(shí)例化���象，Release對象。此時(shí)盡量保存并重用對象，例如使用StringBuffer()和String()。?
如果你發(fā)現(xiàn)每次GC后，Heap的剩余空間會(huì)是總空間的50%，這表示你的Heap處于健康狀態(tài)。許多Server端的Java程序每次GC后最好能有65%的剩余空間?
三、JVM如何設(shè)置虛擬內(nèi)存?
提示：在JVM中如果98％的時(shí)間是用于GC且可用的Heap size 不足2％的時(shí)候?qū)伋龃水惓Ｐ畔ⅰ?
提示：Heap Size 最大不要超過可用物理內(nèi)存的80％，一般的要將-Xms和-Xmx選項(xiàng)設(shè)置為相同，而-Xmn為1/4的-Xmx值。?
提示：JVM初始分配的內(nèi)存由-Xms指定，默認(rèn)是物理內(nèi)存的1/64；JVM最大分配的內(nèi)存由-Xmx指定，默認(rèn)是物理內(nèi)存的1/4。默認(rèn)空余堆內(nèi)存小于40%時(shí)，JVM就會(huì)增大堆直到-Xmx的最大限制；空余堆內(nèi)存大于70%時(shí)，JVM會(huì)減少堆直到-Xms的最小限制。因此服務(wù)器一般設(shè)置-Xms、-Xmx相等以避免在每次GC 后調(diào)整堆的大小。?
提示：假設(shè)物理內(nèi)存無限大的話，JVM內(nèi)存的最大值跟操作系統(tǒng)有很大的關(guān)系。簡單的說就32位處理器雖然可控內(nèi)存空間有4GB,但是具體的操作系統(tǒng)會(huì)給一個(gè)限制，這個(gè)限制一般是2GB-3GB（一般來說Windows系統(tǒng)下為1.5G-2G，Linux系統(tǒng)下為2G-3G），而64bit以上的處理器就不會(huì)有限制了?
提示：注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來。?
提示：設(shè)置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old區(qū)如果不夠大會(huì)頻繁的觸發(fā)"主" GC ，大大降低了性能?
提示：增加Heap Size 雖然會(huì)降低GC的頻率，但也增加了每次GC的時(shí)間。并且GC運(yùn)行時(shí)，所有的用戶線程將暫停，也就是GC期間，Java應(yīng)用程序不做任何工作。?
提示：Heap Size 并不決定進(jìn)程的內(nèi)存使用量。進(jìn)程的內(nèi)存使用量要大于-Xmx定義的值，因?yàn)镴ava為其他任務(wù)分配內(nèi)存，例如每個(gè)線程的Stack等。?
提示：每個(gè)線程都有他自己的Stack，Stack Size 限制著線程的數(shù)量。如果Stack過大就好導(dǎo)致內(nèi)存溢漏。-Xss參數(shù)決定Stack大小，例如-Xss1024K。如果Stack太小，也會(huì)導(dǎo)致Stack溢漏。?
JVM使用-XX:PermSize設(shè)置非堆內(nèi)存初始值，默認(rèn)是物理內(nèi)存的1/64；由XX:MaxPermSize設(shè)置最大非堆內(nèi)存的大小，默認(rèn)是物理內(nèi)存的1/4。?
解決方法：手動(dòng)設(shè)置Heap size?
修改TOMCAT_HOME/bin/catalina.bat?
在"echo "Using CATALINA_BASE: $CATALINA_BASE""上面加入以下行：?
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"?
四、不健壯代碼的特征及解決辦法?
1、盡早釋放無用對象的引用。好的辦法是使用臨時(shí)變量的時(shí)候，讓引用變量在退出活動(dòng)域后，自動(dòng)設(shè)置為null，暗示垃圾收集器來收集該對象，防止發(fā)生內(nèi)存泄露。對于仍然有指針指向的實(shí)例，jvm就不會(huì)回收該資源,因?yàn)槔厥諘?huì)將值為null的對象作為垃圾，提高GC回收機(jī)制效率；?
2、我們的程序里不可避免大量使用字符串處理，避免使用String，應(yīng)大量使用StringBuffer，每一個(gè)String對象都得獨(dú)立占用內(nèi)存一塊區(qū)域；例如?
3、盡量少用靜態(tài)變量，因?yàn)殪o態(tài)變量是全局的，GC不會(huì)回收的；?
4、避免集中創(chuàng)建對象尤其是大對象，JVM會(huì)突然需要大量內(nèi)存，這時(shí)必然會(huì)觸發(fā)GC優(yōu)化系統(tǒng)內(nèi)存環(huán)境；顯示的聲明數(shù)組空間，而且申請數(shù)量還極大。?
5、盡量運(yùn)用對象池技術(shù)以提高系統(tǒng)性能；生命周期長的對象擁有生命周期短的對象時(shí)容易引發(fā)內(nèi)存泄漏，例如大集合對象擁有大數(shù)據(jù)量的業(yè)務(wù)對象的時(shí)候，可以考慮分塊進(jìn)行處理，然后解決一塊釋放一塊的策略。?
6、不要在經(jīng)常調(diào)用的方法中創(chuàng)建對象，尤其是忌諱在循環(huán)中創(chuàng)建對象。可以適當(dāng)?shù)氖褂胔ashtable，vector 創(chuàng)建一組對象容器，然后從容器中去取那些對象，而不用每次new之后又丟棄?
7、一般都是發(fā)生在開啟大型文件或跟數(shù)據(jù)庫一次拿了太多的數(shù)據(jù)，造成 Out Of Memory Error 的狀況，這時(shí)就大概要計(jì)算一下數(shù)據(jù)量的最大值是多少，并且設(shè)定所需最小及最大的內(nèi)存空間值。
【如何寫出會(huì)發(fā)生內(nèi)存泄露的Java代碼】 ? ? Java中，內(nèi)存泄漏就是存在一些被分配的對象，這些對象有下面兩個(gè)特點(diǎn)，首先，這些對象是可達(dá)的，即在有向圖中，存在通路可以與其相連；其次，這些對象是無用的，即程序以后不會(huì)再使用這些對象。如果對象滿足這兩個(gè)條件，這些對象就可以判定為Java中的內(nèi)存泄漏，這些對象不會(huì)被GC所回收，然而它卻占用內(nèi)存。 ========================================================================================
內(nèi)存泄露的例子:
Vector?v?=?new?Vector(10);
for?(int?i?=?1;?i<100;?i++)
{Object?o?=?new?Object();
v.add(o);
o?=?null;
} 首先理解什么是引用，什么是對象。
java中我們是通過引用來操作對象的。
比如Object?o?=?new?Object();
這里的o是引用，根據(jù)o能找到新創(chuàng)建的對象，但是o并不是這個(gè)對象。
打個(gè)比方，o就是一個(gè)門牌號，通過門牌號能找到放對象的地方。
v.add(o);就是你把門牌號放到里面了，也就是說v通過內(nèi)部的信息還能找到對象，對象不是垃圾。 ? ? 其實(shí)Java中不可能存在內(nèi)存泄漏，因?yàn)镚C會(huì)在必要的時(shí)候回收內(nèi)存。
這個(gè)例子沒有體現(xiàn)內(nèi)存泄漏，但是用來理解內(nèi)存泄漏的潛在發(fā)生可能還是可以的。
不需要那么復(fù)雜，一個(gè)非常簡單的例子就能說明問題：
Object?o1?=?new?Object();
Object?o2?=?o1;
o1?=?null;??//??這時(shí)o1指向的那個(gè)對象回收了嗎？沒有，因?yàn)樗€被o2引用著
o2?=?null;??//??這樣才能回收
實(shí)際應(yīng)用中，只要o2的作用域很小，不執(zhí)行o2=null也是沒有問題的，因?yàn)橹灰猳2過了它的生存期，它指向的對象就能被回收。
結(jié)論是，作用域越大的變量，越要引起重視，因?yàn)樗赡苷加弥承ο笠枚鴮?dǎo)致對象不能被回收。換句話說，盡可能地縮小變量的作用域——這也是你在Java中關(guān)于內(nèi)存方面能做的唯一努力了。 ? ?
A1：通過以下步驟可以很容易產(chǎn)生內(nèi)存泄露（程序代碼不能訪問到某些對象，但是它們?nèi)匀槐４嬖趦?nèi)存中）:
由于沒有了對類和類加載器的引用，ThreadLocal中的存儲就不能被訪問到。ThreadLocal持有該對象的引用，它也就持有了這個(gè)類及其類加載器的引用，類加載器持有它所加載的類的所有引用，這樣GC無法回收ThreadLocal中存儲的內(nèi)存。在很多JVM的實(shí)現(xiàn)中Java類和類加載器直接分配到permgen區(qū)域不執(zhí)行GC，這樣導(dǎo)致了更嚴(yán)重的內(nèi)存泄露。
?
這種泄露模式的變種之一就是如果你經(jīng)常重新部署以任何形式使用了ThreadLocal的應(yīng)用程序、應(yīng)用容器（比如Tomcat）會(huì)很容易發(fā)生內(nèi)存泄露（由于應(yīng)用容器使用了如前所述的線程，每次重新部署應(yīng)用時(shí)將使用新的類加載器）。
?
?
A2：
靜態(tài)變量引用對象
| 1 | class?MemorableClass { |
| 2 | ????static?final?ArrayList list =?new?ArrayList(100); |
| 3 | } |
調(diào)用長字符串的String.intern()
| 1 | String str=readString();?// read lengthy string any source db,textbox/jsp etc.. |
| 2 | // This will place the string in memory pool from which you cant remove |
| 3 | str.intern(); |
未關(guān)閉已打開流(文件，網(wǎng)絡(luò)等)
| 1 | try?{ |
| 2 | ????BufferedReader br =?new?BufferedReader(new?FileReader(inputFile)); |
| 3 | ????... |
| 4 | ????... |
| 5 | }?catch?(Exception e) { |
| 6 | ????e.printStacktrace(); |
| 7 | } |
未關(guān)閉連接
| 1 | try?{ |
| 2 | ????Connection conn = ConnectionFactory.getConnection(); |
| 3 | ????... |
| 4 | ????... |
| 5 | }?catch?(Exception e) { |
| 6 | ????e.printStacktrace(); |
| 7 | } |
JVM的GC不可達(dá)區(qū)域
比如通過native方法分配的內(nèi)存。
web應(yīng)用在application范圍的對象，應(yīng)用未重啟或者沒有顯式移除
getServletContext().setAttribute("SOME_MAP", map);
web應(yīng)用在session范圍的對象，未失效或者沒有顯式移除
session.setAttribute("SOME_MAP", map);
不正確或者不合適的JVM選項(xiàng)
比如IBM JDK的noclassgc阻止了無用類的垃圾回收
?
A3：如果HashSet未正確實(shí)現(xiàn)(或者未實(shí)現(xiàn))hashCode()或者equals(),會(huì)導(dǎo)致集合中持續(xù)增加“副本”。如果集合不能地忽略掉它應(yīng)該忽略的元素，它的大小就只能持續(xù)增長，而且不能刪除這些元素。
如果你想要生成錯(cuò)誤的鍵值對，可以像下面這樣做：
| 1 | class?BadKey { |
| 2 | ???// no hashCode or equals(); |
| 3 | ???public?final?String key; |
| 4 | ???public?BadKey(String key) {?this.key = key; } |
| 5 | } |
| 6 | ? |
| 7 | Map map = System.getProperties(); |
| 8 | map.put(new?BadKey("key"),?"value");?// Memory leak even if your threads die. |
A4：除了被遺忘的監(jiān)聽器，靜態(tài)引用，hashmap中key錯(cuò)誤/被修改或者線程阻塞不能結(jié)束生命周期等典型內(nèi)存泄露場景，下面介紹一些不太明顯的Java發(fā)生內(nèi)存泄露的情況，主要是線程相關(guān)的。
- Runtime.addShutdownHook后沒有移除，即使使用了removeShutdownHook，由于ThreadGroup類對于未啟動(dòng)線程的bug，它可能不被回收，導(dǎo)致ThreadGroup發(fā)生內(nèi)存泄露。
- 創(chuàng)建但未啟動(dòng)線程，與上面的情形相同
- 創(chuàng)建繼承了ContextClassLoader和AccessControlContext的線程，ThreadGroup和InheritedThreadLocal的使用，所有這些引用都是潛在的泄露，以及所有被類加載器加載的類和所有靜態(tài)引用等等。這對ThreadFactory接口作為重要組成元素整個(gè)j.u.c.Executor框架(java.util.concurrent)的影響非常明顯，很多開發(fā)人員沒有注意到它潛在的危險(xiǎn)。而且很多庫都會(huì)按照請求啟動(dòng)線程。
- ThreadLocal緩存，很多情況下不是好的做法。有很多基于ThreadLocal的簡單緩存的實(shí)現(xiàn)，但是如果線程在它的期望生命周期外繼續(xù)運(yùn)行ContextClassLoader將發(fā)生泄露。除非真正必要不要使用ThreadLocal緩存。
- 當(dāng)ThreadGroup自身沒有線程但是仍然有子線程組時(shí)調(diào)用ThreadGroup.destroy()。發(fā)生內(nèi)存泄露將導(dǎo)致該線程組不能從它的父線程組移除，不能枚舉子線程組。
- 使用WeakHashMap，value直接(間接)引用key，這是個(gè)很難發(fā)現(xiàn)的情形。這也適用于繼承Weak/SoftReference的類可能持有對被保護(hù)對象的強(qiáng)引用。
- 使用http(s)協(xié)議的java.net.URL下載資源。KeepAliveCache在系統(tǒng)ThreadGroup創(chuàng)建新線程，導(dǎo)致當(dāng)前線程的上下文類加載器內(nèi)存泄露。沒有存活線程時(shí)線程在第一次請求時(shí)創(chuàng)建，所以很有可能發(fā)生泄露。(在Java7中已經(jīng)修正了，創(chuàng)建線程的代碼合理地移除了上下文類加載器。)
- 使用InflaterInputStream在構(gòu)造函數(shù)(比如PNGImageDecoder)中傳遞new java.util.zip.Inflater()，不調(diào)用inflater的end()。僅僅是new的話非常安全，但如果自己創(chuàng)建該類作為構(gòu)造函數(shù)參數(shù)時(shí)調(diào)用流的close()不能關(guān)閉inflater，可能發(fā)生內(nèi)存泄露。這并不是真正的內(nèi)存泄露因?yàn)樗鼤?huì)被finalizer釋放。但這消耗了很多native內(nèi)存，導(dǎo)致linux的oom_killer殺掉進(jìn)程。所以這給我們的教訓(xùn)是：盡可能早地釋放native資源。
- java.util.zip.Deflater也一樣，它的情況更加嚴(yán)重。好的地方可能是很少用到Deflater。如果自己創(chuàng)建了Deflater或者Inflater記住必須調(diào)用end()。
轉(zhuǎn)載于:https://www.cnblogs.com/lsx1993/p/4631281.html
總結(jié)
- 上一篇： 原生APP与移动Web App的比较
- 下一篇： ios动态获取UILabel的高度和宽度