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

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

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

背景

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

代码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的任务

测试结果：

符合预期

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