1.背景

雖然閱讀了各大牛的博客或文章,但并沒有找到特別全面的關于JVM內存分配方法的文章,很多都是復制黏貼

為了嚴謹,本文特別備注只介紹基于HotSpot VM虛擬機,并且基于JDK1.7的內存分配情況,有關GC的說法也是基于CMS的concurrent collection(而非G1),防止大牛拍磚.

目前主流的JVM就是HotSpot VM(其次還有J9 VM,Zing VM),目前各類博客文章也大多基于JDK1.7以前的版本進行闡述的.

(注:因為不同的虛擬機實現(xiàn),不同的JDK,內存的分布都不一樣,也就是說下面文章中提到的內存結構都只是邏輯結構,并不是內存的物理結構)

本文只介紹內存分配的方法,有關于具體的垃圾回收機制,內存結構的原理不作為本文重點,也希望通過本文讓大家對JVM有一點點的認知,小編對JVM理解并不透徹,不想誤人子弟。

2.內存總體結構

如果只是為了解決問題,不想了解其中緣由的請?zhí)^本章節(jié)

本文介紹的是垃圾回收的內存區(qū)域的結構(簡稱GC堆,不包括程序計數(shù)器,棧,本地方法棧)，引用一個大牛的說法《一個java對象的這一輩子》

我是一個普通的Java對象，我出生在Eden區(qū)，在Eden區(qū)我還看到和我長的很像的小兄弟(其他java對象)，我們在Eden區(qū)中玩了挺長時間。有一天Eden區(qū)中的人實在是太多了(會觸發(fā)Young GC,每次GC加一歲))，我就被迫去了Survivor區(qū)的“From”區(qū)，自從去了Survivor區(qū)，我就開始漂了，有時候在Survivor的“From”區(qū)，有時候在Survivor的“To”區(qū)，居無定所(每次Young GC都需要Survivor區(qū)中的from區(qū)和to區(qū)"對調")。直到我18歲的時候(進行了18次Young GC)，爸爸說我成人了，該去社會上闖闖了。于是我就去了年老代那邊，年老代里，人很多，并且年齡都挺大的，我在這里也認識了很多人。在年老代里，我生活了20年，然后被回收(Old GC)。

解釋一下,首先內存總體分為年輕代(young),老年代(old),永久代(permanent),如下圖

年輕代:(針對年輕代的垃圾回收我們簡稱Young GC)

年輕代分為eden區(qū),survivor區(qū)

1.eden區(qū),是new Object(),對象誕生的地方

2.survivor區(qū)是經過垃圾回收后的仍存活的對象存儲區(qū)域,survivor區(qū)中又分為from區(qū)和to區(qū)

2.1.from區(qū): 經過GC回收,eden區(qū)和to區(qū)仍存活的對象會存放在from區(qū)

2.2.to區(qū): 經過GC回收,eden區(qū)和from區(qū)仍存活的對象會轉移到to區(qū)

2.3.正因為2.1和2.2的操作,所以from區(qū)和to區(qū)中的存活對象來回轉移,并且始終有一個區(qū)是空的

老年代:(針對老年代的垃圾回收簡稱Old GC)

經過18次Young GC后年輕代中仍存活的對象,會從年輕代中轉移到老年代

老年代滿了之后,會觸發(fā)Old GC,仍存活的對象繼續(xù)保留在老年代中,直到經過20次Old GC進行回收

永久代:(針對年輕代+老年代+永久代的回收簡稱Full GC)

是HotSpot VM針對Java方法區(qū)的一個實現(xiàn),通常存儲類信息、常量池、靜態(tài)變量、JIT編譯后的代碼等數(shù)據(jù)(簡單理解成編譯代碼的存儲區(qū)域,即可以理解成:我們的java項目運行時,加載的類文件越多,則需要的永久代內存空間越大)

(注:據(jù)說永久代是Hotspot虛擬機特有的概念，別的JVM都沒有這個東西，在Java 8中，永久代被徹底移除，取而代之的是另一塊與堆不相連的本地內存——元空間)

3.通常內存問題解釋

常見問題一 java.lang.OutOfMemoryError: Java heap space ----JVM Heap(堆)溢出

原因:項目運行階段,new的對象過多,撐滿了配置的最大內存,會出現(xiàn)該錯誤

解決方法:手動設置Xms ,Xmx 的大小.

常見問題二 java.lang.OutOfMemoryError: PermGen space ----PermGen space (永久代) 溢出

原因:開發(fā)的項目Java文件比較多的時候,會出現(xiàn)該錯誤(即項目很大,被JVM加載的文件很多)

解決方法:手動設置MaxPermSize大小.

常見問題三 java.lang.StackOverflowError ---- 棧溢出

原因:通常都是某個代碼邏輯遞歸層次太多導致的,

解決方法:修改遞歸代碼,控制遞歸層數(shù)

4.內存分配方法(建議,非藥到病除)

本文只介紹常用的一些配置參數(shù),通常情況下永久代不算堆內存(單獨占用另一塊內存)，新生代占年老代的1/2，即占整個堆內存的1/3，按照這個原則我們給出一個配置例子。

比如服務器可以提供1G的內存以供項目使用，依據(jù)上圖我們給出如下配置。

運行模式:

-server 服務器模式,多CPU時,性能更佳

新生代與老年代:(通常不單獨配置新生代與老年代,所以直接配置整個內存堆大小即可)

-Xms384m 內存堆初始的內存空間

-Xmx768m 內存堆最大內存空間

永久代:(新生代,老年代配置剩余的內存留給永久代)---注意jdk1.8已移除

-XX:PermSize=128m 永久代初始化大小

-XX:MaxPermSize=256m 永久代最大的內存空間(默認為64m)

4.不同環(huán)境下的Tomcat內存配置方法

前面已經進行各類內存問題的詳解以及配置參數(shù)的簡要介紹,下面我們介紹一下各種環(huán)境下的具體配置方法.

1. 使用命令行啟動的tomcat：

修改TOMCAT_HOME/bin/catalina.sh(windows中是catalina.bat), 在文件上方添加如下語句

JAVA_OPTS="-server -Xms384m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m"

2.如果tomcat注冊成了windows服務,使用tomcat目錄中的/bin/tomcat8w.exe修改就可以了.如下圖

3.如果是使用myeclipse開發(fā)中,啟動tomcat,上述的修改就不起作用了,可進行如下設置：

Myeclipse->preferences->myeclipse->servers->tomcat->tomcat×.×->JDK面板中的Optional Java VM arguments中添加如下內容:

-server -Xms384m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m

最后說兩句:

不管配置什么,以及配置的參數(shù)值是多少,都需要根據(jù)實際項目不斷的調試,不要輕易放棄.

比如tomcat的內存配置,也不是越大越好,適合項目/適合服務器配置才是最好的

到此這篇關于淺談Tomcat內存配置的正確姿勢的文章就介紹到這了,更多相關Tomcat內存配置內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論