Java 进程占用内存过多，幕后元凶原来是线程太多

2020-01-15 09:27:38来源：博客园阅读 ()

Java 进程占用内存过多，幕后元凶原来是线程太多

那天中午吃饭，一个同事说，那个项目组的人快气死我了，程序有问题，早晨在群里@了他们，到中午才回消息，然后竟然还说他们的程序没有问题，是我们这边调用的太频繁了。

简直想笑。

背景说明

我们当前这个系统和很多的第三方系统做了集成，出问题的就是其中一个三方系统。其实很简单，他们的系统会产生一些个人待办任务，然后待办任务的个数需要推送到我们的 APP 上，作为图标的角标显示。

用户数据已经打通，其实很简单的需求，角标通知也不要求实时，10分钟刷一次就可以。这个场景非常典型，用消息队列再合适不过了。他们把数据推到消息队列，我们去消息队列取，完美。

可现实并不是这样，他们说系统是产品化，不支持消息队列，只能把待办任务接口开放出来。好的(微笑脸)，你们是产品你们有理。可能有待办任务的用户不多，300多个，那就每隔 10 分钟请求 300 多次请求呗。也没用多线程，就是简单的循环 300 多次请求，每次耗时差不多的1分钟。

也可以，那就这样呗。

顺便说一下，这个服务的 JDK 是 1.6 版本，据说由于历史原因，现在已经不敢升级了。而且，服务要部署在 windows 上。(你说神奇不神奇)

花明柳暗

那就这样呗，做个定时任务，10分钟咔咔请求个 300 来次，也挺过瘾，也挺省心。

但是好景不长，天不遂人愿，服务器不遂程序员愿。

以下是同事的经历，我转述以下。

就在定时任务跑起来后的第二个晚上，那本来该是一个平常的晚上，可是告警邮件扰人清梦。一看日志，内存使用空间过高，撑爆了，导致机器自动重启了。windows 就这点好啊，还会自动重启(尴尬脸)。然后手动上去把服务启动起来，解决。

隔了一天，还是晚上，又报警了，服务器又自动重启了，又是内存使用空间过高。又手动上去把服务启动了。

于是他反馈给这个服务的开发人员，结果得到的回复是：“我们的服务没有问题，肯定是你们的调用有问题，你们把定时任务停掉肯定就好了，所以是你们的问题”。

于是，他过来找我，跟我说明情况，问我可能会是什么问题。

我：你确定定时服务是 10 分钟一次，没有出现死循环吗？

同事：确定。

我：那他们的服务有使用 redis 之类的外部缓存吗？

同事：不知道。

我：。。。既然你确定你调用的没问题，那肯定是他们程序出现问题把内存撑爆了呀，这有什么好怀疑的，让他们改吧。

同事：他们现在说自己没问题啊。

挖出真凶

好吧，既然他们说没问题，那我就来帮他把问题找出来吧。于是，远程进了那台 windows 服务器。

这时候已经把定时任务已经跑了两天了，16G 的内存已经用掉 15G 多了，眼看随时有可能崩溃，然后把定时任务停掉，内存使用量也并不会下来。

我开始怀疑是不是用了 redis 之类的外部缓存，结果进服务器一查 redis 、memcached 之类的压根儿就没装，所以基本排除外部缓存。

并且登录上去之后查看进程内存占用，确实就是一个 Java 进程占了这么多内存。

那既然不是外部缓存，那肯定出在 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 就对的上了。