再不解决延迟不当,小心你的内存被打爆
摘要:这是在具体代码中发现的不当延迟的问题,极端情况下可能把内存打爆。
本文分享自华为云社区《线程中不当使用延迟问题》,原文作者:技术火炬手 。
背景
这是在具体代码中发现的不当延迟的问题,极端情况下可能把内存打爆。
代码DevLicenseServiceRoaDelegateImpl.java
定义:
使用:
signalRefreshHelp 定义
这段代码最大问题是使用延迟算法不当,在极端情况下会导致内存暴涨,严重影响服务程序的性能。
不要使用sleep来实现延迟
使用sleep实现延迟看起来非常直观,但是这个在高并发、多请求、长期运行的服务程序里必须特别小心。这是因为衡量服务程序性能的一个非常重要的指标是QPS, 就是服务程序的处理能力,一般情况下越大越好;服务程序的总并发能力等于每个线程的qps;单个线程的QPS = 1000毫秒 / (处理一个请求的毫秒);所以上面那个线程的QPS <= 1000 / 10000 = 0.1 (因为线程sleep了10000毫秒)。
这里的处理逻辑是错误的!也有很严重的性能隐患,不过幸好调用这个api 请求不多,才没有导致严重问题。
开发者的意图是在创建一个任务后,延迟10s执行该任务,处理时序图如下
假如时间点t1 & t2 挨得很接近的话,线程在执行job1 & job2 也是很接近。
但实际的情况变成:
就算创建job1 & job2的时间很接近,但job2执行的时间会比预期多了10s;连续提交的任务越多,越容易堆积,这些堆积的任务存放在 blocking queue,一直到处理完毕才删除;如果这类请求很多的话,很容易引起内存爆掉。
解决方案
选择合适的数据结构,默认线程池关联的队列是LinkedBlockingQueue , 没有延迟控制,可以使用DelayQueue
DelayQueue内部使用了PriorityQueue 按时间排序;需要自己使用Delayed 接口封装请求数据
下面是例子
测试代码,同时加入 3个需要延迟10s的任务
测试结果:
符合预期
相关文章
- 摸鱼搞了个掘金数据监控桌面应用,还不快用起来!
- 这个实现不对,要的是excel里面的高亮重复项效果
- 精选Github计算机开源视觉项目
- 腾讯云大数据流计算 Oceanus 在 MySQL CDC Connector 的核心优化
- 网宿科技携手亚马逊云科技,助力云计算成为真正的生产力
- 【FAQ】分析服务导出的事件数据和概览页面展示的数据不一致该如何解决?
- 金融App面临安全风险?解锁HMS Core安全检测服务解决方案
- CodeArts TestPlan:一站式测试管理平台
- cookie、session,、token,还在傻傻分不清?
- 一文了解华为FusionInsight MRS HBase的集群隔离方案RSGroup
- 高并发环境下构建缓存服务,你需要注意这6点
- 一文详解RocketMQ的存储模型
- Serverless时代的微服务开发指南:华为云提出七大实践新标准
- 用100W+行代码贡献经验,带你了解如何参与OpenHarmony开源
- CSV:简单格式下隐藏的那些坑
- 能将三次握手讲到这个程度,不给你offer给谁!
- 细数华为云云原生产品及五大开源实践
- 解密秒杀系统架构:不是所有的秒杀都是秒杀
- 《迷你世界》亿级玩家都在用的游戏场景推荐系统长啥样?
- ROMA Connect: 5大联接能力+4大集成能力,推进企业数字化转型