目錄

?

內(nèi)存溢出解決記錄

內(nèi)存及GC 的相關(guān)參數(shù)

---

內(nèi)存溢出解決記錄

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

24-Sep-2019 10:39:06.628 嚴(yán)重 [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 嚴(yán)重 [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 嚴(yán)重 [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 嚴(yán)重 [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 嚴(yán)重 [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 嚴(yán)重 [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 嚴(yán)重 [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ù)日志內(nèi)容進(jìn)行解析：

[http-nio-9090-exec-xx]，這里的http-nio指得是tomcat連接器Connector的三種模式之一(bio/nio/apr)由于本次使用的是tomcat8.5版本，所以tomcat8.5連接器默認(rèn)是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請求默認(rèn)使用了HTTP/1.1協(xié)議處理，當(dāng)然tomcat8.5以上版本都支持了最新的HTTP/2.0協(xié)議。

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

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

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

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

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

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

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

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

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

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

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

jvisualvm監(jiān)測結(jié)果：

監(jiān)測總覽：

jvisualvm概述，如圖DUMP必須調(diào)出來才能在內(nèi)存溢出彈出錯誤信息：

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

堆內(nèi)存總覽：

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

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

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

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

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

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

---

內(nèi)存及GC 的相關(guān)參數(shù)

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

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

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

總結(jié)

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

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