本篇內(nèi)容介紹了“如何檢查高并發(fā)多線程下的內(nèi)存泄漏問(wèn)題”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

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

現(xiàn)象：應(yīng)用的內(nèi)存在高并發(fā)下內(nèi)存持續(xù)增加，具體體現(xiàn)在早上7點(diǎn)，每秒處理2W，內(nèi)存增長(zhǎng)趨勢(shì)很快，分配給應(yīng)用的內(nèi)存最大值為4G，但是實(shí)際上容器節(jié)點(diǎn)的內(nèi)存使用率早已超過(guò)這個(gè)值，

通過(guò)top命令看到的內(nèi)存使用并不高，略高于4G，初步懷疑是容器統(tǒng)計(jì)有問(wèn)題，看了下內(nèi)存的狀態(tài)信息

cat /sys/fs/cgroup/memory/memory.stat

因?yàn)榘踩Ｃ芫壒剩韵聰?shù)據(jù)為例子數(shù)據(jù)，不是真實(shí)數(shù)據(jù)
cache 148365312
rss 5496782848
rss_huge 0
mapped_file 1605632
swap 0
pgpgin 3524638
pgpgout 2146428
pgfault 9691132
pgmajfault 44
inactive_anon 1142784
active_anon 5496709120
inactive_file 104824832
active_file 42397696
unevictable 0
hierarchical_memory_limit 8523934592
hierarchical_memsw_limit 8523934592
total_cache 148365312
total_rss 5492382848
total_rss_huge 0
total_mapped_file 1605632
total_swap 0
total_pgpgin 3524638
total_pgpgout 2146428
total_pgfault 9691132
total_pgmajfault 44
total_inactive_anon 1142784
total_active_anon 5423709120
total_inactive_file 104823832
total_active_file 42397696
total_unevictable 0

看了下內(nèi)存信息 cat /sys/fs/cgroup/memory/memory.meminfo

MemTotal:        8382308 kB
MemFree:         2874740 kB
Buffers:               0 kB
Cached:           145000 kB
SwapCached:            0 kB
Active:          5412308 kB
Inactive:         103516 kB
Active(anon):    5323724 kB
Inactive(anon):     1116 kB
Active(file):      41484 kB
Inactive(file):   102400 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:       5362300 kB
Mapped:             1568 kB
Shmem:                 0 kB
Slab:                  0 kB
SReclaimable:          0 kB
SUnreclaim:            0 kB
KernelStack:           0 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:           0 kB
Committed_AS:          0 kB
VmallocTotal:          0 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB

確實(shí)rss有點(diǎn)高

ps -p PID -o rss,vsz

rss特別高，一開始以為是cache導(dǎo)致內(nèi)存使用統(tǒng)計(jì)有問(wèn)題，但是看到rss很高可以確定不是cache造成的統(tǒng)計(jì)錯(cuò)誤。

rss很高的情況下，只有java應(yīng)用在跑著。

導(dǎo)出來(lái)的jmap堆棧：

jmap -dump:format=b,file=20210508heapdump.hprof pid

并沒有分析出具體的原因，只知道是加載器加載了大量的線程對(duì)象，這些對(duì)象都不大，但是量多。

這個(gè)時(shí)候想了下去拿內(nèi)存里面的信息看看吧，也懷疑是不是堆外內(nèi)存在增長(zhǎng)。

使用pmap查看進(jìn)程的內(nèi)存分配

pmap -x PID > 20210508pmap.txt

Address           Kbytes     RSS   Dirty Mode  Mapping
0000000700000000 4194304 4167772 4167772 rw---   [ anon ]
0000000800000000    7180    5284       0 r---- classes.jsa
0000000800703000    9204       0       0 -----   [ anon ]
0000000801000000   10996    5556    5196 rw--- classes.jsa
0000000801abd000    5388       0       0 -----   [ anon ]
0000000802000000    1552    1540     176 rw--- classes.jsa
0000000802184000    2544       0       0 -----   [ anon ]
0000000802400000      36      20       0 r-x-- classes.jsa
0000000802409000      84       0       0 -----   [ anon ]
000000080241e000   10240   10172   10172 rw---   [ anon ]
0000000802e1e000 1038336       0       0 -----   [ anon ]
00007fdebc000000     132      12      12 rw---   [ anon ]
00007fdebc021000   65404       0       0 -----   [ anon ]
00007fdec4000000     132       4       4 rw---   [ anon ]
00007fdec4021000   65404       0       0 -----   [ anon ]
00007fdec8000000     132       4       4 rw---   [ anon ]
00007fdec8021000   65404       0       0 -----   [ anon ]
00007fdecc000000     132       4       4 rw---   [ anon ]

發(fā)現(xiàn)很多RSS大小為40-160的內(nèi)存段，至少有2W個(gè)，這是及其不正常的，理論上是不應(yīng)該有這么多的。

這個(gè)時(shí)候用smaps可以輸出進(jìn)程使用的內(nèi)存塊詳細(xì)信息，包括地址范圍和來(lái)源

cat /proc/<pid>/smaps > 20210508smaps.txt
注：因?yàn)榘踩Ｃ芫壒剩韵聰?shù)據(jù)為例子數(shù)據(jù)，不是真實(shí)數(shù)據(jù)

802300000-80211000 r-xp 01345000 fc:10 13514
Size:                 36 kB
Rss:                  20 kB
Pss:                  20 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        20 kB
Private_Dirty:         0 kB
Referenced:           20 kB
Anonymous:             0 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
VmFlags: rd ex mr mw me 
803609000-80291e000 ---p 00000000 00:00 0 
Size:                 84 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
VmFlags: mr mw me nr

查看smaps.txt，找到有問(wèn)題的內(nèi)存塊地址，先從pmap中找到有問(wèn)題的地址，比如Address為000000080241e000的有問(wèn)題，則拿著80241e000去smaps找到對(duì)應(yīng)的地址段， 一般會(huì)有連續(xù)的一個(gè)地址段，找問(wèn)題對(duì)應(yīng)的size，因?yàn)檫B續(xù)的地址段可能存在別的內(nèi)存數(shù)據(jù)，但是肯定在前后，只需要size對(duì)應(yīng)上就大概率是這個(gè)內(nèi)存段數(shù)據(jù)。

假設(shè)現(xiàn)在找到有問(wèn)題的地址段為：

80241e000-802420000 ---p 00000000 00:00 0 
Size:                 1540 kB
Rss:                  1540 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
VmFlags: mr mw me nr

這個(gè)時(shí)候找到了內(nèi)存的地址段 ，就需要獲取這個(gè)內(nèi)存地址段上的數(shù)據(jù)，使用gdb神器。

gdb attach PID

這個(gè)時(shí)候會(huì)刷一大串代碼，進(jìn)入gdb命令行,在gdb下將上面找到的內(nèi)存段信息dump下來(lái)。

dump memory /tmp/20210508.dump 0x80241e000 0x802420000

這個(gè)時(shí)候在 /tmp/20210508.dump 可以找到該內(nèi)存段數(shù)據(jù)，可以自己用vim或者less慢慢找，也可以偷懶使用strings命令來(lái)幫忙找關(guān)鍵字。

顯示長(zhǎng)度超過(guò)8個(gè)字符的字符串。

strings -8 /tmp/20210508.dump

找到之后使用關(guān)鍵字再用less命令去文件里查找。

這時(shí)候大概能看到一串這樣的字符

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
insert xxx value(123,456,789) @@@@
https://qq.com,@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

看起來(lái)這個(gè)內(nèi)存地址段記錄的數(shù)據(jù)是某方法在寫入一個(gè)表的時(shí)候的操作，這是我們應(yīng)用某個(gè)方法塊的數(shù)據(jù)，找到對(duì)應(yīng)的方法塊上下文調(diào)用查了下，發(fā)現(xiàn)了問(wèn)題的所在，這個(gè)方法被調(diào)用的地方在局部new了一個(gè)線程池，線程池并沒有做shutdown操作，導(dǎo)致大量的線程雖然執(zhí)行好了但是在存在，所以內(nèi)存一直在增長(zhǎng)。

到了這里問(wèn)題基本上知道怎么解決了，將線程池扔出外面去，不要在局部new線程池，編譯發(fā)布，高并發(fā)模擬測(cè)試，內(nèi)存不再增長(zhǎng)。

“如何檢查高并發(fā)多線程下的內(nèi)存泄漏問(wèn)題”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

網(wǎng)站題目：如何檢查高并發(fā)多線程下的內(nèi)存泄漏問(wèn)題
網(wǎng)頁(yè)路徑：http://www.chinadenli.net/article14/jdjcge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、App設(shè)計(jì)、網(wǎng)站導(dǎo)航、微信公眾號(hào)、Google、ChatGPT

廣告

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