再不解决延迟不当,小心你的内存被打爆

Posted 华为云

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了再不解决延迟不当,小心你的内存被打爆相关的知识,希望对你有一定的参考价值。

摘要:这是在具体代码中发现的不当延迟的问题,极端情况下可能把内存打爆。

本文分享自华为云社区《线程中不当使用延迟问题》,原文作者:技术火炬手 。

背景

这是在具体代码中发现的不当延迟的问题,极端情况下可能把内存打爆。

代码DevLicenseServiceRoaDelegateImpl.java

定义:

image002.jpg

使用:

image004.jpg

signalRefreshHelp 定义

image006.jpg

这段代码最大问题是使用延迟算法不当,在极端情况下会导致内存暴涨,严重影响服务程序的性能。

不要使用sleep来实现延迟

使用sleep实现延迟看起来非常直观,但是这个在高并发、多请求、长期运行的服务程序里必须特别小心。这是因为衡量服务程序性能的一个非常重要的指标是QPS, 就是服务程序的处理能力,一般情况下越大越好;服务程序的总并发能力等于每个线程的qps;单个线程的QPS = 1000毫秒 / (处理一个请求的毫秒);所以上面那个线程的QPS <= 1000 / 10000 = 0.1 (因为线程sleep了10000毫秒)。

这里的处理逻辑是错误的!也有很严重的性能隐患,不过幸好调用这个api 请求不多,才没有导致严重问题。

开发者的意图是在创建一个任务后,延迟10s执行该任务,处理时序图如下

image008.jpg

假如时间点t1 & t2 挨得很接近的话,线程在执行job1 & job2 也是很接近。

但实际的情况变成:

image010.jpg

就算创建job1 & job2的时间很接近,但job2执行的时间会比预期多了10s;连续提交的任务越多,越容易堆积,这些堆积的任务存放在 blocking queue,一直到处理完毕才删除;如果这类请求很多的话,很容易引起内存爆掉。

解决方案

选择合适的数据结构,默认线程池关联的队列是LinkedBlockingQueue , 没有延迟控制,可以使用DelayQueue

image012.jpg

DelayQueue内部使用了PriorityQueue 按时间排序;需要自己使用Delayed 接口封装请求数据

下面是例子

image014.jpg

测试代码,同时加入 3个需要延迟10s的任务

image016.jpg

测试结果:

image018.jpg

符合预期

 

点击关注,第一时间了解华为云新鲜技术~

以上是关于再不解决延迟不当,小心你的内存被打爆的主要内容,如果未能解决你的问题,请参考以下文章

#yyds干货盘点# 如何保障你的 Kubernetes 集群资源不会被打爆(18)

ubuntu18.04ssh输入延时

mysql 主从复制延迟及解决

怎样解决MySQL数据库主从复制延迟的问题?

动态规划专题6:打气球的最大分数

怎么样才能让一个人的手机被打爆