布控預(yù)警的需求

在布控預(yù)警的需求實(shí)現(xiàn)里，我需要把持久化在數(shù)據(jù)庫中的布控對象（身份證、姓名、手機(jī)號(hào)、imsi、faceId等等都可分別作為布控對象）一直往kafka里發(fā)送，然后由flink進(jìn)行消費(fèi)，把當(dāng)前的布控對象和存儲(chǔ)的用戶軌跡記錄（有旅客、航班、車輛卡口、人臉等等數(shù)據(jù)）同時(shí)包含身份證、姓名等等信息進(jìn)行比對，如果比對成功則觸發(fā)布控預(yù)警
最開始我是通過單線程發(fā)送，發(fā)現(xiàn)發(fā)送速度有點(diǎn)慢，這里面我需要把布控對象做一些處理（比如split,flat,fitler）后才發(fā)送到kafka，大概30w+的布控對象需要十多分鐘那邊才能預(yù)警到，于是開始進(jìn)行性能優(yōu)化，使用并行流進(jìn)行處理，改變之后同樣30w的數(shù)據(jù)這次只需要8秒左右就能發(fā)送完成，然而跑了一陣之后程序開始出現(xiàn)報(bào)錯(cuò)

Received invalid metadata error in produce request on partition xxxTopic due to org.apache.kafka.common.errors.

NetworkException: The server disconnected before a response was received.. Going to request metadata update now

報(bào)錯(cuò)分析

第一眼看到這個(gè)錯(cuò)，我以為是kafka或者網(wǎng)絡(luò)出問題了，也去看了broker的日志，發(fā)現(xiàn)是有一些關(guān)于當(dāng)前topic被刪除的錯(cuò)誤，但是日志級別只是一個(gè)info，我以為是topic出現(xiàn)錯(cuò)誤，又嘗試了使用kakfa的消費(fèi)命令，發(fā)現(xiàn)是能夠正常消費(fèi)的，說明這個(gè)topic和metadata應(yīng)該是沒有問題的。

我也在網(wǎng)上搜索著，發(fā)現(xiàn)很少有這個(gè)問題的說明，但是我發(fā)現(xiàn)了一些特征，經(jīng)過我重啟后程序又是可以繼續(xù)發(fā)送的，而且速度還是很快，但是跑了一會(huì)兒，開始又有這個(gè)報(bào)錯(cuò)了，開始是一個(gè)報(bào)錯(cuò)，其他的都成功，后來是慢慢的，報(bào)錯(cuò)越來越多，成功的越來越少。接著過了很久竟然還發(fā)生了nacos的心跳超時(shí)導(dǎo)致服務(wù)不可用的情況。

我這時(shí)想到了之前看過的一些文章，說頻繁fullgc可能會(huì)導(dǎo)致心跳請求失敗的問題，最開始的時(shí)候看了cpu使用率，發(fā)現(xiàn)非常高，600%左右，我以為是因?yàn)槲业某绦蚶锩嬉驗(yàn)槭怯卸〞r(shí)任務(wù)去循環(huán)發(fā)送消息所有有點(diǎn)占用是正常的，沒有當(dāng)回事，后來我用起了arthas和gc命令，先使用dashboard，看了下cpu線程，發(fā)現(xiàn)gc線程占用以及那個(gè)并行流forkjoinpool的線程占用非常大的cpu利用率，然后full gc次數(shù)非常多，又使用

jstat -gcutil $pid 1000

命令進(jìn)行確認(rèn)，開始我就發(fā)現(xiàn)了old區(qū)的占用比非常高，且fullgc的頻率非常高，幾乎是幾秒鐘就有一次，最重要的是，最開始是能回收一些內(nèi)存，隨著時(shí)間的推移，old區(qū)占用比基線一直在增長，最后到了100，在這個(gè)過程中我也發(fā)現(xiàn)了，出現(xiàn)報(bào)錯(cuò)的頻率和old區(qū)占用比之間是存在關(guān)系的，報(bào)錯(cuò)越來越多的時(shí)候，old區(qū)被占用的越多，fullgc越頻繁。

內(nèi)存泄漏

這里我才意識(shí)到這是出現(xiàn)內(nèi)存泄漏的問題了吧，可能是我寫的代碼有點(diǎn)問題，于是我繼續(xù)開始排查，通過

jmap dump:format=b,file=xx.hprof $pid

然后導(dǎo)出文件到本地，用java visualvm打開（也可以用mat或者idea的profiler進(jìn)行解析，我這里用visualvm解析類實(shí)例的還報(bào)了堆內(nèi)存不足，要改一下/lib/visualvm/etc/visualvm.conf，把-xms改大點(diǎn)）

查看了一下占用最大的幾個(gè)對象ObjectiveVO（這個(gè)是我推送到kafka的封裝對象）、LogUtil.$$(這個(gè)是我發(fā)送消息的工具類)、java.util.concurrent.LinkedBlockingDeque$NODE，還有char[]、String這幾個(gè)占用是比較大的，看到這里我逐漸清晰了，在logUtil里面的代碼我是從其他需要發(fā)送日志的地方拷過來的，在這里我加了一個(gè)異步executor的操作，主要就是為了隔離業(yè)務(wù)和日志的發(fā)送或者發(fā)生異常的情況，然而，我把這個(gè)executor的線程池隊(duì)列設(shè)置為了new LinkedBlockingDeque<>()，這個(gè)的隊(duì)列的默認(rèn)長度值為Integer.MAX，因?yàn)槲覀兊南到y(tǒng)屬于to G系統(tǒng)，所以操作日志是比較少的，一直沒有發(fā)現(xiàn)這個(gè)問題，而在這個(gè)布控發(fā)送Kafka的場景中，數(shù)據(jù)量非常大，8秒鐘左右差不多就是30w的數(shù)據(jù)，為了快速實(shí)現(xiàn)布控我甚至在外層又加了一個(gè)并行流，然后這里logUtil里面又有一個(gè)異步把ObjectiveVO加入到隊(duì)列，所以才導(dǎo)致的內(nèi)存溢出了....

后面我把這個(gè)異步executor去掉了，就沒有發(fā)生內(nèi)存溢出的問題，也就沒有發(fā)生上面報(bào)的NetworkException，或者如果要使用線程池異步的話，一定要設(shè)計(jì)一下隊(duì)列的長度，以及拒絕策略！??！

以上就是線程池調(diào)用kafka發(fā)送消息產(chǎn)生的內(nèi)存泄漏問題的詳細(xì)內(nèi)容，更多關(guān)于kafka發(fā)送消息內(nèi)存泄漏的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論