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