在java虛擬機規(guī)范描述中，除了程序計數(shù)器外，虛擬機內存的其他幾個運行區(qū)域都有發(fā)生 oom 異常的可能。在這里，用代碼驗證各個運行時區(qū)域存儲的內容并討論該如何進行處理。
java堆溢出
java 堆用于存儲對象實例，只要不斷創(chuàng)建對象，并且保證 gc roots 到對象之間有可達路徑來避免垃圾回收機制清除這些對象，那么對象數(shù)量達到最大堆的容量限制之后就會產生內存溢出異常。
異常再現(xiàn)
代碼采用如下虛擬機參數(shù)：
|
1
|
-xms20m -xmx20m -xx:+heapdumponoutofmemoryerror |
這樣 java 堆的大小將被限制為20 mb 且不可拓展。通過參數(shù) -xx:+heapdumponoutofmemoryerror 可以讓虛擬機在出現(xiàn)內存溢出異常時 dump 出當前的內存堆轉儲快照以便時候進行分析。
采用如下代碼進行驗證：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class heapoom { static class oomobject { } public static void main(string[] args) { list<oomobject> list = new arraylist<oomobject>(); while (true) { list.add(new oomobject()); } }} |
運行結果：
|
1
2
3
4
5
|
java.lang.outofmemoryerror: java heap spacedumping heap to java_pid3460.hprof ...heap dump file created [28199779 bytes in 0.237 secs] |
解決方法
java 堆內存的 oom 異常是實際應用中常見的內存溢出異常情況，出現(xiàn)時往往會緊跟著提示“java heap space”。
要解決這個區(qū)域的異常，一般的手段是先通過內存映像分析工具，比如 mat ，確認到底是出現(xiàn)了內存泄漏還是內存溢出。
如果是內存泄漏，可以進一步通過工具查看泄漏對象到 gc roots 的引用鏈，找到泄漏對象是通過怎樣的途徑和 gc roots 相關聯(lián)并導致垃圾收集器無法自動回收它們所占的空間。
如果不是內存泄漏，換而言之，內存中的對象確實還有必要存活著，那么就應當檢查虛擬機的堆參數(shù)，與機器物理內存對比看是否還可以調大。從代碼層面上看，是否存在某些對象生命周期過長、持有狀態(tài)時間過長的情況，嘗試減少程序運行期間的內存消耗。
虛擬機棧和本地方法棧溢出
由于在 hotspot 虛擬機中并不區(qū)分虛擬機棧或者本地方法棧，因此對于 hotspot 而言，雖然 -xoss 參數(shù)存在，但是實際上是無效的，棧容量只由 -xss 參數(shù)設定。
異常再現(xiàn)
在單線程下，代碼采用如下的虛擬機參數(shù)：
|
1
|
-xss128k |
使用該參數(shù)減小棧容量，使用如下代碼復現(xiàn)異常：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
public class javavmstacksof { private int stacklength = 1; public void stackleak() { stacklength++; stackleak(); } public static void main(string[] args) throws throwable { javavmstacksof oom = new javavmstacksof(); try { oom.stackleak(); } catch (throwable e) { system.out.println("stack length:" + oom.stacklength); throw e; } }} |
解決方法
如果使用虛擬機默認參數(shù)，棧深度在大多數(shù)情況下（因為每個方法壓入棧的幀大小并不是一樣的，所以只能說在大多數(shù)情況下）達到1000 ~ 2000 完全沒有問題，對于正常的方法調用（包括遞歸），這個深度應該完全足夠。
但是，如果是因為建立過多的線程導致內存溢出，在不能減少線程數(shù)或者更換64位虛擬機的情況下，就只能通過減少最大堆和減少棧容量來換取更多的線程。
本機直接內存溢出
directmemory 容量可以通過 -xx ：maxdirectmemorysize 指定，如果不指定，則默認與java最大堆一樣。
異常再現(xiàn)
使用以下虛擬機參數(shù)：
|
1
|
-xmx20m -xx:maxdirectmemorysize=10m |
使用以下代碼重現(xiàn)異常：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class directmemoryoom { private static final int _1mb = 1024 * 1024; public static void main(string[] args) throws exception { field unsafefield = unsafe.class.getdeclaredfields()[0]; unsafefield.setaccessible(true); unsafe unsafe = (unsafe) unsafefield.get(null); while (true) { unsafe.allocatememory(_1mb);//直接申請分配內存 } }} |
解決方法
由 directmemory 導致的內存溢出，一個明顯的特征就是在heap dump 文件中不會看見明顯的異常。
如果發(fā)現(xiàn) oom 之后dump文件很小，而程序中又直接或者間接使用了nio ，那么就可以考慮檢查一下是不是這方面的原因。
以上就是我們整理的全部解決方法，感謝大家對服務器之家的支持。
