解Bug之路-记一次JVM堆外内存泄露Bug的查找
解Bug之路-记一次JVM堆外内存泄露Bug的查找 前言 JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔...
作者: 无毁的湖光-Al
{{emojiItem.symbol}}
删除一条评论
评论删除后，数据将无法恢复
公众号
视频号
问题反馈
深圳市奥思网络科技有限公司版权所有
粤ICP备12009483号
操作系统原理知识的重要性体现的淋漓尽致。
祝大牛事业有成，蒸蒸日上
博主的文章就像美酒，越发酵味更醇，真心希望博主多写点这类文章。
引用来自“文敦赋”的评论
大神，请教个问题！我的理解是OOM的原因是创建太多了的线程。标题中的：堆外内存 体现在哪个地方了？引用来自“我是无证程序员”的评论
你的思考很好，但是这样效率太低，在下传授一个快速定位和解决问题的方法给你。1.先看看内存哪个对象占用的内存最多。
2.去项目里搜索创建这个对象的代码。
3.检查代码确认并解决问题。
1.先看看内存哪个对象占用的内存最多。
2.去项目里搜索创建这个对象的代码。
3.检查代码确认并解决问题。
引用来自“FeiMcdull”的评论
问题挺明显的，随着请求不断进来，thread根本不会回收（thread类似一个守护进程，但是thread没有setdeamon）。值得学习的是楼主的问题定位和数据分析过程。
引用来自“无毁的湖光-Al”的评论
^_^，内存定量分析挺有意思引用来自“FeiMcdull”的评论
其实问题解决方式直接将new thread设置为守护线程应该不会出现这种情况（setDaemon(true)），不知道楼主最后怎么解决的。理论上守护线程会连同其主线程（用户请求线程）消亡而消亡引用来自“FeiMcdull”的评论
问题挺明显的，随着请求不断进来，thread根本不会回收（thread类似一个守护进程，但是thread没有setdeamon）。值得学习的是楼主的问题定位和数据分析过程。
引用来自“无毁的湖光-Al”的评论
^_^，内存定量分析挺有意思引用来自“FeiMcdull”的评论
问题挺明显的，随着请求不断进来，thread根本不会回收（thread类似一个守护进程，但是thread没有setdeamon）。值得学习的是楼主的问题定位和数据分析过程。
值得学习的是楼主的问题定位和数据分析过程。
引用来自“卓sir”的评论
可以可以，好文引用来自“pain_7”的评论
1. 一般避免直接 new Thread2. 在构造函数里面，new Thead 启动，应该会被内部类持有 this 引用吧，也不太好。可以在构造完成后调用启动，这样会不会好一些
2. 在构造函数里面，new Thead 启动，应该会被内部类持有 this 引用吧，也不太好。可以在构造完成后调用启动，这样会不会好一些
引用来自“苦苦奋斗的渣渣”的评论
构造方法里面new Thread也没有调用start方法啊引用来自“九州暮云”的评论
引用来自“无毁的湖光-Al”的评论
引用来自“九州暮云”的评论
你用jstack怎么看出多出来12563个线程？引用来自“无毁的湖光-Al”的评论
引用来自“九州暮云”的评论
你用jstack怎么看出多出来12563个线程？引用来自“鳄鱼的眼泪”的评论
不使用一些常用的cache库，非要重新造轮子的必然效应
引用来自“zigzagroad”的评论
这里主要原因不是使用了new Thread创建新线程，而是在新创建线程中的run方法永远在执行，造成线程不能正常退出运行。
引用来自“东胜神洲”的评论
之前在看别人的代码时，每次看到 new Thread()，我都会觉得不舒服：不会 new 太多而爆了吗？。。只是一直没碰到过爆例，你这个实例非常好！。。前人之鉴，后人之师啊。。（拱手）受教受教了。引用来自“市委书记李达康”的评论
牛逼引用来自“天选老司机”的评论
上首页了，花哥牛逼😆引用来自“梁国强-java”的评论
厉害，关注了
引用来自“sulinixl”的评论
这不是“内存泄漏”，只是线程太多太浪费而已。这种问题jmap、jstack一看就明白，jstack输出上万个线程时候，就应该知道有问题。一般生产环境应用几百个线程就够多了，毕竟CPU核心就那么多，线程太多也没有意义，还凭空浪费资源。引用来自“Jamson丶”的评论
生产系统上一直有个类似的问题，就是随着请求增加，线程也会增加，到了GC了就会被删掉回落，周而复始。排查了一轮还没处理好，不知道大佬你有没有什么想法？引用来自“hyuan”的评论
讲到linux知识这块就不太懂了😂引用来自“糖果先生”的评论
这种定时任务可以用Concurrent 的sdk写啊，写在构造函数里，不挂才怪，代码review的时候就应该发现这样的问题。
引用来自“一生做恶”的评论
过程挺屌，但是好像没治本呢
引用来自“开源中国首席圣杯守护者Saber”的评论
请问是用什么工具查看分析的？引用来自“Ryan-瑞恩”的评论
楼主，，，你使用 JProfile 看看堆外。引用来自“dxbj1010”的评论
看来写多线程代码的地方都需要注意啊引用来自“风车361”的评论
受教了引用来自“光脚满地跑”的评论
高并发场景下使用这种方式实现定时调度，看了想砍人哎，new出来2.8w个线程放在那里，想哭引用来自“晕dows”的评论
为什么我用firefox,chrome,ie,都看不到评论...顺便看一下我自己的能不能看到...
引用来自“unknown”的评论
分析过程受教了，出现问题的代码是太烂了引用来自“black83”的评论
牛批引用来自“九州暮云”的评论
你用jstack怎么看出多出来12563个线程？引用来自“淘淘我的小宝宝”的评论
大秀一番GC和fork肌肉，没对业务代码特别是sleep的深深忏悔，不怕中断吗，美中不足。望海涵。引用来自“阿信sxq”的评论
厉害，能弱弱的问一下，这个怎么修改吗，因为这里有一个类似的问题引用来自“淘淘我的小宝宝”的评论
大秀一番GC和fork肌肉，没对业务代码特别是sleep的深深忏悔，不怕中断吗，美中不足。望海涵。引用来自“爱喝貓的咖啡”的评论
又一个跪在new Thread()上的。。。Java thread所用内存是jvm向os额外申请的，直到进程结束前不释放，所以不停的new Thread()，jvm早晚会挂。顺便看一下我自己的能不能看到...
引用来自“爱喝貓的咖啡”的评论
又一个跪在new Thread()上的。。。Java thread所用内存是jvm向os额外申请的，直到进程结束前不释放，所以不停的new Thread()，jvm早晚会挂。
引用来自“harryxue12”的评论
体现了new Thread()带来的坑，如果他不sleep 那么久的话，可能能更早的发现问题。引用来自“爱宝贝丶”的评论
写的很好👍👍👍
引用来自“NoSuchMan”的评论
66666 菜鸟的我以前也看过博主的 其他问题排查的 文章 总结的非常到位 受教了
引用来自“开源中国首席董事长”的评论
牛逼。项目禁止 直接new Thread(); 特别是并发特别高的。
引用来自“周胜”的评论
博主大牛，特来膜拜引用来自“马进举”的评论
牛逼，我也有个看着有点像的问题，明天这样去排查看看，不过是win2008