目錄

?

內存溢出解決記錄

內存及GC 的相關參數(shù)

---

內存溢出解決記錄

項目平穩(wěn)運行到1個月5天時候，tomcat服務突然崩潰，首先查看下tomcat的日志，如下：

24-Sep-2019 10:39:06.628 嚴重 [http-nio-9090-exec-53]?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]?? ??? ?
in context with path [/web_project_resources] threw exception [Request processing failed;?? ??? ?
nested exception is java.lang.NullPointerException] with root cause?? ??? ?
java.lang.NullPointerException?? ??? ?
24-Sep-2019 10:40:55.663 嚴重 [http-nio-9090-exec-19]?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp] ?? ??? ?
in context with path [/web_project_resources] threw exception [Request processing failed;?? ??? ?
nested exception is java.lang.NullPointerException] with root cause?? ??? ?
java.lang.NullPointerException?? ??? ?
24-Sep-2019 10:44:46.997 嚴重 [http-nio-9090-exec-19] ?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]?? ??? ?
in context with path [/web_project_resources] threw exception [Handler processing failed;?? ??? ?
nested exception is java.lang.OutOfMemoryError: Java heap space] with root cause?? ??? ?
java.lang.OutOfMemoryError: Java heap space?? ??? ?
24-Sep-2019 10:45:29.173 嚴重 [http-nio-9090-exec-58]?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]?? ??? ?
in context with path [/web_project_resources] threw exception [Handler processing failed;?? ??? ?
nested exception is java.lang.OutOfMemoryError: Java heap space] with root cause?? ??? ?
java.lang.OutOfMemoryError: Java heap space?? ??? ?
24-Sep-2019 10:45:29.173 嚴重 [http-nio-9090-exec-57]?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]?? ??? ?
in context with path [/web_project_resources] threw exception [Handler processing failed;?? ??? ?
nested exception is java.lang.OutOfMemoryError: Java heap space] with root cause?? ??? ?
java.lang.OutOfMemoryError: Java heap space?? ??? ?
24-Sep-2019 10:45:29.173 嚴重 [http-nio-9090-exec-56]?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]?? ??? ?
in context with path [/web_project_resources] threw exception [Handler processing failed;?? ??? ?
nested exception is java.lang.OutOfMemoryError: Java heap space] with root cause?? ??? ?
java.lang.OutOfMemoryError: Java heap space?? ??? ?
24-Sep-2019 10:45:29.174 嚴重 [http-nio-9090-exec-18]?? ??? ?
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]?? ??? ?
in context with path [/web_project_resources] threw exception [Request processing failed; ?? ??? ?
nested exception is java.lang.NullPointerException] with root cause?? ??? ?
java.lang.NullPointerException

根據(jù)日志內容進行解析：

[http-nio-9090-exec-xx]，這里的http-nio指得是tomcat連接器Connector的三種模式之一(bio/nio/apr)由于本次使用的是tomcat8.5版本，所以tomcat8.5連接器默認是NIO模式(tomcat7以及之前使用BIO)如果使用tomcat7及以前版本想配置成nio模式需要在conf/server.xml中<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />改成<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443" />

另外Http請求默認使用了HTTP/1.1協(xié)議處理，當然tomcat8.5以上版本都支持了最新的HTTP/2.0協(xié)議。

說句題外話，tomcat對http/2.0的支持實際是從tomcat9開始的，Apache Tomcat 9.0.0.M1 是 9.0.x 的第一個里程碑版本，提供 9.0.x 的新特性早期預覽，有如下值得關注的改進：

①新增 HTTP/2 支持和 TLS 虛擬主機
②實現(xiàn)當前 Servlet 4.0 規(guī)范草案
③BIO connectors 不再支持 Windows Itanium 和 Comet
comet取消，因為http2.0 加入了 server push的功能。

不過，現(xiàn)在已經把http2.0的支持移植到了tomcat8.5版本中。

“exec”表達執(zhí)行，exec-xx后面接的數(shù)字只的是tomcat此時執(zhí)行的線程，所以[http-nio-9090-exec-xx]是tomcat
處理當前請求的線程名字。tomcat內部有一個處理任務請求的線程池，有請求的時候會被放在線程池中執(zhí)行，請求處理結束返回給瀏覽器后，線程池回收線程。

org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [tug_ciimp]
in context with path [/web_project_resources] threw exception [Request processing failed;
nested exception is java.lang.NullPointerException] with root cause

這段話的意思其實就是說tomcat在執(zhí)行名為tug_ciimp這個servlet容器時，這個容器上下文/web_project_resources
這個路徑的時候拋出異常，該異常因為root用戶引起，請求程序失敗，發(fā)生嵌套的異常為：空指針異常(NullPointerException)

同理，解析出：[Handler processing failed;nested exception is java.lang.OutOfMemoryError:
Java heap space] with root cause java.lang.OutOfMemoryError: Java heap space
這個異常是處理程序失敗，產生Java堆內存溢出。

而且根據(jù)線程名，http-nio-9090-exec-19是在發(fā)生完NullPointerException，經過大約4分鐘后發(fā)生堆內存溢出的異常。
解析完這些log后，再看看實際的程序運行背景：

在tomcat啟動時，并未發(fā)生啟動異常。tomcat服務器中有4個程序在同時運行，并不只有tug_ciimp這個程序，且這4個
程序毫無關聯(lián)。在啟動后，系統(tǒng)運行一切正常，當啟動到第10天左右時候，產生內存溢出這個異常。第一次發(fā)生此異常
只是把tomcat重啟，系統(tǒng)恢復正常運行。又間隔大約10多天時間又發(fā)生內存溢出。
為了把這個定時炸彈解決掉，準備采取以下措施，從網上找出內存溢出的可能情況：

1.java運行內存分配不足，啟動參數(shù)內存值設定的過小。有幾個地方：一是開發(fā)環(huán)境中eclipse.ini中，?? ?
二是tomcat的啟動文件中catalina.bat/catalina.sh中。因為不是開發(fā)環(huán)境，所以eclipse.ini去掉。?? ?
2.代碼中存在死循環(huán)或循環(huán)產生過多重復的對象實體。?? ?
3.集合類中有對對象的引用，使用完后未清空，使得JVM不能回收；?? ?
4.創(chuàng)建的對象持續(xù)增加，未得到及時清理，日積月累使內存溢出。?? ?
5.一次性提取大量數(shù)據(jù)到內存的地方（10萬數(shù)據(jù)以上）?? ?
6.某個線程執(zhí)行時間過長，那么就很危險了，占用的內存無法釋放。容易造成內存的溢出。

總結完以上問題，需要重點排查以下幾點：?? ??? ??? ?
1.檢查代碼中是否有死循環(huán)或遞歸調用。?? ??? ??? ?
2.檢查是否有大循環(huán)重復產生新對象實體。?? ??? ??? ?
3.檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存?? ??? ??? ?
溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有?? ??? ??? ?
可能引起內存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。?? ??? ??? ?
4.檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得?? ??? ??? ?
這些對象不能被GC回收。?? ??? ??? ?
有了以上這幾點內存溢出的情況，不過根據(jù)實際背景分析出，基本不會是內存分配不足，如果內存分配有問題在啟動?? ??? ??? ?
時候就會報異常，所以先排除1之外剩余四點都有可能。根據(jù)項目實際使用情況，當前處于試運行階段，出現(xiàn)一次性?? ??? ??? ?
提取大量數(shù)據(jù)的可能性也不大，所以首先從2、3、4、5這幾點著手，由于項目的代碼很多，一個一個代碼排查很笨拙?? ??? ??? ?
所以先采取以下方案進行觀察：
首先選擇jvisualvm工具，來查看到堆內存中各個對象的數(shù)量以及占用的內存大小。?? ?
如果找到有大量的自定義對象一直無法釋放，可能距離定位到問題就不遠了。

jvisualvm監(jiān)測結果：

監(jiān)測總覽：

jvisualvm概述，如圖DUMP必須調出來才能在內存溢出彈出錯誤信息：

通過jconsole監(jiān)測結果，參數(shù)總覽：

堆內存總覽：

根據(jù)將近6天時間持續(xù)監(jiān)測，發(fā)現(xiàn)cup、內存、類、線程等一直很平穩(wěn)，沒有持續(xù)升高現(xiàn)象，但是CPU偶爾會有突發(fā)性升高并會很快的下降回到正常。通過類實例數(shù)監(jiān)測結果，對象所占內存也并不大。通過監(jiān)測圖還可看出，雖然結果運行比較平穩(wěn)，但是通過檢測工具發(fā)現(xiàn)堆初始值和最大值分別是128m和256m，并且離最大值比較近，所以突發(fā)的大數(shù)據(jù)量導致內存暴漲的可能性比較大。(本來水面離堤壩最高點比較接近的情況下又下了場大雨，導致決堤)

所以目前從兩個方向去處理這個問題：

1.修改tomcat的內存參數(shù)，讓內存參數(shù)加大。
2.減少應用中單次請求數(shù)據(jù)量過大的情況，比如，對數(shù)據(jù)查詢時做分頁處理，其它操作時也分批次。幾個定時任務之間
不在同一時刻執(zhí)行。(但是通過log發(fā)生時間，推斷跟定時任務關系不大)
所以，先把內存參數(shù)調大，再觀測一段時間。

由于在windows server服務器的tomcat是通過系統(tǒng)服務啟動tomcat服務，所以在TOMCAT_HOME/bin/catalina.bat?? ?
中添加是無效的，windows服務執(zhí)行的是bin\tomcat.exe.他讀取注冊表中的值,而不是catalina.bat的設置。?? ?
所以，需要在注冊表中進行修改，ctrl+R，輸入regedit后，出現(xiàn)注冊表，路徑為：?? ?
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Tomcat8\Parameters\Java?? ?
此路徑下的Options?? ?
經過嘗試在Options的最下面加入 ?? ?
-Xms128M?? ?
-Xmx1024M?? ?
并重啟tomcat服務后，并不起作用，嘗試在catalina.bat下添加：?? ?
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "?? ?
重啟服務，以及重新安裝tomcat系統(tǒng)服務還是不起作用。?? ?
windows server重新安裝tomcat系統(tǒng)服務步驟如下：?? ?
CMD 命令進入到 Tomcat 的 bin 目錄下，先停掉tomcat系統(tǒng)服務，執(zhí)行service remove 服務名稱?? ?
再輸入 service install 服務名稱，再裝載上tomcat系統(tǒng)服務，tomcat系統(tǒng)服務裝配完畢后，?? ?
進入tomcat的bin目錄下，找到tomcat8w.exe，雙擊點開

在此處，把初始內存和最大內存更改后，加入jmx連接，并定義好連接端口12003(不要與其它服務沖突即可)?? ??? ??? ?
-Dcom.sun.management.jmxremote.port=12003?? ??? ??? ?
-Dcom.sun.management.jmxremote.ssl=false?? ??? ??? ?
-Dcom.sun.management.jmxremote.authenticate=false?? ??? ??? ?
用系統(tǒng)服務重啟tomcat，然后啟動jconsole和jvisualvm連接

自從更改完初始參數(shù)后，經過兩個多月使用，沒再發(fā)生內存溢出問題。

---

內存及GC 的相關參數(shù)

?? 內存相關設置(32位系統(tǒng)Heap 最大支持2GB，64位以上無限制)?? ??? ?
?? -Xms：初始堆(Heap)大小，默認3670k。當空閑堆內存小于40%時，JVM 就會增大堆內存直到-Xmx 所設置的最大值，?? ??? ?
可以通過-XX:MinHeapFreeRatio=n 設置其比例。默認是物理內存的1/64。?? ??? ?
?? -Xmx：最大堆(Heap)大小，默認64m。當空閑堆內存大于70%時，JVM 會減少堆內存直到-Xms 所設置的最小值，可?? ??? ?
以通過-XX:MaxHeapFreeRatio=n 設置其比例。默認是物理內存的1/4。?? ??? ?
?? -Xmn：新生代大小，增大新生代后會相應減小老年代大小。此值對系統(tǒng)性能影響較大，Java 官方推薦配置為整個?? ??? ?
堆大小的3/8。?? ??? ?
?? -Xss：設置每個線程棧的大小。Java1.5 以后每個線程棧默認大小為1M，之前每個線程棧默認大小為256K。?? ??? ?
可以根據(jù)應用的線程所需內存大小進行調整。一般情況下默認值已經能滿足絕大部分情景的應用，如果想更進一步優(yōu)化?? ??? ?
則需要非常細致的測試。在相同物理內存下，減小這個值能生成更多的線程，進程中可容納線程數(shù)量與很多因素有關，?? ??? ?
感興趣的可以詳細了解下，據(jù)說可以達到6500個以上。?? ??? ?
?? -XX:MinHeapFreeRatio=40：如果發(fā)現(xiàn)空閑堆內存占到整個預估上限值的40%，則增大上限值。?? ??? ?
?? -XX:MaxHeapFreeRatio=70：如果發(fā)現(xiàn)空閑堆內存占到整個預估上限值的70%，則收縮預估上限值。?? ??? ?
?? -XX:NewRatio=2：設置年輕代和老年代的比值。例如：n=3，則表示年輕代與老年代比值為1:3，年輕代占整個年?? ??? ?
輕代與老年代之和的1/4。?? ??? ?
?? -XX:SurvivorRatio=8：Eden 與Survivor 的占用比例。例如8表示，一個survivor 區(qū)占用 1/8 的Eden 內存，?? ??? ?
即1/10的新生代內存，此處需注意年輕代有2個survivor 區(qū)，所以比例為1:10。?? ??? ?
?? -XX:TargetSurvivorRatio=50：實際使用的survivor 空間大小占比。默認是47%，最高90%。?? ??? ?
?? -XX:MaxPermSize=64m：設置持久代(即方法區(qū))占整個堆內存的最大值。?? ??? ?
?? -XX:MaxTenuringThreshold=0：設置對象最大年齡。即對象在在Eden 與Survivor 區(qū)之間被復制的次數(shù)，每?? ??? ?
被復制一次就增加1歲，默認值為15。如果設置為0的話，則Eden 中對象不經過Survivor 區(qū)直接進入老年代。?? ??? ?
Heap size 的大小是Young Generation 和Tenured Generaion 之和。?? ??? ?
注意1：在JVM中如果98％的時間是用于GC且可用的Heap size 不足2％的時候將拋出此異常信息。?? ??? ?
注意2：Heap Size最大不要超過可用物理內存的80％，一般的要將-Xms和-Xmx選項設置為相同，而-Xmn為1/4的-Xmx值。?? ??? ?
Tomcat啟動內存設置：?? ??? ?
如果需要對tomcat啟動內存參數(shù)做設置，則修改TOMCAT_HOME/bin/catalina.bat，?? ??? ?
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：?? ??? ?
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m?? ??? ?
或修改catalina.sh?? ??? ?
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：?? ??? ?
JAVA_OPTS="$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m"?? ??? ?
另一種做法對tomcat容器，可以在啟動時對jvm設置內存限度。對tomcat，可以在catalina.bat中添加：?? ??? ?
set CATALINA_OPTS=-Xms128M -Xmx256M?? ??? ?
set JAVA_OPTS=-Xms128M -Xmx256M?? ??? ?
或者把%CATALINA_OPTS%和%JAVA_OPTS%代替為-Xms128M -Xmx256M

堆內存和非堆內存?? ??? ??? ??? ?
“Java 虛擬機具有一個堆，堆是運行時數(shù)據(jù)區(qū)域，所有類實例和數(shù)組的內存均從此處分配。堆是在Java虛擬機啟動時?? ??? ??? ??? ?
創(chuàng)建的。在JVM中堆之外的內存稱為非堆內存(Non-heap memory)”。可以看出JVM主要管理兩種類型的內存：堆和非堆。?? ??? ??? ??? ?
簡單來說堆就是Java代碼可及的內存，是留給開發(fā)人員使用的；非堆就是JVM留給自己用的，所以方法區(qū)、JVM內部處理?? ??? ??? ??? ?
或優(yōu)化所需的內存(如JIT編譯后的代碼緩存)、每個類結構(如運行時常數(shù)池、字段和方法數(shù)據(jù))以及方法和構造方法?? ??? ??? ??? ?
的代碼都在非堆內存中。?? ??? ??? ??? ?
JVM主要管理兩種類型的內存：堆和非堆?? ??? ??? ??? ?
Heap memory Code Cache?? ??? ??? ??? ?
Eden Space?? ??? ??? ??? ?
Survivor Space?? ??? ??? ??? ?
Tenured Gen?? ??? ??? ??? ?
non-heap memory Perm Gen?? ??? ??? ??? ?
native heap?(I guess)?? ??? ??? ??? ?
堆內存?? ??? ??? ??? ?
Java虛擬機具有一個堆，堆是運行時數(shù)據(jù)區(qū)域，所有類實例和數(shù)組的內存均從此處分配。堆是在Java虛擬機啟動?? ??? ??? ??? ?
時創(chuàng)建的。對象的堆內存由稱為垃圾回收器的自動內存管理系統(tǒng)回收。?? ??? ??? ??? ?
堆的大小可以固定，也可以擴大和縮小。堆的內存不需要是連續(xù)空間。?? ??? ??? ??? ?
非堆內存?? ??? ??? ??? ?
Java虛擬機管理堆之外的內存（稱為非堆內存）。?? ??? ??? ??? ?
Java虛擬機具有一個由所有線程共享的方法區(qū)。方法區(qū)屬于非堆內存。它存儲每個類結構，如運行時常數(shù)池、字段和?? ??? ??? ??? ?
方法數(shù)據(jù)，以及方法和構造方法的代碼。它是在 Java 虛擬機啟動時創(chuàng)建的。?? ??? ??? ??? ?
方法區(qū)在邏輯上屬于堆，但Java虛擬機實現(xiàn)可以選擇不對其進行回收或壓縮。與堆類似，方法區(qū)的大小可以固定，也?? ??? ??? ??? ?
可以擴大和縮小。方法區(qū)的內存不需要是連續(xù)空間。?? ??? ??? ??? ?
除了方法區(qū)外，Java虛擬機實現(xiàn)可能需要用于內部處理或優(yōu)化的內存，這種內存也是非堆內存。例如，JIT編譯器需?? ??? ??? ??? ?
要內存來存儲從Java虛擬機代碼轉換而來的本機代碼，從而獲得高性能。?? ??? ??? ??? ?
各區(qū)概念解釋參照：?? ??? ??? ??? ?
https://www.cnblogs.com/kxm87/p/7205414.html?? ??? ??? ??? ?
https://blog.csdn.net/shiyong1949/article/details/52585256?? ??? ??? ??? ?
https://blog.csdn.net/zyc88888/article/details/80346409?? ??? ??? ??? ?
幾個基本概念?? ??? ??? ??? ?
Heap space：存放Instance。?? ??? ??? ??? ?
Java Heap（堆）分為3個區(qū)：?? ??? ??? ??? ?
Eden Space（伊甸園）、Survivor Space(幸存者區(qū))、Old Gen（老年代-養(yǎng)老區(qū)）?? ??? ??? ??? ?
Young保存剛實例化的對象。當該區(qū)被填滿時，GC會將對象移到Old區(qū)。Permanent區(qū)則負責保存反射對象。?? ??? ??? ??? ?
Eden Space字面意思是伊甸園，對象被創(chuàng)建的時候首先放到這個區(qū)域，進行垃圾回收后，不能被回收的對象被放入?? ??? ??? ??? ?
到空的survivor區(qū)域。?? ??? ??? ??? ?
Survivor Space幸存者區(qū)，用于保存在Eden space內存區(qū)域中經過垃圾回收后沒有被回收的對象。Survivor有兩個，?? ??? ??? ??? ?
分別為To Survivor、 From Survivor，這個兩個區(qū)域的空間大小是一樣的。執(zhí)行垃圾回收的時候Eden區(qū)域不能被?? ??? ??? ??? ?
回收的對象被放入到空的survivor（也就是To Survivor，同時Eden區(qū)域的內存會在垃圾回收的過程中全部釋放），?? ??? ??? ??? ?
另一個survivor（即From Survivor）里不能被回收的對象也會被放入這個survivor（即To Survivor），然后?? ??? ??? ??? ?
To Survivor 和 From Survivor的標記會互換，始終保證一個survivor是空的。?? ??? ??? ??? ?
?? ??? ??? ????
?Eden Space和Survivor Space都屬于新生代，新生代中執(zhí)行的垃圾回收被稱之為Minor GC（因為是對新生代進?? ??? ??? ??? ?
行垃圾回收，所以又被稱為Young GC），每一次Young GC后留下來的對象age加1。?? ??? ??? ??? ?
注：GC為Garbage Collection，垃圾回收。?? ??? ??? ??? ?
Old Gen老年代，用于存放新生代中經過多次垃圾回收仍然存活的對象，也有可能是新生代分配不了內存的大對象會?? ??? ??? ??? ?
直接進入老年代。經過多次垃圾回收都沒有被回收的對象，這些對象的年代已經足夠old了，就會放入到老年代。?? ??? ??? ??? ?
當老年代被放滿的之后，虛擬機會進行垃圾回收，稱之為Major GC。由于Major GC除并發(fā)GC外均需對整個堆進行掃描和回收，因此又稱為Full GC。?? ??? ??? ??? ?
總結：heap區(qū)即堆內存，整個堆大小=年輕代大小 + 老年代大小。堆內存默認為物理內存的1/64(<1GB)；默認空余?? ??? ??? ??? ?
堆內存小于40%時，JVM就會增大堆直到-Xmx的最大限制，可以通過MinHeapFreeRatio參數(shù)進行調整；默認空余堆內?? ??? ??? ??? ?
存大于70%時，JVM會減少堆直到-Xms的最小限制，可以通過MaxHeapFreeRatio參數(shù)進行調整。?? ??? ??? ??? ?
非heap區(qū)又分：?? ??? ??? ??? ?
Code Cache(代碼緩存區(qū))、Perm Gen（永久代）、Jvm Stack(java虛擬機棧)、Local Method Statck(本地方法棧)。?? ??? ??? ??? ?
Code Cache代碼緩存區(qū)，它主要用于存放JIT所編譯的代碼。CodeCache代碼緩沖區(qū)的大小在client模式下默認最大?? ??? ??? ??? ?
是32m，在server模式下默認是48m，這個值也是可以設置的，它所對應的JVM參數(shù)為ReservedCodeCacheSize和?? ??? ??? ??? ?
InitialCodeCacheSize，可以通過如下的方式來為Java程序設置。?? ??? ??? ??? ?
-XX:ReservedCodeCacheSize=128m?? ??? ??? ??? ?
CodeCache緩存區(qū)是可能被充滿的，當CodeCache滿時，后臺會收到CodeCache is full的警告信息，如下所示：?? ??? ??? ??? ?
“CompilerThread0” java.lang.OutOfMemoryError: requested 2854248 bytes for Chunk::new. Out of swap space??? ??? ??? ??? ?
注：JIT編譯器是在程序運行期間，將Java字節(jié)碼編譯成平臺相關的二進制代碼。正因為此編譯行為發(fā)生在程序運行?? ??? ??? ??? ?
期間，所以該編譯器被稱為Just-In-Time編譯器。?? ??? ??? ??? ?
Perm Gen全稱是Permanent Generation space，是指內存的永久保存區(qū)域，因而稱之為永久代。這個內存區(qū)域用?? ??? ??? ??? ?
于存放Class和Meta的信息，Class在被 Load的時候被放入這個區(qū)域。因為Perm里存儲的東西永遠不會被JVM垃圾?? ??? ??? ??? ?
回收的，所以如果你的應用程序LOAD很多CLASS的話，就很可能出現(xiàn)PermGen space錯誤。默認大小為物理內存的1/64。?? ??
Perm Gen中放著類、方法的定義。持久代主要存放類定義、字節(jié)碼和常量等很少會變更的信息。?? ??? ??? ??? ?
jvm Stack區(qū)域放著方法參數(shù)、局域變量等的引用，方法執(zhí)行順序按照棧的先入后出方式。?? ??? ??? ??? ?
HotSpot虛擬機GC算法采用分代收集算法：?? ??? ??? ??? ?
1、一個人（對象）出來（new 出來）后會在Eden Space（伊甸園）無憂無慮的生活，直到GC到來打破了他們平靜?? ??? ??? ??? ?
的生活。GC會逐一問清楚每個對象的情況，有沒有錢（此對象的引用）啊，因為GC想賺錢呀，有錢的才可以敲詐嘛。?? ??? ???
然后富人就會進入Survivor Space（幸存者區(qū)），窮人的就直接kill掉。?? ??? ??? ??? ?
2、并不是進入Survivor Space（幸存者區(qū)）后就保證人身是安全的，但至少可以活段時間。GC會定期（可以自定義）?? ??? ??? ??? ?
會對這些人進行敲詐，億萬富翁每次都給錢，GC很滿意，就讓其進入了Genured Gen(養(yǎng)老區(qū))。萬元戶經不住幾次敲詐?? ??? ??? ? 就沒錢了，GC看沒有啥價值啦，就直接kill掉了。?? ??? ??? ??? ?
3、進入到養(yǎng)老區(qū)的人基本就可以保證人身安全啦，但是億萬富豪有的也會揮霍成窮光蛋，只要錢沒了，GC還是kill掉。?? ??? ??? ???
分區(qū)的目的：新生區(qū)由于對象產生的比較多并且大都是朝生夕滅的，所以直接采用標記-清理算法。而養(yǎng)老區(qū)生命力很?? ??? ??? ??? ?
強，則采用復制算法，針對不同情況使用不同算法。

堆內存分配?? ??? ??? ?
JVM初始分配的堆內存由-Xms指定，默認是物理內存的1/64；?? ??? ??? ?
JVM最大分配的堆內存由-Xmx指定，默認是物理內存的1/4。?? ??? ??? ?
默認空余堆內存小于40%時，JVM就會增大堆直到-Xmx的最大限制；?? ??? ??? ?
空余堆內存大于70%時，JVM會減少堆直到-Xms的最小限制。?? ??? ??? ?
因此服務器一般設置-Xms、-Xmx 相等以避免在每次GC 后調整堆的大小。?? ??? ??? ?
說明：如果-Xmx 不指定或者指定偏小，應用可能會導致java.lang.OutOfMemory錯誤，此錯誤來自JVM，?? ??? ??? ?
不是Throwable的，無法用try…catch捕捉。?? ??? ??? ?
非堆內存分配?? ??? ??? ?
1.JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；?? ??? ??? ?
2.由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。?? ??? ??? ?
還有一說：MaxPermSize缺省值和-server -client選項相關，-server選項下默認MaxPermSize為64m，-client選項?? ??? ??? ?
下默認MaxPermSize為32m。這個沒有實驗過。?? ??? ??? ?
3. XX:MaxPermSize設置過小會導致java.lang.OutOfMemoryError: PermGen space 就是內存益出。?? ??? ??? ?
4. 為什么會內存益出：?? ??? ??? ?
這一部分內存用于存放Class和Meta的信息，Class在被 Load的時候被放入PermGen space區(qū)域，它和存放Instance?? ??? ??? ?
的Heap區(qū)域不同。?? ??? ??? ?
GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的APP會LOAD很多CLASS 的話,?? ??? ??? ?
就很可能出現(xiàn)PermGen space錯誤。?? ??? ??? ?
5. 這種錯誤常見在web服務器對JSP進行pre compile的時候。?? ??? ??? ?
JVM內存限制(最大值)?? ??? ??? ?
1. 首先JVM內存限制于實際的最大物理內存，假設物理內存無限大的話，JVM內存的最大值跟操作系統(tǒng)有很大的關系。?? ??? ??? ?
簡單的說就32位處理器雖然可控內存空間有4GB,但是具體的操作系統(tǒng)會給一個限制，這個限制一般是2GB-3GB?? ??? ??? ?
（一般來說Windows系統(tǒng)下為1.5G-2G，Linux系統(tǒng)下為2G-3G），而64bit以上的處理器就不會有限制了。?? ??? ??? ?
2. 為什么有的機器我將-Xmx和-XX:MaxPermSize都設置為512M之后Eclipse可以啟動，而有些機器無法啟動？?? ??? ??? ?
通過上面對JVM內存管理的介紹我們已經了解到JVM內存包含兩種：堆內存和非堆內存，另外JVM最大內存首先取決于?? ??? ??? ?
實際的物理內存和操作系統(tǒng)。所以說設置VM參數(shù)導致程序無法啟動主要有以下幾種原因：?? ??? ??? ?
?參數(shù)中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize；?? ??? ??? ?
?-Xmx的值和-XX:MaxPermSize的總和超過了JVM內存的最大限制，比如當前操作系統(tǒng)最大內存限制，或者實際的物理?? ??? ??? ?
內存等等。說到實際物理內存這里需要說明一點的是，如果你的內存是1024MB，但實際系統(tǒng)中用到的并不可能是1024MB，?? ????
因為有一部分被硬件占用了。?? ??? ??? ?
3.如果你有一個雙核的CPU，也許可以嘗試這個參數(shù): -XX:+UseParallelGC讓GC可以更快的執(zhí)行（只是JDK5里對GC新增加的參數(shù)）?? ??? ??? ?
4.如果你的WEB APP下都用了大量的第三方jar，其大小超過了服務器jvm默認的大小，那么就會產生內存益出問題了。?? ??? ??? ?
解決方法：設置MaxPermSize大小。?? ??? ??? ?
增加服務器啟動的JVM參數(shù)設置：?? ??? ??? ?
?-Xms128m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m?? ??? ??? ?
如tomcat，修改TOMCAT_HOME/bin/catalina.sh，在echo“Using CATALINA_BASE: $CATALINA_BASE”上面?? ??? ??? ?
加入以下行：?? ??? ??? ?
JAVA_OPTS=”-server -XX:PermSize=64M -XX:MaxPermSize=128m?? ??? ??? ?
5. 建議：將相同的第三方jar文件移置到tomcat/shared/lib目錄下，這樣可以減少jar 文檔重復占用內存?? ??? ??? ?
補充說明：?? ??? ??? ?
PermSize和MaxPermSize指明虛擬機為java永久生成對象（Permanate generation）如，class對象、方法對象這些?? ??? ??? ?
可反射（reflective）對象分配內存限制，這些內存不包括在Heap（堆內存）區(qū)之中。?? ??? ??? ?
MaxPermSize缺省值和-server -client選項相關：-server選項下默認MaxPermSize為64m、-client選項下默認?? ??? ??? ?
MaxPermSize為32m。?? ??? ??? ?
申請一塊內存的過程?? ??? ??? ?
1.JVM會試圖為相關Java對象在Eden中初始化一塊內存區(qū)域?? ??? ??? ?
2.當Eden空間足夠時，內存申請結束。否則到下一步?? ??? ??? ?
3.JVM試圖釋放在Eden中所有不活躍的對象（這屬于1或更高級的垃圾回收）；釋放后若Eden空間仍然不足以放入?? ??? ??? ?
新對象，則試圖將部分Eden中活躍對象放入Survivor區(qū)/OLD區(qū)?? ??? ??? ?
4.Survivor區(qū)被用來作為Eden及OLD的中間交換區(qū)域，當OLD區(qū)空間足夠時，Survivor區(qū)的對象會被移到Old區(qū)，否則會?? ??? ??? ?
被保留在Survivor區(qū)。?? ??? ??? ?
5.當OLD區(qū)空間不夠時，JVM會在OLD區(qū)進行完全的垃圾收集（0級）?? ??? ??? ?
6.完全垃圾收集后，若Survivor及OLD區(qū)仍然無法存放從Eden復制過來的部分對象，導致JVM無法在Eden區(qū)為新對象?? ??? ??? ?
創(chuàng)建內存區(qū)域，則出現(xiàn)”out of memory錯誤”?? ??? ??? ?
內存回收算法?? ??? ??? ?
Java中有四種不同的回收算法，對應的啟動參數(shù)為:?? ??? ??? ?
?–XX:+UseSerialGC?? ??? ??? ?
?–XX:+UseParallelGC?? ??? ??? ?
?–XX:+UseParallelOldGC?? ??? ??? ?
?–XX:+UseConcMarkSweepGC

總結

以上是生活随笔為你收集整理的tomcat内存溢出全记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。