一、內(nèi)存溢出類型
1、java.lang.OutOfMemoryError: PermGen space
JVM管理兩種類型的內(nèi)存，堆和非堆。堆是給開發(fā)人員用的上面說的就是，是在JVM啟動時創(chuàng)建；非堆是留給JVM自己用的，用來存放類的信息的。它和堆不同，運(yùn)行期內(nèi)GC不會釋放空間。如果web app用了大量的第三方j(luò)ar或者應(yīng)用有太多的class文件而恰好MaxPermSize設(shè)置較小，超出了也會導(dǎo)致這塊內(nèi)存的占用過多造成溢出，或者tomcat熱部署時侯不會清理前面加載的環(huán)境，只會將context更改為新部署的，非堆存的內(nèi)容就會越來越多。
PermGen space的全稱是Permanent Generation space,是指內(nèi)存的永久保存區(qū)域，這塊內(nèi)存主要是被JVM存放Class和Meta信息的,Class在被Loader時就會被放到PermGen space中，它和存放類實(shí)例(Instance)的Heap區(qū)域不同,GC(Garbage Collection)不會在主程序運(yùn)行期對PermGen space進(jìn)行清理，所以如果你的應(yīng)用中有很CLASS的話,就很可能出現(xiàn)PermGen space錯誤，這種錯誤常見在web服務(wù)器對JSP進(jìn)行pre compile的時候。如果你的WEB APP下都用了大量的第三方j(luò)ar, 其大小超過了jvm默認(rèn)的大小(4M)那么就會產(chǎn)生此錯誤信息了。
一個最佳的配置例子：(經(jīng)過本人驗(yàn)證，自從用此配置之后，再未出現(xiàn)過tomcat死掉的情況)
set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
2、java.lang.OutOfMemoryError: Java heap space
第一種情況是個補(bǔ)充，主要存在問題就是出現(xiàn)在這個情況中。其默認(rèn)空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4。如果內(nèi)存剩余不到40％，JVM就會增大堆到Xmx設(shè)置的值，內(nèi)存剩余超過70％，JVM就會減小堆到Xms設(shè)置的值。所以服務(wù)器的Xmx和Xms設(shè)置一般應(yīng)該設(shè)置相同避免每次GC后都要調(diào)整虛擬機(jī)堆的大小。假設(shè)物理內(nèi)存無限大，那么JVM內(nèi)存的最大值跟操作系統(tǒng)有關(guān)，一般32位機(jī)是1.5g到3g之間，而64位的就不會有限制了。
注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會引起服務(wù)器啟動不起來。
垃圾回收GC的角色
JVM調(diào)用GC的頻度還是很高的，主要兩種情況下進(jìn)行垃圾回收：
當(dāng)應(yīng)用程序線程空閑；另一個是java內(nèi)存堆不足時，會不斷調(diào)用GC，若連續(xù)回收都解決不了內(nèi)存堆不足的問題時，就會報out of memory錯誤。因?yàn)檫@個異常根據(jù)系統(tǒng)運(yùn)行環(huán)境決定，所以無法預(yù)期它何時出現(xiàn)。
根據(jù)GC的機(jī)制，程序的運(yùn)行會引起系統(tǒng)運(yùn)行環(huán)境的變化，增加GC的觸發(fā)機(jī)會。
為了避免這些問題，程序的設(shè)計和編寫就應(yīng)避免垃圾對象的內(nèi)存占用和GC的開銷。顯示調(diào)用System.GC()只能建議JVM需要在內(nèi)存中對垃圾對象進(jìn)行回收，但不是必須馬上回收，
一個是并不能解決內(nèi)存資源耗空的局面，另外也會增加GC的消耗。
二、JVM內(nèi)存區(qū)域組成
簡單的說java中的堆和棧
java把內(nèi)存分兩種：一種是棧內(nèi)存，另一種是堆內(nèi)存
1。在函數(shù)中定義的基本類型變量和對象的引用變量都在函數(shù)的棧內(nèi)存中分配；
2。堆內(nèi)存用來存放由new創(chuàng)建的對象和數(shù)組
在函數(shù)（代碼塊）中定義一個變量時，java就在棧中為這個變量分配內(nèi)存空間，當(dāng)超過變量的作用域后，java會自動釋放掉為該變量所分配的內(nèi)存空間；在堆中分配的內(nèi)存由java虛擬機(jī)的自動垃圾回收器來管理
堆的優(yōu)勢是可以動態(tài)分配內(nèi)存大小，生存期也不必事先告訴編譯器，因?yàn)樗窃谶\(yùn)行時動態(tài)分配內(nèi)存的。缺點(diǎn)就是要在運(yùn)行時動態(tài)分配內(nèi)存，存取速度較慢；
棧的優(yōu)勢是存取速度比堆要快，缺點(diǎn)是存在棧中的數(shù)據(jù)大小與生存期必須是確定的無靈活性。
java堆分為三個區(qū)：New、Old和Permanent
GC有兩個線程：
新創(chuàng)建的對象被分配到New區(qū)，當(dāng)該區(qū)被填滿時會被GC輔助線程移到Old區(qū)，當(dāng)Old區(qū)也填滿了會觸發(fā)GC主線程遍歷堆內(nèi)存里的所有對象。Old區(qū)的大小等于Xmx減去-Xmn
java棧存放
棧調(diào)整：參數(shù)有+UseDefaultStackSize -Xss256K，表示每個線程可申請256k的棧空間
每個線程都有他自己的Stack
三、JVM如何設(shè)置虛擬內(nèi)存
提示：在JVM中如果98％的時間是用于GC且可用的Heap size 不足2％的時候?qū)伋龃水惓Ｐ畔ⅰ?/div>
提示：Heap Size 最大不要超過可用物理內(nèi)存的80％，一般的要將-Xms和-Xmx選項(xiàng)設(shè)置為相同，而-Xmn為1/4的-Xmx值。
提示：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)整堆的大小。
提示：假設(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以上的處理器就不會有限制了
提示：注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會引起服務(wù)器啟動不起來。
提示：設(shè)置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old區(qū)如果不夠大會頻繁的觸發(fā)"主" GC ，大大降低了性能
JVM使用-XX:PermSize設(shè)置非堆內(nèi)存初始值，默認(rèn)是物理內(nèi)存的1/64；
由XX:MaxPermSize設(shè)置最大非堆內(nèi)存的大小，默認(rèn)是物理內(nèi)存的1/4。
解決方法：手動設(shè)置Heap size
修改TOMCAT_HOME/bin/catalina.bat
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"
四、性能檢查工具使用
定位內(nèi)存泄漏：
JProfiler工具主要用于檢查和跟蹤系統(tǒng)（限于Java開發(fā)的）的性能。JProfiler可以通過時時的監(jiān)控系統(tǒng)的內(nèi)存使用情況，隨時監(jiān)視垃圾回收，線程運(yùn)行狀況等手段，從而很好的監(jiān)視JVM運(yùn)行情況及其性能。
1. 應(yīng)用服務(wù)器內(nèi)存長期不合理占用，內(nèi)存經(jīng)常處于高位占用，很難回收到低位；
2. 應(yīng)用服務(wù)器極為不穩(wěn)定，幾乎每兩天重新啟動一次，有時甚至每天重新啟動一次；
3. 應(yīng)用服務(wù)器經(jīng)常做Full GC(Garbage Collection)，而且時間很長，大約需要30-40秒，應(yīng)用服務(wù)器在做Full GC的時候是不響應(yīng)客戶的交易請求的，非常影響系統(tǒng)性能。
因?yàn)殚_發(fā)環(huán)境和產(chǎn)品環(huán)境會有不同，導(dǎo)致該問題發(fā)生有時會在產(chǎn)品環(huán)境中發(fā)生，通常可以使用工具跟蹤系統(tǒng)的內(nèi)存使用情況，在有些個別情況下或許某個時刻確實(shí)是使用了大量內(nèi)存導(dǎo)致out of memory，這時應(yīng)繼續(xù)跟蹤看接下來是否會有下降，
如果一直居高不下這肯定就因?yàn)槌绦虻脑驅(qū)е聝?nèi)存泄漏。
五、不健壯代碼的特征及解決辦法
1、盡早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域后，自動設(shè)置為null，暗示垃圾收集器來收集該對象，防止發(fā)生內(nèi)存泄露。
對于仍然有指針指向的實(shí)例，jvm就不會回收該資源,因?yàn)槔厥諘⒅禐閚ull的對象作為垃圾，提高GC回收機(jī)制效率；
2、我們的程序里不可避免大量使用字符串處理，避免使用String，應(yīng)大量使用StringBuffer，每一個String對象都得獨(dú)立占用內(nèi)存一塊區(qū)域；
String str = "aaa";
String str2 = "bbb";
String str3 = str + str2;//假如執(zhí)行此次之后str ,str2以后再不被調(diào)用,那它就會被放在內(nèi)存中等待Java的gc去回收,程序內(nèi)過多的出現(xiàn)這樣的情況就會報上面的那個錯誤,建議在使用字符串時能使用StringBuffer就不要用String,這樣可以省不少開銷；
3、盡量少用靜態(tài)變量，因?yàn)殪o態(tài)變量是全局的，GC不會回收的；
4、避免集中創(chuàng)建對象尤其是大對象，JVM會突然需要大量內(nèi)存，這時必然會觸發(fā)GC優(yōu)化系統(tǒng)內(nèi)存環(huán)境；顯示的聲明數(shù)組空間，而且申請數(shù)量還極大。
這是一個案例想定供大家警戒
使用jspsmartUpload作文件上傳,運(yùn)行過程中經(jīng)常出現(xiàn)java.outofMemoryError的錯誤，
檢查之后發(fā)現(xiàn)問題：組件里的代碼
m_totalBytes = m_request.getContentLength();
m_binArray = new byte[m_totalBytes];
問題原因是totalBytes這個變量得到的數(shù)極大，導(dǎo)致該數(shù)組分配了很多內(nèi)存空間，而且該數(shù)組不能及時釋放。解決辦法只能換一種更合適的辦法，至少是不會引發(fā)outofMemoryError的方式解決。參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747
5、盡量運(yùn)用對象池技術(shù)以提高系統(tǒng)性能；生命周期長的對象擁有生命周期短的對象時容易引發(fā)內(nèi)存泄漏，例如大集合對象擁有大數(shù)據(jù)量的業(yè)務(wù)對象的時候，可以考慮分塊進(jìn)行處理，然后解決一塊釋放一塊的策略。
6、不要在經(jīng)常調(diào)用的方法中創(chuàng)建對象，尤其是忌諱在循環(huán)中創(chuàng)建對象。可以適當(dāng)?shù)氖褂胔ashtable，vector 創(chuàng)建一組對象容器，然后從容器中去取那些對象，而不用每次new之后又丟棄
7、一般都是發(fā)生在開啟大型文件或跟數(shù)據(jù)庫一次拿了太多的數(shù)據(jù)，造成 Out Of Memory Error 的狀況，這時就大概要計算一下數(shù)據(jù)量的最大值是多少，并且設(shè)定所需最小及最大的內(nèi)存空間值。