Java內(nèi)存故障？只是因為你不夠帥！
本文轉(zhuǎn)載自微信公眾號「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請聯(lián)系小姐姐味道公眾號。
從小我就對Java有著深厚的感情，算下來有幾十年的Java經(jīng)驗了。當年的Java還是Sun公司的，我有著多年的Servlet經(jīng)驗，CURD經(jīng)驗，在現(xiàn)在已經(jīng)被自我革新，轉(zhuǎn)而研究人生的哲學。罷了，不吹了。本文是關(guān)于Java故障排查的，屬上篇。
為了保證文章的流暢性，我決定一口氣把它寫完。因為相關(guān)方面的培訓做的多了，就不需要在寫的時候參考資料、翻源代碼。掐指一算，本文一個小時沒花掉，但篇幅已經(jīng)較長了。
長了，那就割斷。本篇就定為內(nèi)存排查的上篇，主要講一些原理。為什么要講原理?開車還需要了解汽車結(jié)構(gòu)么?
這還真不能相比。
汽車很少壞，出了問題你會花錢給拖車公司、4S店。你還會每年給它買上保險。
反觀Java，三天兩頭出問題，找人解決還找不到人，給錢都不一定能解決問題。能比么?盤點來盤點去，最后只能靠自己。
- 1.內(nèi)存里都有啥
- 2.操作系統(tǒng)內(nèi)存
- 3.JVM內(nèi)存劃分
- 4.一圖解千愁，jvm內(nèi)存從來沒有這么簡單過!
- 5.為什么會有內(nèi)存問題
- 6.垃圾回收器
- 7.重要概念GC Roots
- 8.對象的提升
1.內(nèi)存里都有啥
要想排查內(nèi)存問題，我們就需要看一下內(nèi)存里都有啥。我們先來看一下操作系統(tǒng)內(nèi)存的劃分，然后再來看一下JVM內(nèi)存的劃分。由于JVM本身是作為一個正常的應用運行在操作系統(tǒng)上的，所以它的行為同時會受到操作系統(tǒng)的限制。
2.操作系統(tǒng)內(nèi)存
我們首先從操作系統(tǒng)的實現(xiàn)來說起。通常情況下，我們寫了一個C語言程序，編譯后，會發(fā)現(xiàn)里面的內(nèi)存地址是固定的。其實我們的應用程序在編譯之后，這些地址都是虛擬地址。他需要經(jīng)過一層翻譯之后，才能映射到真正的物理內(nèi)存，MMU就是負責地址轉(zhuǎn)換的硬件。
那我們操作系統(tǒng)的可用內(nèi)存到底是多少呢?它其實是分為兩部分的。一部分是物理內(nèi)存，指的是我們插的那根內(nèi)存條;另一部分就是使用磁盤模擬的虛擬內(nèi)存，在Linux通常稱做swap分區(qū)。所以，可用內(nèi)存 = 物理內(nèi)存 + 虛擬內(nèi)存。如果你的系統(tǒng)開了swap，可用內(nèi)存就比物理內(nèi)存大。
通過top命令和free命令都可以看到內(nèi)存的使用情況。
top命令可以看到每一個進程的內(nèi)存使用情況，我們平常關(guān)注的是RES這一列，它代表的是進程實際的內(nèi)存占用，我們平常在搭建監(jiān)控系統(tǒng)的時候，監(jiān)控的也是這個數(shù)值。
我們再來看一下free命令的展示。它的展示其實是有一些混亂的，具體的關(guān)系可以看上面的圖。通常情況下，free顯示的數(shù)值都是比較小的，但這并不等于系統(tǒng)的可用內(nèi)存就那么一點點。Linux操作系統(tǒng)啟動后，隨著機器的運行，剩余內(nèi)存會迅速被buffer和cache這些緩沖區(qū)和緩存迅速占滿，而這些內(nèi)存再應用的內(nèi)存空間不足時，是可以釋放的。可用內(nèi)存 = free + buffers + cached。
具體每一個區(qū)域的內(nèi)存使用情況，可以通過/proc/meminfo進行查看的。
- # cat /proc/meminfo
- MemTotal: 3881692 kB
- MemFree: 249248 kB
- MemAvailable: 1510048 kB
- Buffers: 92384 kB
- Cached: 1340716 kB
- 40+ more ...
3.JVM內(nèi)存劃分
接下來，我們才來看一下JVM的內(nèi)存區(qū)域劃分。
在JVM中，最大的內(nèi)存區(qū)域就是堆，我們平常創(chuàng)建的大部分對象，都會存放在這里。所謂的垃圾回收，也主要針對的是這一部分。
多本JVM書籍描述：JVM中，除了程序計數(shù)器，其他區(qū)域都是可能溢出的。我們這里依然同意這個結(jié)論。下面僅對這些內(nèi)存區(qū)域做簡要的介紹，因為有些知識對我們的內(nèi)存排查無益。
- 堆：JVM堆中的數(shù)據(jù)，是共享的，是占用內(nèi)存最大的一塊區(qū)域
- 虛擬機棧：Java虛擬機棧，是基于線程的，用來服務字節(jié)碼指令的運行
- 程序計數(shù)器：當前線程所執(zhí)行的字節(jié)碼的行號指示器
- 元空間：方法區(qū)就在這里，非堆 本地內(nèi)存：其他的內(nèi)存占用空間
類比上面這張圖，我們可以歸位一些常用對象的分配位置。不要糾結(jié)什么棧上分配逃逸分析，也不用關(guān)注棧幀和操作數(shù)棧這種雙層的結(jié)構(gòu)，這些小細節(jié)對于對象的汪洋大海來說，影響實在是太小。我們關(guān)注的內(nèi)存區(qū)域，其實就只有堆內(nèi)內(nèi)存和堆外內(nèi)存兩個概念。
4.一圖解千愁，jvm內(nèi)存從來沒有這么簡單過!
下面這篇文章，詳細的講解了每個區(qū)域。本來想要揉在一塊，但怕突出不了它的重要性。所以開始直接讀原文吧。
5.為什么會有內(nèi)存問題
統(tǒng)計顯示，我們平常的工作中，OOM/ML問題占比5%左右，平均處理時間卻達到40天左右。這就可以看出這種問題的排查，是非常的困難的。
但讓人無語的是，遇到內(nèi)存問題，工程師們的現(xiàn)場保護意識往往不足，特別的不足。只知道一個內(nèi)存溢出的結(jié)果，但什么都沒留下。監(jiān)控沒有，日志沒有，甚至連發(fā)生的時間點都不清楚。這樣的問題，鬼才知道原因。
6.垃圾回收器
內(nèi)存問題有兩種模式，一種是內(nèi)存溢出，一種是內(nèi)存泄漏。
- 內(nèi)存溢出 OutOfMemoryError，簡稱OOM，堆是最常見的情況，堆外內(nèi)存排查困難。
- 內(nèi)存泄漏 Memory Leak，簡稱ML，主要指的是分配的內(nèi)存沒有得到釋放。內(nèi)存一直在增長，有OOM風險;GC時該回收的回收不掉;或者能夠回收掉但很快又占滿，產(chǎn)生壓力。
內(nèi)存問題影響也是非常大的，比如下面這三種場景。
- 發(fā)生OOM Error，應用停止(最嚴重)
- 頻繁GC，GC時間長，GC線程時間片占用高
- 服務卡頓，請求響應時間變長
說到這卡頓問題，就不得不提一嘴垃圾回收器。
很多同學一看上面的圖，就知道我們要說G1垃圾回收器了，這也是我的推薦。CMS等垃圾回收器，回收時間不可控，如果你有條件，當然要避免使用，CMS也將要在Java14中被移除，我也真心不希望你掌握一些即將過時的經(jīng)驗。ZGC雖然厲害，但還太新，幾乎沒有人敢吃螃蟹，那剩下的就是G1了。
G1通過三個簡單的配置參數(shù)，大部分情況下即可獲取優(yōu)異的性能，工程師幸福了很多。三個參數(shù)如下：
- MaxGCPauseMillis 預定目標，自動調(diào)整。
- G1HeapRegionSize 小堆區(qū)大小。
- InitiatingHeapOccupancyPercent 堆內(nèi)存比例閾值，啟動并發(fā)標記。
如果你還是不放心，想要了解一下G1的原理，那我們也可以捎帶提上兩嘴。G1其實還是有年輕代老年代的概念的，只不過它的內(nèi)存是不連續(xù)的。
如圖所示，G1將內(nèi)存切分成大小相等的區(qū)域，這些區(qū)域叫做小堆區(qū)，是垃圾回收的最小單位。以前的垃圾回收器都是整代回收，而G1是部分回收，那就可以根據(jù)配置的最小延遲時間合理的選取小堆區(qū)的數(shù)量，回收過程就顯得智能了很多。
7.重要概念GC Roots
如圖所示，要確定哪些是垃圾，就需要有一種找到垃圾的方法。其實，我們上一句的表述是不正確的。在JVM中，找垃圾的方法和我們理解的正好相反：它是首先找到存活的對象，對存活的對象做標記，然后把其他對象一股腦的回收掉。
JVM在垃圾回收時，關(guān)心的是不要把不是垃圾的對象給回收了，而不是把垃圾對象給清理的干干凈凈。
要找到哪些是存活對象，就需要從源頭上追溯。在JVM中，常見的GC Roots就有靜態(tài)的成員變量等，比如一個靜態(tài)的HashMap。
另外一部分，就是線程所關(guān)聯(lián)的虛擬機棧和本地方法棧里面的內(nèi)容。
我們說了這老半天，其實這種追溯方式有一個專有的名詞：可達性分析法。與之類似的還有引用計數(shù)法，但由于有環(huán)形依賴的問題，所以幾乎沒有回收器使用這種形式。
并不是說只要是和GC Roots有一條聯(lián)系(Reference Chain)，對象就是存活的，它還與對象的引用級別有關(guān)。
- 強引用：屬于最普通最強硬的一種存在，只有在和GC Roots斷絕關(guān)系時，才會被消滅掉
- 軟引用：只有在內(nèi)存不足時，系統(tǒng)則會回收軟引用對象
- 弱引用：當JVM進行垃圾回收時，無論內(nèi)存是否充足，都會回收被弱引用關(guān)聯(lián)的對象
- 虛引用：虛引用主要用來跟蹤對象被垃圾回收的活動
平常情況下，我們使用的對象就是強引用。軟引用和弱引用在一些緩存框架中用的比較廣泛，對象的重要程度也比較弱。
8.對象的提升
大多數(shù)垃圾回收器都是分代垃圾回收，我們從上面對G1的描述就能夠看出來。
如圖所示，是典型的分代回收內(nèi)存模型。對象從年輕代提升到老年代，有四種方式。
- 常規(guī)提升，對象夠老。比如從from到to轉(zhuǎn)了15圈還沒有被回收掉?？刂茀?shù)就是-XX:MaxTenuringThreshold。這個值在CMS下默認為6，G1下默認為15
- 分配擔保 Survivor 空間不夠，老年代擔保。
- 大對象直接在老年代分配
- 動態(tài)對象年齡判定。比如在G1里的TenuringThreshold會隨著堆內(nèi)對象的分布而變化
對于垃圾回收器的優(yōu)化，就是要確保盡量多的對象在年輕代里分配，減少對象提升到老年代的可能。雖然這種思想在G1里弱化了許多。
End了解了操作系統(tǒng)的內(nèi)存里都有啥，又了解了JVM的內(nèi)存里都有啥，我們就可以淡定縱容的針對于每一種出現(xiàn)問題的情況，進行針對性排查和優(yōu)化。
文章到這里嘎然而止。下一篇，我們以幾個實際的案例，來看一下Java的內(nèi)存問題排查的具體過程。
