如何检查高并发多线程下的内存泄漏问题

本篇内容介绍了“如何检查高并发多线程下的内存泄漏问题”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

现象：应用的内存在高并发下内存持续增加，具体体现在早上7点，每秒处理2W，内存增长趋势很快，分配给应用的内存最大值为4G，但是实际上容器节点的内存使用率早已超过这个值，

通过top命令看到的内存使用并不高，略高于4G，初步怀疑是容器统计有问题，看了下内存的状态信息

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

因为安全保密缘故，以下数据为例子数据，不是真实数据
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

看了下内存信息 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

确实rss有点高

ps -p PID -o rss,vsz

rss特别高，一开始以为是cache导致内存使用统计有问题，但是看到rss很高可以确定不是cache造成的统计错误。

rss很高的情况下，只有java应用在跑着。

导出来的jmap堆栈：

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

并没有分析出具体的原因，只知道是加载器加载了大量的线程对象，这些对象都不大，但是量多。

这个时候想了下去拿内存里面的信息看看吧，也怀疑是不是堆外内存在增长。

使用pmap查看进程的内存分配

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 ]

发现很多RSS大小为40-160的内存段，至少有2W个，这是及其不正常的，理论上是不应该有这么多的。

这个时候用smaps可以输出进程使用的内存块详细信息，包括地址范围和来源

cat /proc/<pid>/smaps > 20210508smaps.txt
注：因为安全保密缘故，以下数据为例子数据，不是真实数据

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，找到有问题的内存块地址，先从pmap中找到有问题的地址，比如Address为000000080241e000的有问题，则拿着80241e000去smaps找到对应的地址段， 一般会有连续的一个地址段，找问题对应的size，因为连续的地址段可能存在别的内存数据，但是肯定在前后，只需要size对应上就大概率是这个内存段数据。

假设现在找到有问题的地址段为：

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

这个时候找到了内存的地址段 ，就需要获取这个内存地址段上的数据，使用gdb神器。

gdb attach PID

这个时候会刷一大串代码，进入gdb命令行,在gdb下将上面找到的内存段信息dump下来。

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

这个时候在 /tmp/20210508.dump 可以找到该内存段数据，可以自己用vim或者less慢慢找，也可以偷懒使用strings命令来帮忙找关键字。

显示长度超过8个字符的字符串。

strings -8 /tmp/20210508.dump

找到之后使用关键字再用less命令去文件里查找。

这时候大概能看到一串这样的字符

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

看起来这个内存地址段记录的数据是某方法在写入一个表的时候的操作，这是我们应用某个方法块的数据，找到对应的方法块上下文调用查了下，发现了问题的所在，这个方法被调用的地方在局部new了一个线程池，线程池并没有做shutdown操作，导致大量的线程虽然执行好了但是在存在，所以内存一直在增长。

到了这里问题基本上知道怎么解决了，将线程池扔出外面去，不要在局部new线程池，编译发布，高并发模拟测试，内存不再增长。

“如何检查高并发多线程下的内存泄漏问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！