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