今天給大家介紹一下Disruptor發(fā)生內(nèi)存溢出的示例分析。文章的內(nèi)容小編覺得不錯，現(xiàn)在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著小編的思路一起來閱讀吧。

成都創(chuàng)新互聯(lián)公司專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、青山湖網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5開發(fā)、商城建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為青山湖等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

前言

OutOfMemoryError 問題相信很多朋友都遇到過，相對于常見的業(yè)務(wù)異常（數(shù)組越界、空指針等）來說這類問題是很難定位和解決的。

下面以最近碰到的一次線上內(nèi)存溢出的定位、解決問題的方式展開。

主要從表現(xiàn)-->排查-->定位-->解決 四個步驟來分析和解決問題。

表象

最近我們生產(chǎn)上的一個應(yīng)用不斷的爆出內(nèi)存溢出，并且隨著業(yè)務(wù)量的增長出現(xiàn)的頻次越來越高。

該程序的業(yè)務(wù)邏輯非常簡單，就是從 Kafka 中將數(shù)據(jù)消費下來然后批量的做持久化操作。

而現(xiàn)象則是隨著 Kafka 的消息越多，出現(xiàn)的異常的頻次就越快。由于當時還有其他工作所以只能讓運維做重啟，并且監(jiān)控好堆內(nèi)存以及 GC 情況。

重啟大法雖好，可是依然不能根本解決問題。

排查

于是我們想根據(jù)運維之前收集到的內(nèi)存數(shù)據(jù)、GC 日志嘗試判斷哪里出現(xiàn)問題。

結(jié)果發(fā)現(xiàn)老年代的內(nèi)存使用就算是發(fā)生 GC 也一直居高不下，而且隨著時間推移也越來越高。

結(jié)合 jstat 的日志發(fā)現(xiàn)就算是發(fā)生了 FGC 老年代也已經(jīng)回收不了，內(nèi)存已經(jīng)到頂。

甚至有幾臺應(yīng)用 FGC 達到了上百次，時間也高的可怕。

這說明應(yīng)用的內(nèi)存使用肯定是有問題的，有許多賴皮對象始終回收不掉。

定位

由于生產(chǎn)上的內(nèi)存 dump 文件非常大，達到了幾十G。也是由于我們的內(nèi)存設(shè)置太大有關(guān)。

所以導致想使用 MAT 分析需要花費大量時間。

因此我們便想是否可以在本地復現(xiàn)，這樣就要好定位的多。

為了盡快的復現(xiàn)問題，我將本地應(yīng)用大堆內(nèi)存設(shè)置為 150M。

然后在消費 Kafka 那里 Mock 為一個 while 循環(huán)一直不斷的生成數(shù)據(jù)。

同時當應(yīng)用啟動之后利用 VisualVM 連上應(yīng)用實時監(jiān)控內(nèi)存、GC 的使用情況。

結(jié)果跑了 10 幾分鐘內(nèi)存使用并沒有什么問題。根據(jù)圖中可以看出，每產(chǎn)生一次 GC 內(nèi)存都能有效的回收，所以這樣并沒有復現(xiàn)問題。

沒法復現(xiàn)問題就很難定位了。于是我們 review 代碼，發(fā)現(xiàn)生產(chǎn)的邏輯和我們用 while 循環(huán) Mock 數(shù)據(jù)還不太一樣。

查看生產(chǎn)的日志發(fā)現(xiàn)每次從 Kafka 中取出的都是幾百條數(shù)據(jù)，而我們 Mock 時每次只能產(chǎn)生一條。

為了盡可能的模擬生產(chǎn)情況便在服務(wù)器上跑著一個生產(chǎn)者程序，一直源源不斷的向 Kafka 中發(fā)送數(shù)據(jù)。

果然不出意外只跑了一分多鐘內(nèi)存就頂不住了，觀察左圖發(fā)現(xiàn) GC 的頻次非常高，但是內(nèi)存的回收卻是相形見拙。

同時后臺也開始打印內(nèi)存溢出了，這樣便復現(xiàn)出問題。

解決

從目前的表現(xiàn)來看就是內(nèi)存中有許多對象一直存在強引用關(guān)系導致得不到回收。

于是便想看看到底是什么對象占用了這么多的內(nèi)存，利用 VisualVM 的 HeapDump 功能可以立即 dump 出當前應(yīng)用的內(nèi)存情況。

結(jié)果發(fā)現(xiàn) com.lmax.disruptor.RingBuffer 類型的對象占用了將近 50% 的內(nèi)存。

看到這個包自然就想到了 Disruptor 環(huán)形隊列。

再次 review 代碼發(fā)現(xiàn)：從 Kafka 里取出的 700 條數(shù)據(jù)是直接往 Disruptor 里丟的。

這里也就能說明為什么第一次模擬數(shù)據(jù)沒復現(xiàn)問題了。

模擬的時候是一個對象放進隊列里，而生產(chǎn)的情況是 700 條數(shù)據(jù)放進隊列里。這個數(shù)據(jù)量是 700 倍的差距。

而 Disruptor 作為一個環(huán)形隊列，再對象沒有被覆蓋之前是一直存在的。

我也做了一個實驗，證明確實如此。

我設(shè)置隊列大小為 8 ，從 0~9 往里面寫 10 條數(shù)據(jù)，當寫到 8 的時候就會把之前 0 的位置覆蓋掉，后面的以此類推（類似于 HashMap 的取模定位）。

所以在生產(chǎn)上假設(shè)我們的隊列大小是 1024，那么隨著系統(tǒng)的運行最終肯定會導致 1024 個位置上裝滿了對象，而且每個位置是 700 個！

于是查看了生產(chǎn)上 Disruptor 的 RingBuffer 配置，結(jié)果是：1024*1024。

這個數(shù)量級就非常嚇人了。

為了驗證是否是這個問題，我在本地將該值換為 2 ，一個最小值試試。

同樣的 128M 內(nèi)存，也是通過 Kafka 一直源源不斷的取出數(shù)據(jù)。通過監(jiān)控如下：

跑了 20 幾分鐘系統(tǒng)一切正常，每當一次 GC 都能回收大部分內(nèi)存，最終呈現(xiàn)鋸齒狀。

這樣問題就找到了，不過生產(chǎn)上這個值具體設(shè)置多少還得根據(jù)業(yè)務(wù)情況測試才能知道，但原有的 1024*1024 是絕對不能再使用了。

雖然到了最后也就改了一行代碼(還沒改，直接修改配置)，但這排查過程我覺得是有意義的。

也會讓大部分覺得 JVM 這樣的黑盒難以下手的同學有一個直觀的感受。

同時也得感嘆 Disruptor 東西雖好，也不能亂用哦！

以上就是Disruptor發(fā)生內(nèi)存溢出的示例分析的全部內(nèi)容了，更多與Disruptor發(fā)生內(nèi)存溢出的示例分析相關(guān)的內(nèi)容可以搜索創(chuàng)新互聯(lián)之前的文章或者瀏覽下面的文章進行學習哈！相信小編會給大家增添更多知識,希望大家能夠支持一下創(chuàng)新互聯(lián)！

新聞標題：Disruptor發(fā)生內(nèi)存溢出的示例分析-創(chuàng)新互聯(lián)
文章分享：http://www.chinadenli.net/article44/cccgee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、品牌網(wǎng)站設(shè)計、營銷型網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計公司、域名注冊、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)