如何检查高并发多线程下的内存泄漏问题
本篇内容介绍了“如何检查高并发多线程下的内存泄漏问题”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
成都创新互联公司专注于企业营销型网站建设、网站重做改版、源汇网站定制设计、自适应品牌网站建设、H5开发、成都做商城网站、集团公司官网建设、成都外贸网站制作、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为源汇等各大城市提供网站开发制作服务。
现象：应用的内存在高并发下内存持续增加，具体体现在早上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//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线程池，编译发布，高并发模拟测试，内存不再增长。
“如何检查高并发多线程下的内存泄漏问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
文章题目：如何检查高并发多线程下的内存泄漏问题
转载来源：http://azwzsj.com/article/jdjcge.html
