java程式記憶體溢位一般什麼原因

阿新 • • 發佈：2019-01-16

JVM記憶體設定小了或者一次性讀的資料過大例如list vertor

一、記憶體溢位型別

1、java.lang.OutOfMemoryError: PermGen space

JVM管理兩種型別的記憶體，堆和非堆。堆是給開發人員用的上面說的就是，是在JVM啟動時建立；非堆是留給JVM自己用的，用來存放類的資訊的。它和堆不同，執行期內GC不會釋放空間。如果web
app用了大量的第三方jar或者應用有太多的class檔案而恰好MaxPermSize設定較小，超出了也會導致這塊記憶體的佔用過多造成溢位，或者tomcat熱部署時侯不會清理前面載入的環境，只會將context更改為新部署的，非堆存的內容就會越來越多。

PermGen space的全稱是Permanent Generation
space,是指記憶體的永久儲存區域，這塊記憶體主要是被JVM存放Class和Meta資訊的,Class在被Loader時就會被放到PermGen
space中，它和存放類例項(Instance)的Heap區域不同,GC(Garbage Collection)不會在主程式執行期對PermGen
space進行清理，所以如果你的應用中有很CLASS的話,就很可能出現PermGen space錯誤，這種錯誤常見在web伺服器對JSP進行pre
compile的時候。如果你的WEB APP下都用了大量的第三方jar, 其大小超過了jvm預設的大小(4M)那麼就會產生此錯誤資訊了。

一個最佳的配置例子：(經過本人驗證，自從用此配置之後，再未出現過tomcat死掉的情況)

set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m
-XX:MaxPermSize=256m

2、java.lang.OutOfMemoryError: Java heap space

第一種情況是個補充，主要存在問題就是出現在這個情況中。其預設空間(即-Xms)是實體記憶體的1/64，最大空間(-Xmx)是實體記憶體的1/4。如果記憶體剩餘不到40％，JVM就會增大堆到Xmx設定的值，記憶體剩餘超過70％，JVM就會減小堆到Xms設定的值。所以伺服器的Xmx和Xms設定一般應該設定相同避免每次GC後都要調整虛擬機器堆的大小。假設實體記憶體無限大，那麼JVM記憶體的最大值跟

作業系統有關，一般32位機是1.5g到3g之間，而64位的就不會有限制了。

注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了實體記憶體或者作業系統的最大限制都會引起伺服器啟動不起來。

垃圾回收GC的角色

JVM呼叫GC的頻度還是很高的，主要兩種情況下進行垃圾回收：

當應用程式執行緒空閒；另一個是java記憶體堆不足時，會不斷呼叫GC，若連續回收都解決不了記憶體堆不足的問題時，就會報out of
memory錯誤。因為這個異常根據系統執行環境決定，所以無法預期它何時出現。

根據GC的機制，程式的執行會引起系統執行環境的變化，增加GC的觸發機會。

為了避免這些問題，程式的設計和編寫就應避免垃圾物件的記憶體佔用和GC的開銷。顯示呼叫System.GC()只能建議JVM需要在記憶體中對垃圾物件進行回收，但不是必須馬上回收，

一個是並不能解決記憶體資源耗空的局面，另外也會增加GC的消耗。

二、JVM記憶體區域組成

簡單的說java中的堆和棧

java把記憶體分兩種：一種是棧記憶體，另一種是堆記憶體

1。在函式中定義的基本型別變數和物件的

引用變數都在函式的棧記憶體中分配；

2。堆記憶體用來存放由new建立的物件和陣列

在函式（程式碼塊）中定義一個變數時，java就在棧中為這個變數分配記憶體空間，當超過變數的作用域後，java會自動釋放掉為該變數所分配的記憶體空間；在堆中分配的記憶體由java虛擬機器的自動垃圾回收器來管理

堆的優勢是可以動態分配記憶體大小，生存期也不必事先告訴編譯器，因為它是在執行時動態分配記憶體的。缺點就是要在執行時動態分配記憶體，存取速度較慢；

棧的優勢是存取速度比堆要快，缺點是存在棧中的資料大小與生存期必須是確定的無靈活性。

java堆分為三個區：New、Old和Permanent

GC有兩個執行緒：

新建立的物件被分配到New區，當該區被填滿時會被GC輔助執行緒移到Old區，當Old區也填滿了會觸發GC主執行緒遍歷堆記憶體裡的所有物件。Old區的大小等於Xmx減去-Xmn

java棧存放

棧調整：引數有+UseDefaultStackSize -Xss256K，表示每個執行緒可申請256k的棧空間

每個執行緒都有他自己的Stack

三、JVM如何設定

虛擬記憶體

提示：在JVM中如果98％的時間是用於GC且可用的Heap size 不足2％的時候將丟擲此異常資訊。

提示：Heap Size 最大不要超過可用實體記憶體的80％，一般的要將-Xms和-Xmx選項設定為相同，而-Xmn為1/4的-Xmx值。

提示：JVM初始分配的記憶體由-Xms指定，預設是實體記憶體的1/64；JVM最大分配的記憶體由-Xmx指定，預設是實體記憶體的1/4。

預設空餘堆記憶體小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆記憶體大於70%時，JVM會減少堆直到-Xms的最小限制。因此伺服器一般設定-Xms、-Xmx相等以避免在每次GC
後調整堆的大小。

提示：假設實體記憶體無限大的話，JVM記憶體的最大值跟作業系統有很大的關係。

簡單的說就32位處理器雖然可控記憶體空間有4GB,但是具體的作業系統會給一個限制，

這個限制一般是2GB-3GB（一般來說Windows系統下為1.5G-2G，Linux系統下為2G-3G），而64bit以上的處理器就不會有限制了

提示：注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了實體記憶體或者作業系統的最大限制都會引起伺服器啟動不起來。

提示：設定NewSize、MaxNewSize相等，"new"的大小最好不要大於"old"的一半，原因是old區如果不夠大會頻繁的觸發"主" GC
，大大降低了效能

JVM使用-XX:PermSize設定非堆記憶體初始值，預設是實體記憶體的1/64；

由XX:MaxPermSize設定最大非堆記憶體的大小，預設是實體記憶體的1/4。

解決方法：手動設定Heap size

修改TOMCAT_HOME/bin/catalina.bat

在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：

JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

四、效能檢查工具使用

定位記憶體洩漏：

JProfiler工具主要用於檢查和跟蹤系統（限於Java開發的）的效能。JProfiler可以通過時時的監控系統的記憶體使用情況，隨時監視垃圾回收，執行緒執行狀況等手段，從而很好的監視JVM執行情況及其效能。

1. 應用伺服器記憶體長期不合理佔用，記憶體經常處於高位佔用，很難回收到低位；

2. 應用伺服器極為不穩定，幾乎每兩天重新啟動一次，有時甚至每天重新啟動一次；

3. 應用伺服器經常做Full GC(Garbage Collection)，而且時間很長，大約需要30-40秒，應用伺服器在做Full
GC的時候是不響應客戶的交易請求的，非常影響系統性能。

因為開發環境和產品環境會有不同，導致該問題發生有時會在產品環境中發生，通常可以使用工具跟蹤系統的記憶體使用情況，在有些個別情況下或許某個時刻確實是使用了大量記憶體導致out
of memory，這時應繼續跟蹤看接下來是否會有下降，

如果一直居高不下這肯定就因為程式的原因導致記憶體洩漏。

五、不健壯程式碼的特徵及解決辦法

1、儘早釋放無用物件的引用。好的辦法是使用臨時變數的時候，讓引用變數在退出活動域後，自動設定為null，暗示垃圾收集器來收集該物件，防止發生記憶體洩露。

對於仍然有指標指向的例項，jvm就不會回收該資源,因為垃圾回收會將值為null的物件作為垃圾，提高GC回收機制效率；

2、我們的程式裡不可避免大量使用字串處理，避免使用String，應大量使用StringBuffer，每一個String物件都得獨立佔用記憶體一塊區域；

String str = "aaa";

String str2 = "bbb";

String str3 = str + str2;//假如執行此次之後str
,str2以後再不被呼叫,那它就會被放在記憶體中等待Java的gc去回收,程式內過多的出現這樣的情況就會報上面的那個錯誤,建議在使用字串時能使用StringBuffer就不要用String,這樣可以省不少開銷；

3、儘量少用靜態變數，因為靜態變數是全域性的，GC不會回收的；

4、避免集中建立物件尤其是大物件，JVM會突然需要大量記憶體，這時必然會觸發GC優化系統記憶體環境；顯示的宣告陣列空間，而且申請數量還極大。

這是一個案例想定供大家警戒

使用jspsmartUpload作檔案上傳,執行過程中經常出現java.outofMemoryError的錯誤，

檢查之後發現問題：元件裡的程式碼

m_totalBytes = m_request.getContentLength();

m_binArray = new byte[m_totalBytes];

問題原因是totalBytes這個變數得到的數極大，導致該陣列分配了很多記憶體空間，而且該陣列不能及時釋放。解決辦法只能換一種更合適的辦法，至少是不會引發outofMemoryError的方式解決。參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747

5、儘量運用物件池技術以提高系統性能；生命週期長的物件擁有生命週期短的物件時容易引發記憶體洩漏，例如大集合物件擁有大資料量的業務物件的時候，可以考慮分塊進行處理，然後解決一塊釋放一塊的策略。

6、不要在經常呼叫的方法中建立物件，尤其是忌諱在迴圈中建立物件。可以適當的使用hashtable，vector
建立一組物件容器，然後從容器中去取那些物件，而不用每次new之後又丟棄

7、一般都是發生在開啟大型檔案或跟資料庫一次拿了太多的資料，造成 Out Of Memory Error
的狀況，這時就大概要計算一下資料量的最大值是多少，並且設定所需最小及最大的記憶體空間值。

java程式記憶體溢位一般什麼原因

java程式記憶體溢位一般什麼原因

Java記憶體溢位的原因有哪些？Java程序佔用記憶體構成有哪些？

Java的記憶體溢位與記憶體洩漏

棧，記憶體溢位的原因以及物件與物件引用

java常見記憶體溢位情形

Java服務記憶體溢位問題解決和總結

JAVA程式比較慢一般如何定位？

如何避免java程式記憶體洩漏

專案出現記憶體溢位的原因及解決方案

Java常見記憶體溢位異常分析

JVM之java堆記憶體溢位

java JVM 記憶體溢位 64位JDK

jstat命令分析java程式記憶體回收情況

Java常見記憶體溢位(OOM)解決方案

Java 堆記憶體溢位梗概分析

(8)利用JConsole工具監控java程式記憶體和JVM

HttpURLConnection上傳大檔案記憶體溢位的原因及解決辦法

java專案記憶體溢位問題解決方法

利用VC/VS檢測程式記憶體溢位(轉)

java關於記憶體溢位的分析，mat工具

java程式記憶體溢位一般什麼原因

相關推薦