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