目錄
內存溢出解決記錄
項目平穩運行到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
根據日誌內容進行解析：
[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協議處理，當然tomcat8.5以上版本都支持了最新的HTTP/2.0協議。
說句題外話，tomcat對http/2.0的支持實際是從tomcat9開始的，Apache Tomcat 9.0.0.M1 是 9.0.x 的第一個里程碑版本，提供 9.0.x 的新特性早期預覽，有如下值得關注的改進：
①新增 HTTP/2 支持和 TLS 虛擬主機
②實現當前 Servlet 4.0 規範草案
③BIO connectors 不再支持 Windows Itanium 和 Comet
comet取消，因爲http2.0 加入了 server push的功能。
不過，現在已經把http2.0的支持移植到了tomcat8.5版本中。
“exec”表達執行，exec-xx後面接的數字只的是tomcat此時執行的線程，所以[http-nio-9090-exec-xx]是tomcat
處理當前請求的線程名字。tomcat內部有一個處理任務請求的線程池，有請求的時候會被放在線程池中執行，請求處理結束返回給瀏覽器後，線程池回收線程。
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在執行名爲tug_ciimp這個servlet容器時，這個容器上下文/web_project_resources
這個路徑的時候拋出異常，該異常因爲root用戶引起，請求程序失敗，發生嵌套的異常爲：空指針異常(NullPointerException)
同理，解析出：[Handler processing failed;nested exception is java.lang.OutOfMemoryError:
Java heap space] with root cause java.lang.OutOfMemoryError: Java heap space
這個異常是處理程序失敗，產生Java堆內存溢出。
而且根據線程名，http-nio-9090-exec-19是在發生完NullPointerException，經過大約4分鐘後發生堆內存溢出的異常。
解析完這些log後，再看看實際的程序運行背景：
在tomcat啓動時，並未發生啓動異常。tomcat服務器中有4個程序在同時運行，並不只有tug_ciimp這個程序，且這4個
程序毫無關聯。在啓動後，系統運行一切正常，當啓動到第10天左右時候，產生內存溢出這個異常。第一次發生此異常
只是把tomcat重啓，系統恢復正常運行。又間隔大約10多天時間又發生內存溢出。
爲了把這個定時炸彈解決掉，準備採取以下措施，從網上找出內存溢出的可能情況：
1.java運行內存分配不足，啓動參數內存值設定的過小。有幾個地方：一是開發環境中eclipse.ini中，
二是tomcat的啓動文件中catalina.bat/catalina.sh中。因爲不是開發環境，所以eclipse.ini去掉。
2.代碼中存在死循環或循環產生過多重複的對象實體。
3.集合類中有對對象的引用，使用完後未清空，使得JVM不能回收；
4.創建的對象持續增加，未得到及時清理，日積月累使內存溢出。
5.一次性提取大量數據到內存的地方（10萬數據以上）
6.某個線程執行時間過長，那麼就很危險了，佔用的內存無法釋放。容易造成內存的溢出。
總結完以上問題，需要重點排查以下幾點：
1.檢查代碼中是否有死循環或遞歸調用。
2.檢查是否有大循環重複產生新對象實體。
3.檢查對數據庫查詢中，是否有一次獲得全部數據的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存
溢出。這個問題比較隱蔽，在上線前，數據庫中數據較少，不容易出問題，上線後，數據庫中數據多了，一次查詢就有
可能引起內存溢出。因此對於數據庫查詢儘量採用分頁的方式查詢。
4.檢查List、MAP等集合對象是否有使用完後，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得
這些對象不能被GC回收。
有了以上這幾點內存溢出的情況，不過根據實際背景分析出，基本不會是內存分配不足，如果內存分配有問題在啓動
時候就會報異常，所以先排除1之外剩餘四點都有可能。根據項目實際使用情況，當前處於試運行階段，出現一次性
提取大量數據的可能性也不大，所以首先從2、3、4、5這幾點着手，由於項目的代碼很多，一個一個代碼排查很笨拙
所以先採取以下方案進行觀察：
首先選擇jvisualvm工具，來查看到堆內存中各個對象的數量以及佔用的內存大小。
如果找到有大量的自定義對象一直無法釋放，可能距離定位到問題就不遠了。
jvisualvm監測結果：
監測總覽：
jvisualvm概述，如圖DUMP必須調出來才能在內存溢出彈出錯誤信息：
通過jconsole監測結果，參數總覽：
堆內存總覽：
根據將近6天時間持續監測，發現cup、內存、類、線程等一直很平穩，沒有持續升高現象，但是CPU偶爾會有突發性升高並會很快的下降回到正常。通過類實例數監測結果，對象所佔內存也並不大。通過監測圖還可看出，雖然結果運行比較平穩，但是通過檢測工具發現堆初始值和最大值分別是128m和256m，並且離最大值比較近，所以突發的大數據量導致內存暴漲的可能性比較大。(本來水面離堤壩最高點比較接近的情況下又下了場大雨，導致決堤)
所以目前從兩個方向去處理這個問題：
1.修改tomcat的內存參數，讓內存參數加大。
2.減少應用中單次請求數據量過大的情況，比如，對數據查詢時做分頁處理，其它操作時也分批次。幾個定時任務之間
不在同一時刻執行。(但是通過log發生時間，推斷跟定時任務關係不大)
所以，先把內存參數調大，再觀測一段時間。
由於在windows server服務器的tomcat是通過系統服務啓動tomcat服務，所以在TOMCAT_HOME/bin/catalina.bat
中添加是無效的，windows服務執行的是bin\tomcat.exe.他讀取註冊表中的值,而不是catalina.bat的設置。
所以，需要在註冊表中進行修改，ctrl+R，輸入regedit後，出現註冊表，路徑爲：
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系統服務還是不起作用。
windows server重新安裝tomcat系統服務步驟如下：
CMD 命令進入到 Tomcat 的 bin 目錄下，先停掉tomcat系統服務，執行service remove 服務名稱
再輸入 service install 服務名稱，再裝載上tomcat系統服務，tomcat系統服務裝配完畢後，
進入tomcat的bin目錄下，找到tomcat8w.exe，雙擊點開
在此處，把初始內存和最大內存更改後，加入jmx連接，並定義好連接端口12003(不要與其它服務衝突即可)
-Dcom.sun.management.jmxremote.port=12003
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
用系統服務重啓tomcat，然後啓動jconsole和jvisualvm連接
自從更改完初始參數後，經過兩個多月使用，沒再發生內存溢出問題。
內存及GC 的相關參數
內存相關設置(32位系統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：新生代大小，增大新生代後會相應減小老年代大小。此值對系統性能影響較大，Java 官方推薦配置爲整個
堆大小的3/8。
-Xss：設置每個線程棧的大小。Java1.5 以後每個線程棧默認大小爲1M，之前每個線程棧默認大小爲256K。
可以根據應用的線程所需內存大小進行調整。一般情況下默認值已經能滿足絕大部分情景的應用，如果想更進一步優化
則需要非常細緻的測試。在相同物理內存下，減小這個值能生成更多的線程，進程中可容納線程數量與很多因素有關，
感興趣的可以詳細瞭解下，據說可以達到6500個以上。
-XX:MinHeapFreeRatio=40：如果發現空閒堆內存佔到整個預估上限值的40%，則增大上限值。
-XX:MaxHeapFreeRatio=70：如果發現空閒堆內存佔到整個預估上限值的70%，則收縮預估上限值。
-XX:NewRatio=2：設置年輕代和老年代的比值。例如：n=3，則表示年輕代與老年代比值爲1:3，年輕代佔整個年
輕代與老年代之和的1/4。
-XX:SurvivorRatio=8：Eden 與Survivor 的佔用比例。例如8表示，一個survivor 區佔用 1/8 的Eden 內存，
即1/10的新生代內存，此處需注意年輕代有2個survivor 區，所以比例爲1:10。
-XX:TargetSurvivorRatio=50：實際使用的survivor 空間大小佔比。默認是47%，最高90%。
-XX:MaxPermSize=64m：設置持久代(即方法區)佔整個堆內存的最大值。
-XX:MaxTenuringThreshold=0：設置對象最大年齡。即對象在在Eden 與Survivor 區之間被複制的次數，每
被複制一次就增加1歲，默認值爲15。如果設置爲0的話，則Eden 中對象不經過Survivor 區直接進入老年代。
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啓動內存參數做設置，則修改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 虛擬機具有一個堆，堆是運行時數據區域，所有類實例和數組的內存均從此處分配。堆是在Java虛擬機啓動時
創建的。在JVM中堆之外的內存稱爲非堆內存(Non-heap memory)”。可以看出JVM主要管理兩種類型的內存：堆和非堆。
簡單來說堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給自己用的，所以方法區、JVM內部處理
或優化所需的內存(如JIT編譯後的代碼緩存)、每個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法
的代碼都在非堆內存中。
JVM主要管理兩種類型的內存：堆和非堆
Heap memory Code Cache
Eden Space
Survivor Space
Tenured Gen
non-heap memory Perm Gen
native heap?(I guess)
堆內存
Java虛擬機具有一個堆，堆是運行時數據區域，所有類實例和數組的內存均從此處分配。堆是在Java虛擬機啓動
時創建的。對象的堆內存由稱爲垃圾回收器的自動內存管理系統回收。
堆的大小可以固定，也可以擴大和縮小。堆的內存不需要是連續空間。
非堆內存
Java虛擬機管理堆之外的內存（稱爲非堆內存）。
Java虛擬機具有一個由所有線程共享的方法區。方法區屬於非堆內存。它存儲每個類結構，如運行時常數池、字段和
方法數據，以及方法和構造方法的代碼。它是在 Java 虛擬機啓動時創建的。
方法區在邏輯上屬於堆，但Java虛擬機實現可以選擇不對其進行回收或壓縮。與堆類似，方法區的大小可以固定，也
可以擴大和縮小。方法區的內存不需要是連續空間。
除了方法區外，Java虛擬機實現可能需要用於內部處理或優化的內存，這種內存也是非堆內存。例如，JIT編譯器需
要內存來存儲從Java虛擬機代碼轉換而來的本機代碼，從而獲得高性能。
各區概念解釋參照：
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個區：
Eden Space（伊甸園）、Survivor Space(倖存者區)、Old Gen（老年代-養老區）
Young保存剛實例化的對象。當該區被填滿時，GC會將對象移到Old區。Permanent區則負責保存反射對象。
Eden Space字面意思是伊甸園，對象被創建的時候首先放到這個區域，進行垃圾回收後，不能被回收的對象被放入
到空的survivor區域。
Survivor Space倖存者區，用於保存在Eden space內存區域中經過垃圾回收後沒有被回收的對象。Survivor有兩個，
分別爲To Survivor、 From Survivor，這個兩個區域的空間大小是一樣的。執行垃圾回收的時候Eden區域不能被
回收的對象被放入到空的survivor（也就是To Survivor，同時Eden區域的內存會在垃圾回收的過程中全部釋放），
另一個survivor（即From Survivor）裏不能被回收的對象也會被放入這個survivor（即To Survivor），然後
To Survivor 和 From Survivor的標記會互換，始終保證一個survivor是空的。
Eden Space和Survivor Space都屬於新生代，新生代中執行的垃圾回收被稱之爲Minor GC（因爲是對新生代進
行垃圾回收，所以又被稱爲Young GC），每一次Young GC後留下來的對象age加1。
注：GC爲Garbage Collection，垃圾回收。
Old Gen老年代，用於存放新生代中經過多次垃圾回收仍然存活的對象，也有可能是新生代分配不了內存的大對象會
直接進入老年代。經過多次垃圾回收都沒有被回收的對象，這些對象的年代已經足夠old了，就會放入到老年代。
當老年代被放滿的之後，虛擬機會進行垃圾回收，稱之爲Major GC。由於Major GC除併發GC外均需對整個堆進行掃描和回收，因此又稱爲Full GC。
總結：heap區即堆內存，整個堆大小=年輕代大小 + 老年代大小。堆內存默認爲物理內存的1/64(<1GB)；默認空餘
堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制，可以通過MinHeapFreeRatio參數進行調整；默認空餘堆內
存大於70%時，JVM會減少堆直到-Xms的最小限制，可以通過MaxHeapFreeRatio參數進行調整。
非heap區又分：
Code Cache(代碼緩存區)、Perm Gen（永久代）、Jvm Stack(java虛擬機棧)、Local Method Statck(本地方法棧)。
Code Cache代碼緩存區，它主要用於存放JIT所編譯的代碼。CodeCache代碼緩衝區的大小在client模式下默認最大
是32m，在server模式下默認是48m，這個值也是可以設置的，它所對應的JVM參數爲ReservedCodeCacheSize和
InitialCodeCacheSize，可以通過如下的方式來爲Java程序設置。
-XX:ReservedCodeCacheSize=128m
CodeCache緩存區是可能被充滿的，當CodeCache滿時，後臺會收到CodeCache is full的警告信息，如下所示：
“CompilerThread0” java.lang.OutOfMemoryError: requested 2854248 bytes for Chunk::new. Out of swap space?
注：JIT編譯器是在程序運行期間，將Java字節碼編譯成平臺相關的二進制代碼。正因爲此編譯行爲發生在程序運行
期間，所以該編譯器被稱爲Just-In-Time編譯器。
Perm Gen全稱是Permanent Generation space，是指內存的永久保存區域，因而稱之爲永久代。這個內存區域用
於存放Class和Meta的信息，Class在被 Load的時候被放入這個區域。因爲Perm裏存儲的東西永遠不會被JVM垃圾
回收的，所以如果你的應用程序LOAD很多CLASS的話，就很可能出現PermGen space錯誤。默認大小爲物理內存的1/64。
Perm Gen中放着類、方法的定義。持久代主要存放類定義、字節碼和常量等很少會變更的信息。
jvm Stack區域放着方法參數、局域變量等的引用，方法執行順序按照棧的先入後出方式。
HotSpot虛擬機GC算法採用分代收集算法：
1、一個人（對象）出來（new 出來）後會在Eden Space（伊甸園）無憂無慮的生活，直到GC到來打破了他們平靜
的生活。GC會逐一問清楚每個對象的情況，有沒有錢（此對象的引用）啊，因爲GC想賺錢呀，有錢的纔可以敲詐嘛。
然後富人就會進入Survivor Space（倖存者區），窮人的就直接kill掉。
2、並不是進入Survivor Space（倖存者區）後就保證人身是安全的，但至少可以活段時間。GC會定期（可以自定義）
會對這些人進行敲詐，億萬富翁每次都給錢，GC很滿意，就讓其進入了Genured Gen(養老區)。萬元戶經不住幾次敲詐 就沒錢了，GC看沒有啥價值啦，就直接kill掉了。
3、進入到養老區的人基本就可以保證人身安全啦，但是億萬富豪有的也會揮霍成窮光蛋，只要錢沒了，GC還是kill掉。
分區的目的：新生區由於對象產生的比較多並且大都是朝生夕滅的，所以直接採用標記-清理算法。而養老區生命力很
強，則採用複製算法，針對不同情況使用不同算法。
堆內存分配
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區域，它和存放Instance
的Heap區域不同。
GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的APP會LOAD很多CLASS 的話,
就很可能出現PermGen space錯誤。
5. 這種錯誤常見在web服務器對JSP進行pre compile的時候。
JVM內存限制(最大值)
1. 首先JVM內存限制於實際的最大物理內存，假設物理內存無限大的話，JVM內存的最大值跟操作系統有很大的關係。
簡單的說就32位處理器雖然可控內存空間有4GB,但是具體的操作系統會給一個限制，這個限制一般是2GB-3GB
（一般來說Windows系統下爲1.5G-2G，Linux系統下爲2G-3G），而64bit以上的處理器就不會有限制了。
2. 爲什麼有的機器我將-Xmx和-XX:MaxPermSize都設置爲512M之後Eclipse可以啓動，而有些機器無法啓動？
通過上面對JVM內存管理的介紹我們已經瞭解到JVM內存包含兩種：堆內存和非堆內存，另外JVM最大內存首先取決於
實際的物理內存和操作系統。所以說設置VM參數導致程序無法啓動主要有以下幾種原因：
參數中-Xms的值大於-Xmx，或者-XX:PermSize的值大於-XX:MaxPermSize；
-Xmx的值和-XX:MaxPermSize的總和超過了JVM內存的最大限制，比如當前操作系統最大內存限制，或者實際的物理
內存等等。說到實際物理內存這裏需要說明一點的是，如果你的內存是1024MB，但實際系統中用到的並不可能是1024MB，
因爲有一部分被硬件佔用了。
3.如果你有一個雙核的CPU，也許可以嘗試這個參數: -XX:+UseParallelGC讓GC可以更快的執行（只是JDK5裏對GC新增加的參數）
4.如果你的WEB APP下都用了大量的第三方jar，其大小超過了服務器jvm默認的大小，那麼就會產生內存益出問題了。
解決方法：設置MaxPermSize大小。
增加服務器啓動的JVM參數設置：
-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（堆內存）區之中。
MaxPermSize缺省值和-server -client選項相關：-server選項下默認MaxPermSize爲64m、-client選項下默認
MaxPermSize爲32m。
申請一塊內存的過程
1.JVM會試圖爲相關Java對象在Eden中初始化一塊內存區域
2.當Eden空間足夠時，內存申請結束。否則到下一步
3.JVM試圖釋放在Eden中所有不活躍的對象（這屬於1或更高級的垃圾回收）；釋放後若Eden空間仍然不足以放入
新對象，則試圖將部分Eden中活躍對象放入Survivor區/OLD區
4.Survivor區被用來作爲Eden及OLD的中間交換區域，當OLD區空間足夠時，Survivor區的對象會被移到Old區，否則會
被保留在Survivor區。
5.當OLD區空間不夠時，JVM會在OLD區進行完全的垃圾收集（0級）
6.完全垃圾收集後，若Survivor及OLD區仍然無法存放從Eden複製過來的部分對象，導致JVM無法在Eden區爲新對象
創建內存區域，則出現”out of memory錯誤”
內存回收算法
Java中有四種不同的回收算法，對應的啓動參數爲:
–XX:+UseSerialGC
–XX:+UseParallelGC
–XX:+UseParallelOldGC
–XX:+UseConcMarkSweepGC