我是风筝,公众号「古时的风筝」,一个不只有技术的技术公众号,一个在程序圈混迹多年,主业 Java,另外 Python、React 也玩儿的 6 的斜杠开发者。 Spring Cloud 系列文章已经完成,可以到 我的 github 上查看系列完整内容。也可以在公众号内回复「pdf」获取我精心制作的 pdf 版完整教程。
话说那天中午吃饭的时候,一个同事说:“那个项目组的人快气死我了,程序有问题,早晨在群里@了他们,到中午才回消息,然后竟然还说他们的程序没有问题,是我们这边调用的太频繁了。简直想笑。”
一般来说,对接出现问题,如果不是错误太明显,我首先都会先怀疑是不是自己出了问题,以免到时候丢人。所以我说,吃完饭回去我帮你排查一下,看问题到底出在哪里。
我们当前这个系统和很多的第三方系统做了集成,出问题的就是其中一个三方系统。其实很简单,他们的系统会产生一些个人待办任务,然后待办任务的个数需要推送到我们的 APP 上,作为图标的角标显示。
用户数据已经打通,其实很简单的需求,角标通知也不要求实时,10分钟刷一次就可以。这个场景非常典型,用消息队列再合适不过了。他们把数据推到消息队列,我们去消息队列取,完美。
可现实并不是这样,他们说系统是产品化,不支持消息队列,只能把待办任务接口开放出来。好的(微笑脸),你们是产品你们有理。可能有待办任务的用户不多,300多个,那就每隔 10 分钟请求 300 多次请求呗。也没用多线程,就是简单的循环 300 多次请求,每次耗时差不多的1分钟。
也可以,那就这样呗。
顺便说一下,这个服务的 JDK 是 1.6 版本,据说由于历史原因,现在已经不敢升级了。而且,服务要部署在 windows 上。(你说神奇不神奇)
那就这样呗,做个定时任务,10分钟咔咔请求个 300 来次,也挺过瘾,也挺省心。
但是好景不长,天不遂人愿,服务器不遂程序员愿。
以下是同事的经历,我转述以下。
就在定时任务跑起来后的第二个晚上,那本来该是一个平常的晚上,可是告警邮件扰人清梦。一看日志,内存使用空间过高,撑爆了,导致机器自动重启了。windows 就这点好啊,还会自动重启(尴尬脸)。然后手动上去把服务启动起来,解决。
隔了一天,还是晚上,又报警了,服务器又自动重启了,又是内存使用空间过高。又手动上去把服务启动了。
于是他反馈给这个服务的开发人员,结果得到的回复是:“我们的服务没有问题,肯定是你们的调用有问题,你们把定时任务停掉肯定就好了,所以是你们的问题”。
于是,他过来找我,跟我说明情况,问我可能会是什么问题。
我:你确定定时服务是 10 分钟一次,没有出现死循环吗?
同事:确定。
我:那他们的服务有使用 redis 之类的外部缓存吗?
同事:不知道。
我:。。。 既然你确定你调用的没问题,那肯定是他们程序出现问题把内存撑爆了呀,这有什么好怀疑的,让他们改吧。
同事:他们现在说自己没问题啊。
好吧,既然他们说没问题,那我就来帮他把问题找出来吧。于是,远程进了那台 windows 服务器。
这时候已经把定时任务已经跑了两天了,16G 的内存已经用掉 15G 多了,眼看随时有可能崩溃,然后把定时任务停掉,内存使用量也并不会下来。
我开始怀疑是不是用了 redis 之类的外部缓存,结果进服务器一查 redis 、memcached 之类的压根儿就没装,所以排除外部缓存。( 随后使用 JVM 工具查看也证明了这一点 )
那既然不是外部缓存,那肯定出在 JVM 上了,要不然就是用了 JVM 缓存,要不然就是内存泄漏什么的。于是我想用 jinfo -flags
看一下 JVM 初始参数,JDK 6 竟然还不支持 -flags 。
然后我不知道是不是尝试了 jmap -heap
还是就看了一眼 jmap -help
以为不支持 jamp -heap,反正最后我是通过 jconsole
来观察的 JVM。一看 JVM 参数明显就是默认没特殊设置过,并且奇怪的是对内存一共采用了 700 多M。700M 和 15G 比,差哪儿去了,没道理啊,问题没出在堆上。
然后我尝试执行 GC 操作,然而并没有任何改善。直到这里,我严重怀疑是出现了内存泄漏了。
于是我执行了 jmap -dump
,把堆、线程信息 dump 下来,然后拉到本地分析。不看不知道,一看吓一跳,线程多到令人窒息。
不得不说,有一点他们做的非常好,竟然贴心的给线程编了号,没错,就是有这么多线程 10万多个。于是我们算了一下假设 10分钟请求 300 次,那就是 300 个线程,一小时就是 30 x 6=1800,一天24小时就是1800 x 24=43200,两天多的时间 10万多个线程那就正好对上了,好牛x的样子。
一个线程默认占用空间大小 1M,10万多个线程那就是 10个多G,加上堆内存占用和机器上其他服务的内存占用,内存飙到 15G 就对的上了。
有问题就找问题就这么难吗,不承认自己的程序有问题是怎么想的呢。
好啊,你们自己不查,我帮你找到问题原因了,满意了吧。
于是,同事理直气壮的把上面那张截图发给他们,但是没有额外说一句话。
下午,微信群里对方发来消息,问题已修改,可以再试试。
然后,好多天过去了,问题没有再出现。
有的同学问了,系统能创建10万多个线程吗,有可能的。这篇文章是「你假笨」大神写的 Linux 系统下能创建多少个线程的源码分析 club.perfma.com/article/244… ,有兴趣可以上去看一看。
这个问题产生的原因就是线程创建了但是没有销毁,估计是销毁逻辑写的有些问题吧。
抛开逻辑错误不说,使用线程的正确做法是使用线程池,以免带来不必要的性能损耗和这种未加控制、未及时销毁带来的线程无止境创建的问题。
我是风筝,公众号「古时的风筝」,一个在程序圈混迹多年,主业 Java,另外 Python、React 也玩儿的很 6 的斜杠开发者。可以在公众号中加我好友,进群里小伙伴交流学习,好多大厂的同学也在群内呦。