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

一个Java应用因为与第三方系统集成,频繁调用待办任务接口,导致10分钟后内存使用过高,引发服务器重启。经过排查发现,对方程序未使用线程池,每个待办任务创建一个新线程,累计达到10万个,造成内存泄露。通过dump线程信息,找出问题并建议对方使用线程池以避免此类问题。
摘要由CSDN通过智能技术生成

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

简直想笑。

背景说明

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

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

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

也可以,那就这样呗。

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

花明柳暗

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值