http://www.cnblogs.com/a757956132/p/4644910.html

?

http://my.oschina.net/songhongxu/blog/209951

?

?

一、內(nèi)存溢出類型

1、java.lang.OutOfMemoryError: PermGen space

JVM管理兩種類型的內(nèi)存，堆和非堆。堆是給開發(fā)人員用的上面說(shuō)的就是，是在JVM啟動(dòng)時(shí)創(chuàng)建；非堆是留給JVM自己用的，用來(lái)存放類的信息的。它和堆不同，運(yùn)行期內(nèi)GC不會(huì)釋放空間。如果web app用了大量的第三方j(luò)ar或者應(yīng)用有太多的class文件而恰好MaxPermSize設(shè)置較小，超出了也會(huì)導(dǎo)致這塊內(nèi)存的占用過多造成溢出，或者tomcat熱部署時(shí)侯不會(huì)清理前面加載的環(huán)境，只會(huì)將context更改為新部署的，非堆存的內(nèi)容就會(huì)越來(lái)越多。

PermGen space的全稱是Permanent Generation space,是指內(nèi)存的永久保存區(qū)域，這塊內(nèi)存主要是被JVM存放Class和Meta信息的,Class在被Loader時(shí)就會(huì)被放到PermGen space中，它和存放類實(shí)例(Instance)的Heap區(qū)域不同,GC(Garbage Collection)不會(huì)在主程序運(yùn)行期對(duì)PermGen space進(jìn)行清理，所以如果你的應(yīng)用中有很CLASS的話,就很可能出現(xiàn)PermGen space錯(cuò)誤，這種錯(cuò)誤常見在web服務(wù)器對(duì)JSP進(jìn)行pre compile的時(shí)候。如果你的WEB APP下都用了大量的第三方j(luò)ar, 其大小超過了jvm默認(rèn)的大小(4M)那么就會(huì)產(chǎn)生此錯(cuò)誤信息了。?
一個(gè)最佳的配置例子：(經(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

第一種情況是個(gè)補(bǔ)充，主要存在問題就是出現(xiàn)在這個(gè)情況中。其默認(rèn)空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4。如果內(nèi)存剩余不到40％，JVM就會(huì)增大堆到Xmx設(shè)置的值，內(nèi)存剩余超過70％，JVM就會(huì)減小堆到Xms設(shè)置的值。所以服務(wù)器的Xmx和Xms設(shè)置一般應(yīng)該設(shè)置相同避免每次GC后都要調(diào)整虛擬機(jī)堆的大小。假設(shè)物理內(nèi)存無(wú)限大，那么JVM內(nèi)存的最大值跟操作系統(tǒng)有關(guān)，一般32位機(jī)是1.5g到3g之間，而64位的就不會(huì)有限制了。

注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來(lái)。

垃圾回收GC的角色

JVM調(diào)用GC的頻度還是很高的，主要兩種情況下進(jìn)行垃圾回收：

當(dāng)應(yīng)用程序線程空閑；另一個(gè)是java內(nèi)存堆不足時(shí)，會(huì)不斷調(diào)用GC，若連續(xù)回收都解決不了內(nèi)存堆不足的問題時(shí)，就會(huì)報(bào)out of memory錯(cuò)誤。因?yàn)檫@個(gè)異常根據(jù)系統(tǒng)運(yùn)行環(huán)境決定，所以無(wú)法預(yù)期它何時(shí)出現(xiàn)。

根據(jù)GC的機(jī)制，程序的運(yùn)行會(huì)引起系統(tǒng)運(yùn)行環(huán)境的變化，增加GC的觸發(fā)機(jī)會(huì)。

為了避免這些問題，程序的設(shè)計(jì)和編寫就應(yīng)避免垃圾對(duì)象的內(nèi)存占用和GC的開銷。顯示調(diào)用System.GC()只能建議JVM需要在內(nèi)存中對(duì)垃圾對(duì)象進(jìn)行回收，但不是必須馬上回收，

一個(gè)是并不能解決內(nèi)存資源耗空的局面，另外也會(huì)增加GC的消耗。

二、JVM內(nèi)存區(qū)域組成

簡(jiǎn)單的說(shuō)java中的堆和棧

java把內(nèi)存分兩種：一種是棧內(nèi)存，另一種是堆內(nèi)存

1。在函數(shù)中定義的基本類型變量和對(duì)象的引用變量都在函數(shù)的棧內(nèi)存中分配；

2。堆內(nèi)存用來(lái)存放由new創(chuàng)建的對(duì)象和數(shù)組

在函數(shù)（代碼塊）中定義一個(gè)變量時(shí)，java就在棧中為這個(gè)變量分配內(nèi)存空間，當(dāng)超過變量的作用域后，java會(huì)自動(dòng)釋放掉為該變量所分配的內(nèi)存空間；在堆中分配的內(nèi)存由java虛擬機(jī)的自動(dòng)垃圾回收器來(lái)管理

堆的優(yōu)勢(shì)是可以動(dòng)態(tài)分配內(nèi)存大小，生存期也不必事先告訴編譯器，因?yàn)樗窃谶\(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存的。缺點(diǎn)就是要在運(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存，存取速度較慢；

棧的優(yōu)勢(shì)是存取速度比堆要快，缺點(diǎn)是存在棧中的數(shù)據(jù)大小與生存期必須是確定的無(wú)靈活性。

java堆分為三個(gè)區(qū)：New、Old和Permanent

GC有兩個(gè)線程：

新創(chuàng)建的對(duì)象被分配到New區(qū)，當(dāng)該區(qū)被填滿時(shí)會(huì)被GC輔助線程移到Old區(qū)，當(dāng)Old區(qū)也填滿了會(huì)觸發(fā)GC主線程遍歷堆內(nèi)存里的所有對(duì)象。Old區(qū)的大小等于Xmx減去-Xmn

java棧存放

棧調(diào)整：參數(shù)有+UseDefaultStackSize -Xss256K，表示每個(gè)線程可申請(qǐng)256k的棧空間

每個(gè)線程都有他自己的Stack

三、JVM如何設(shè)置虛擬內(nèi)存

提示：在JVM中如果98％的時(shí)間是用于GC且可用的Heap size 不足2％的時(shí)候?qū)伋龃水惓Ｐ畔ⅰ?/p>

提示：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%時(shí)，JVM就會(huì)增大堆直到-Xmx的最大限制；空余堆內(nèi)存大于70%時(shí)，JVM會(huì)減少堆直到-Xms的最小限制。因此服務(wù)器一般設(shè)置-Xms、-Xmx相等以避免在每次GC 后調(diào)整堆的大小。

提示：假設(shè)物理內(nèi)存無(wú)限大的話，JVM內(nèi)存的最大值跟操作系統(tǒng)有很大的關(guān)系。

簡(jiǎn)單的說(shuō)就32位處理器雖然可控內(nèi)存空間有4GB,但是具體的操作系統(tǒng)會(huì)給一個(gè)限制，

這個(gè)限制一般是2GB-3GB（一般來(lái)說(shuō)Windows系統(tǒng)下為1.5G-2G，Linux系統(tǒng)下為2G-3G），而64bit以上的處理器就不會(huì)有限制了

提示：注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來(lái)。

提示：設(shè)置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old區(qū)如果不夠大會(huì)頻繁的觸發(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。

解決方法：手動(dòng)設(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可以通過時(shí)時(shí)的監(jiān)控系統(tǒng)的內(nèi)存使用情況，隨時(shí)監(jiān)視垃圾回收，線程運(yùn)行狀況等手段，從而很好的監(jiān)視JVM運(yùn)行情況及其性能。

1. 應(yīng)用服務(wù)器內(nèi)存長(zhǎng)期不合理占用，內(nèi)存經(jīng)常處于高位占用，很難回收到低位；

2. 應(yīng)用服務(wù)器極為不穩(wěn)定，幾乎每?jī)商熘匦聠?dòng)一次，有時(shí)甚至每天重新啟動(dòng)一次；

3. 應(yīng)用服務(wù)器經(jīng)常做Full GC(Garbage Collection)，而且時(shí)間很長(zhǎng)，大約需要30-40秒，應(yīng)用服務(wù)器在做Full GC的時(shí)候是不響應(yīng)客戶的交易請(qǐng)求的，非常影響系統(tǒng)性能。

因?yàn)殚_發(fā)環(huán)境和產(chǎn)品環(huán)境會(huì)有不同，導(dǎo)致該問題發(fā)生有時(shí)會(huì)在產(chǎn)品環(huán)境中發(fā)生，通常可以使用工具跟蹤系統(tǒng)的內(nèi)存使用情況，在有些個(gè)別情況下或許某個(gè)時(shí)刻確實(shí)是使用了大量?jī)?nèi)存導(dǎo)致out of memory，這時(shí)應(yīng)繼續(xù)跟蹤看接下來(lái)是否會(huì)有下降，

如果一直居高不下這肯定就因?yàn)槌绦虻脑驅(qū)е聝?nèi)存泄漏。

五、不健壯代碼的特征及解決辦法

1、盡早釋放無(wú)用對(duì)象的引用。好的辦法是使用臨時(shí)變量的時(shí)候，讓引用變量在退出活動(dòng)域后，自動(dòng)設(shè)置為null，暗示垃圾收集器來(lái)收集該對(duì)象，防止發(fā)生內(nèi)存泄露。

對(duì)于仍然有指針指向的實(shí)例，jvm就不會(huì)回收該資源,因?yàn)槔厥諘?huì)將值為null的對(duì)象作為垃圾，提高GC回收機(jī)制效率；

2、我們的程序里不可避免大量使用字符串處理，避免使用String，應(yīng)大量使用StringBuffer，每一個(gè)String對(duì)象都得獨(dú)立占用內(nèi)存一塊區(qū)域；

String str = "aaa";

String str2 = "bbb";

String str3 = str + str2;//假如執(zhí)行此次之后str ,str2以后再不被調(diào)用,那它就會(huì)被放在內(nèi)存中等待Java的gc去回收,程序內(nèi)過多的出現(xiàn)這樣的情況就會(huì)報(bào)上面的那個(gè)錯(cuò)誤,建議在使用字符串時(shí)能使用StringBuffer就不要用String,這樣可以省不少開銷；

3、盡量少用靜態(tài)變量，因?yàn)殪o態(tài)變量是全局的，GC不會(huì)回收的；

4、避免集中創(chuàng)建對(duì)象尤其是大對(duì)象，JVM會(huì)突然需要大量?jī)?nèi)存，這時(shí)必然會(huì)觸發(fā)GC優(yōu)化系統(tǒng)內(nèi)存環(huán)境；顯示的聲明數(shù)組空間，而且申請(qǐng)數(shù)量還極大。

這是一個(gè)案例想定供大家警戒

使用jspsmartUpload作文件上傳,運(yùn)行過程中經(jīng)常出現(xiàn)java.outofMemoryError的錯(cuò)誤，

檢查之后發(fā)現(xiàn)問題：組件里的代碼

m_totalBytes = m_request.getContentLength();

m_binArray = new byte[m_totalBytes];

問題原因是totalBytes這個(gè)變量得到的數(shù)極大，導(dǎo)致該數(shù)組分配了很多內(nèi)存空間，而且該數(shù)組不能及時(shí)釋放。解決辦法只能換一種更合適的辦法，至少是不會(huì)引發(fā)outofMemoryError的方式解決。參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747

5、盡量運(yùn)用對(duì)象池技術(shù)以提高系統(tǒng)性能；生命周期長(zhǎng)的對(duì)象擁有生命周期短的對(duì)象時(shí)容易引發(fā)內(nèi)存泄漏，例如大集合對(duì)象擁有大數(shù)據(jù)量的業(yè)務(wù)對(duì)象的時(shí)候，可以考慮分塊進(jìn)行處理，然后解決一塊釋放一塊的策略。

6、不要在經(jīng)常調(diào)用的方法中創(chuàng)建對(duì)象，尤其是忌諱在循環(huán)中創(chuàng)建對(duì)象。可以適當(dāng)?shù)氖褂胔ashtable，vector 創(chuàng)建一組對(duì)象容器，然后從容器中去取那些對(duì)象，而不用每次new之后又丟棄

7、一般都是發(fā)生在開啟大型文件或跟數(shù)據(jù)庫(kù)一次拿了太多的數(shù)據(jù)，造成 Out Of Memory Error 的狀況，這時(shí)就大概要計(jì)算一下數(shù)據(jù)量的最大值是多少，并且設(shè)定所需最小及最大的內(nèi)存空間值。

轉(zhuǎn)載于:https://www.cnblogs.com/donaldlee2008/p/5839936.html

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的java 大数据处理之内存溢出解决办法（一）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。