tomcat記憶體溢出原因分析與解決

來源:互聯網
上載者:User

標籤:tomcat記憶體溢出

網上有很多的介紹但都不全面,本文綜合了幾篇文章共同組從。

在生產環境中tomcat記憶體設定不好很容易出現記憶體溢出。造成記憶體原因是不一樣的,當然處理方式也不一樣。

  這雷根據平時遇到的情況和相關資料進行一個總結。常見的一般會有下面三種情況:

  1.OutOfMemoryError: Java heap space

  2.OutOfMemoryError: PermGen space

  3.OutOfMemoryError: unable to create new native thread.

  對於前兩種情況,在應用本身沒有記憶體泄露的情況下可以用設定tomcat jvm參數來解決。(-Xms -Xmx -XX: PermSize   -XX:MaxPermSize)

  最後一種可能需要調整作業系統和tomcat jvm參數同時調整才能達到目的。

  第一種:是堆溢出。

  在JVM中如果98%的時間是用於GC且可用的 Heap size 不足2%的時候將拋出此異常資訊。

  沒有記憶體泄露的情況下,調整-Xms -Xmx參數可以解決。

  -Xms:初始堆大小

  -Xmx:最大堆大小

  但堆的大小受下面三方面影響:

  1.相關作業系統的資料模型(32-bt還是64-bit)限制;(32位系統下,一般限制在1.5G~2G;我在2003 server 系統下(實體記憶體:4G和6G,jdk:1.6)測試 1612M,64為作業系統對記憶體無限制。)

  2.系統的可用虛擬記憶體限制;

  3.系統的可用實體記憶體限制。

  堆的大小可以使用 java -Xmx***M   version 命令來測試。支援的話會出現jdk的版本號碼,不支援會報錯。

  -Xms -Xmx一般配置成一樣比較好比如set JAVA_OPTS= -Xms1024m -Xmx1024m

  第二種:永久儲存地區溢出

   PermGen space的全稱是Permanent Generationspace,是指記憶體的永久儲存地區。這一部分用於存放Class和Meta的資訊,Class在被 Load的時候被放入PermGenspace地區,它和和存放Instance的Heap地區不同,GC(Garbage Collection)不會在主程式運行期對PermGenspace進行清理,所以如果你的APP會LOAD很多CLASS的話,就很可能出現 PermGenspace錯誤。這種錯誤常見在web伺服器對JSP進行precompile的時候。但目前的hibernate和spring項目中也 很容易出現這樣的問題。http://www.javaeye.com/topic/80620?page=1 的文章有討論的這個問題。可能是由於這些架構會動態class,而且jvm的gc是不會清理PemGen space的,導致記憶體溢出。

  這一個一般是加大-XX: PermSize   -XX:MaxPermSize 來解決問題。

  -XX: PermSize 永久儲存地區初始大小

  -XX: PermSize 永久儲存地區初始最大值

  這一般結合第一條使用,比如 set JAVA_OPTS= -Xms1024m -Xmx1024m   -XX: PermSize=128M -XX: PermSize=256M

   有一點需要注意:java -Xmx***M   version 命令來測試的最大堆記憶體是 -Xmx與 -XX: PermSize的和 比如系統支援最大的jvm堆大小事1.5G,那   -Xmx1024m   -XX: PermSize=768M 是無法啟動並執行。

  第三種:無法建立新的線程。

  這種現象比較少見,也比較奇怪,主要是和jvm與系統記憶體的比例有關。

  這種怪事是因為JVM已經被系統分配了大量的記憶體(比如1.5G),並且它至少要佔用可用記憶體的一半。有人發現,線上程個數很多的情況下,你分配給JVM的記憶體越多,那麼,上述錯誤發生的可能性就越大。

   產生這種現象的原因如下:每一個32位的進程最多可以使用2G的可用記憶體,因為另外2G被作業系統保留。這裡假設使用1.5G給JVM,那麼還餘下 500M可用記憶體。這500M記憶體中的一部分必須用於系統dll的載入,那麼真正剩下的也許只有400M,現在關鍵的地方出現了:當你使用Java建立一 個線程,在JVM的記憶體裡也會建立一個Thread對象,但是同時也會在作業系統裡建立一個真正的物理線程(參考JVM規範),作業系統會在餘下的400 兆記憶體裡建立這個物理線程,而不是在JVM的1500M的記憶體堆裡建立。在jdk1.4裡頭,預設的棧大小是256KB,但是在jdk1.5裡頭,預設的 棧大小為1M每線程,因此,在餘下400M的可用記憶體裡邊我們最多也只能建立400個可用線程。

  這樣結論就出來了,要想建立更多的線程,你必須減少分配給JVM的最大記憶體。還有一種做法是讓JVM宿主在你的JNI代碼裡邊。

  給出一個有關能夠建立線程的最大個數的估算公式:

  (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads

  對於jdk1.5而言,假設作業系統保留120M記憶體:

  1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads

  1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads

  在2000/XP/2003的boot.ini裡頭有一個啟動選項,好像是:/PAE /3G ,可以讓使用者進程最大記憶體擴充至3G,這時作業系統只能佔用最多1G的虛存。那樣應該可以讓JVM建立更多的線程。

  因此這種情況需要結合作業系統進行相關調整。

  因此:我們需要結合不同情況對tomcat記憶體配置進行不同的診斷才能從根本上解決問題。

說完了原因後如何設定呢?

這裡面有兩種情況:

擷取【】 SpringMVC+Mybatis架構整合源碼 項目 下載

1、當用控制台啟動的時候可以在,catalina.bat最前面加入 set JAVA_OPTS=-Xms128m -Xmx350m 。。。。

2、當用服務啟動的時候,設定的方法是不一樣的,這點很多人忽視。見圖如下,只有在這裡設定才生效,這個困擾了我一會。

650) this.width=650;" style="border-top:0px;border-right:0px;border-bottom:0px;border-left:0px;" src="http://img.my.csdn.net/uploads/201302/20/1361364767_8118.JPG" />

當然也可以在註冊表中進行配置,註冊表的位置如下:

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat7\Parameters

以上內容配置好後,應該不會出現這些問題,當然程式不能有記憶體流失。



tomcat記憶體溢出原因分析與解決

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.