这个确实形成了死循环。但这没有逻辑问题。从要求上讲，A要求定时执行，既然超时了（每次返回到链表头检查时），当然要执行罗。。。

只能说redis不适合这种场景。redis适合于IO密集型，不适合计算密集型。问题中由于A、又有B，导致B处理完A就超时了，典型的计算密集型，CPU根本就没有空出来啊~ 网络操作是IO密集型，redis才有用武之地。另一方面，记得redis整个源码中也只添加了serverCron一个定时器，而且这个函数的执行应该需要严格控制，比如那个redis中的db数就不应太多，so其实那个定时器链表其实没什么用，也难怪查找时作者说没有优化的必要了。。。

想起了之前别人问过我的一个问题，也是关于这个time链表。这个链表是无序的，如果链表上有大量的超时time，按照这个顺序处理逻辑就可能不对了。因为按理说至少要排个序嘛，超时也得有个先后。。。当时很囧，没有代码在手边，没回答上这样做在redis中会不会存在问题。道理其实很简单，因为redis中暂时就一个time嘛。。。当然，如果要迁移这个框架为你所用，是需要改改的。。。比如可以用跳表、堆什么的优化一下。。。。

那么首先执行A，A执行完后，设置下次超时时间，然后从A开始执行，此时A还没超时跳过执行，执行B，B执行完后又从头开始执行，此时A已经超时，执行A，这时不是死循环了吗