起源于Thread.sleep最近在系统调优的过程中遇到一个有趣的CPU消耗高的问题（当时CPU占用已经达到90%左右），先来看看上图。没错，就是Thread.sleep这个方法，大概消耗了34%的CPU，而且还停留了很长时间。其实我第一眼看到这个东西的时候也是傻眼了，这什么鬼。我在心里骂了xxx次开发。这个纳米是没有大脑用来发展睡眠的纳秒。事实证明我错了（其实是因为我平时代码比较少，对生菜不是很熟悉，因为当时对生菜不是很熟悉。知道是生菜造成的），抱歉感谢我们辛勤工作的开发者RuiSibai。开始寻找“BUG”OK，言归正传，问题还是要仔细分析。终于在threaddump找到了突破口，找到了这个跟帖：然后通过这个跟帖找到了今天的主角，请生菜出道。至此，我知道是lettuce的错，但是我对lettuce不熟，还是老老实实复习英语。lettuce官方文档（https://lettuce.io/core/5.3.7...）在官方文档中找到了这个：默认开启lettuce的延迟监控功能。在内存转储中，还可以看到相关属性为true：简单介绍延迟跟踪功能，详见官方文档：依赖LatencyUtils模块统计第一次响应的执行次数延迟(min,max,percentiles)delayofcommandexecution(min,max,percentiles)命令延迟统计可以是1.按主机和端口或套接字路径区分（不区分命令），2.按命令类型跟踪延迟监控（GET,SET,...)可以通过配置关闭，官方文档中有说明例子如下：RedisClientclient=RedisClient.create(res);这里基本可以给出优化建议：非必要情况，直接关闭该功能。除了这个方法，我暂时想不出其他的解决办法。根据前面的描述，Time.sleep()是在LatencyUtils模块下调用的。为了满足我的好奇心，我直接查看了LatencyUtils相关的源码。源码地址：https://github.com/LatencyUti...可以看到默认休眠时间是1毫秒。为什么线程休眠会消耗CPU？让我在这里解释一下。其实挂起的线程不是消耗CPU资源，而是消耗资源。最频繁的醒来和睡眠。睡眠会导致线程上下文切换和额外的系统消耗，类似于LockSupport.park()。下面是sleep的demo（园友可以玩一整），感受一下散热风扇的轰鸣声（线程越多CPU消耗越大）：publicclassHighCPU{publicstaticvoidmain(String[]args){intthreadCount=100;finalList
