摘要：这是在具体代码中发现的不当延迟的问题，极端情况下可能把内存打爆。
本文分享自华为云社区 《线程中不当使用延迟问题》 ，原文作者：技术火炬手 。
背景
这是在具体代码中发现的不当延迟的问题，极端情况下可能把内存打爆。
代码 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 的任务
测试结果：
符合预期
