掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。
十年品牌的成都網(wǎng)站建設(shè)公司,1000多家企業(yè)網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn).價(jià)格合理,可準(zhǔn)確把握網(wǎng)頁設(shè)計(jì)訴求.提供定制網(wǎng)站建設(shè)、商城建設(shè)、微信小程序、成都響應(yīng)式網(wǎng)站建設(shè)公司等服務(wù),我們?cè)O(shè)計(jì)的作品屢獲殊榮,是您值得信賴的專業(yè)的建站公司。
從小我就對(duì)Java有著深厚的感情，算下來有幾十年的Java經(jīng)驗(yàn)了。當(dāng)年的Java還是Sun公司的，我有著多年的Servlet經(jīng)驗(yàn)，CURD經(jīng)驗(yàn)，在現(xiàn)在已經(jīng)被自我革新，轉(zhuǎn)而研究人生的哲學(xué)。罷了，不吹了。本文是關(guān)于Java故障排查的，屬上篇。
為了保證文章的流暢性，我決定一口氣把它寫完。因?yàn)橄嚓P(guān)方面的培訓(xùn)做的多了，就不需要在寫的時(shí)候參考資料、翻源代碼。掐指一算，本文一個(gè)小時(shí)沒花掉，但篇幅已經(jīng)較長(zhǎng)了。
長(zhǎng)了，那就割斷。本篇就定為內(nèi)存排查的上篇，主要講一些原理。為什么要講原理?開車還需要了解汽車結(jié)構(gòu)么?
這還真不能相比。
汽車很少壞，出了問題你會(huì)花錢給拖車公司、4S店。你還會(huì)每年給它買上保險(xiǎn)。
反觀Java，三天兩頭出問題，找人解決還找不到人，給錢都不一定能解決問題。能比么?盤點(diǎn)來盤點(diǎn)去，最后只能靠自己。
1.內(nèi)存里都有啥
要想排查內(nèi)存問題，我們就需要看一下內(nèi)存里都有啥。我們先來看一下操作系統(tǒng)內(nèi)存的劃分，然后再來看一下JVM內(nèi)存的劃分。由于JVM本身是作為一個(gè)正常的應(yīng)用運(yùn)行在操作系統(tǒng)上的，所以它的行為同時(shí)會(huì)受到操作系統(tǒng)的限制。
2.操作系統(tǒng)內(nèi)存
我們首先從操作系統(tǒng)的實(shí)現(xiàn)來說起。通常情況下，我們寫了一個(gè)C語言程序，編譯后，會(huì)發(fā)現(xiàn)里面的內(nèi)存地址是固定的。其實(shí)我們的應(yīng)用程序在編譯之后，這些地址都是虛擬地址。他需要經(jīng)過一層翻譯之后，才能映射到真正的物理內(nèi)存，MMU就是負(fù)責(zé)地址轉(zhuǎn)換的硬件。
那我們操作系統(tǒng)的可用內(nèi)存到底是多少呢?它其實(shí)是分為兩部分的。一部分是物理內(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命令可以看到每一個(gè)進(jìn)程的內(nèi)存使用情況，我們平常關(guān)注的是RES這一列，它代表的是進(jìn)程實(shí)際的內(nèi)存占用，我們平常在搭建監(jiān)控系統(tǒng)的時(shí)候，監(jiān)控的也是這個(gè)數(shù)值。
我們?cè)賮砜匆幌耭ree命令的展示。它的展示其實(shí)是有一些混亂的，具體的關(guān)系可以看上面的圖。通常情況下，free顯示的數(shù)值都是比較小的，但這并不等于系統(tǒng)的可用內(nèi)存就那么一點(diǎn)點(diǎn)。Linux操作系統(tǒng)啟動(dòng)后，隨著機(jī)器的運(yùn)行，剩余內(nèi)存會(huì)迅速被buffer和cache這些緩沖區(qū)和緩存迅速占滿，而這些內(nèi)存再應(yīng)用的內(nèi)存空間不足時(shí)，是可以釋放的?？捎脙?nèi)存 = free + buffers + cached。
具體每一個(gè)區(qū)域的內(nèi)存使用情況，可以通過/proc/meminfo進(jìn)行查看的。
- # 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)建的大部分對(duì)象，都會(huì)存放在這里。所謂的垃圾回收，也主要針對(duì)的是這一部分。
多本JVM書籍描述：JVM中，除了程序計(jì)數(shù)器，其他區(qū)域都是可能溢出的。我們這里依然同意這個(gè)結(jié)論。下面僅對(duì)這些內(nèi)存區(qū)域做簡(jiǎn)要的介紹，因?yàn)橛行┲R(shí)對(duì)我們的內(nèi)存排查無益。
類比上面這張圖，我們可以歸位一些常用對(duì)象的分配位置。不要糾結(jié)什么棧上分配逃逸分析，也不用關(guān)注棧幀和操作數(shù)棧這種雙層的結(jié)構(gòu)，這些小細(xì)節(jié)對(duì)于對(duì)象的汪洋大海來說，影響實(shí)在是太小。我們關(guān)注的內(nèi)存區(qū)域，其實(shí)就只有堆內(nèi)內(nèi)存和堆外內(nèi)存兩個(gè)概念。
4.一圖解千愁，jvm內(nèi)存從來沒有這么簡(jiǎn)單過!
下面這篇文章，詳細(xì)的講解了每個(gè)區(qū)域。本來想要揉在一塊，但怕突出不了它的重要性。所以開始直接讀原文吧。
5.為什么會(huì)有內(nèi)存問題
統(tǒng)計(jì)顯示，我們平常的工作中，OOM/ML問題占比5%左右，平均處理時(shí)間卻達(dá)到40天左右。這就可以看出這種問題的排查，是非常的困難的。
但讓人無語的是，遇到內(nèi)存問題，工程師們的現(xiàn)場(chǎng)保護(hù)意識(shí)往往不足，特別的不足。只知道一個(gè)內(nèi)存溢出的結(jié)果，但什么都沒留下。監(jiān)控沒有，日志沒有，甚至連發(fā)生的時(shí)間點(diǎn)都不清楚。這樣的問題，鬼才知道原因。
6.垃圾回收器
內(nèi)存問題有兩種模式，一種是內(nèi)存溢出，一種是內(nèi)存泄漏。
內(nèi)存問題影響也是非常大的，比如下面這三種場(chǎng)景。
說到這卡頓問題，就不得不提一嘴垃圾回收器。
很多同學(xué)一看上面的圖，就知道我們要說G1垃圾回收器了，這也是我的推薦。CMS等垃圾回收器，回收時(shí)間不可控，如果你有條件，當(dāng)然要避免使用，CMS也將要在Java14中被移除，我也真心不希望你掌握一些即將過時(shí)的經(jīng)驗(yàn)。ZGC雖然厲害，但還太新，幾乎沒有人敢吃螃蟹，那剩下的就是G1了。
G1通過三個(gè)簡(jiǎn)單的配置參數(shù)，大部分情況下即可獲取優(yōu)異的性能，工程師幸福了很多。三個(gè)參數(shù)如下：
如果你還是不放心，想要了解一下G1的原理，那我們也可以捎帶提上兩嘴。G1其實(shí)還是有年輕代老年代的概念的，只不過它的內(nèi)存是不連續(xù)的。
如圖所示，G1將內(nèi)存切分成大小相等的區(qū)域，這些區(qū)域叫做小堆區(qū)，是垃圾回收的最小單位。以前的垃圾回收器都是整代回收，而G1是部分回收，那就可以根據(jù)配置的最小延遲時(shí)間合理的選取小堆區(qū)的數(shù)量，回收過程就顯得智能了很多。
7.重要概念GC Roots
如圖所示，要確定哪些是垃圾，就需要有一種找到垃圾的方法。其實(shí)，我們上一句的表述是不正確的。在JVM中，找垃圾的方法和我們理解的正好相反：它是首先找到存活的對(duì)象，對(duì)存活的對(duì)象做標(biāo)記，然后把其他對(duì)象一股腦的回收掉。
JVM在垃圾回收時(shí)，關(guān)心的是不要把不是垃圾的對(duì)象給回收了，而不是把垃圾對(duì)象給清理的干干凈凈。
要找到哪些是存活對(duì)象，就需要從源頭上追溯。在JVM中，常見的GC Roots就有靜態(tài)的成員變量等，比如一個(gè)靜態(tài)的HashMap。
另外一部分，就是線程所關(guān)聯(lián)的虛擬機(jī)棧和本地方法棧里面的內(nèi)容。
我們說了這老半天，其實(shí)這種追溯方式有一個(gè)專有的名詞：可達(dá)性分析法。與之類似的還有引用計(jì)數(shù)法，但由于有環(huán)形依賴的問題，所以幾乎沒有回收器使用這種形式。
并不是說只要是和GC Roots有一條聯(lián)系(Reference Chain)，對(duì)象就是存活的，它還與對(duì)象的引用級(jí)別有關(guān)。
平常情況下，我們使用的對(duì)象就是強(qiáng)引用。軟引用和弱引用在一些緩存框架中用的比較廣泛，對(duì)象的重要程度也比較弱。
8.對(duì)象的提升
大多數(shù)垃圾回收器都是分代垃圾回收，我們從上面對(duì)G1的描述就能夠看出來。
如圖所示，是典型的分代回收內(nèi)存模型。對(duì)象從年輕代提升到老年代，有四種方式。
對(duì)于垃圾回收器的優(yōu)化，就是要確保盡量多的對(duì)象在年輕代里分配，減少對(duì)象提升到老年代的可能。雖然這種思想在G1里弱化了許多。
End了解了操作系統(tǒng)的內(nèi)存里都有啥，又了解了JVM的內(nèi)存里都有啥，我們就可以淡定縱容的針對(duì)于每一種出現(xiàn)問題的情況，進(jìn)行針對(duì)性排查和優(yōu)化。
文章到這里嘎然而止。下一篇，我們以幾個(gè)實(shí)際的案例，來看一下Java的內(nèi)存問題排查的具體過程。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)