卡列宁的微笑

IO调度的本质上把多个阻塞集中为一个阻塞，在这一个阻塞上获取事件，发 生“中断”，挂起或者恢复（调度）原先那些本应该阻塞的控制流。在一个 控制流上并发地生产多个超时事件的东东就叫做定时器。

大体上，定时器是一个线程，接受注册超时事件，在任何一个超时事件的条件 满足时发出事件。基本的思路是用一个并发数据结构维护注册的事件，睡一段 时间醒来去看一下这个数据结构，收集满足条件的事件，根据应用上的要求， 做特定的事情（也就是发出事件）。

这里面就有两个选择，第一：选择何种数据结构，第二，怎么睡，睡多久。

关于第一个问题，使用最小堆或者优先队列应该是比较直观的想法。如果假 设比较后来进入的超时请求，应该概率上比先进入的超时请求更加迟到达， 这大部分应该是成立的，优先队列应该效率不错，但这需要评测，这两种数 据结构在一般的假设下都是合理的选择。

第二个问题，关于睡多久，自然是堆或者是队列首元素距离当前的时间，显 然，每次只要睡这么久就绝对不会错过。但是有一个问题就是当有事件注册 进来的时候，它到达的时间可能比当前堆或者队列的首元素的时间还要早， 也就是说注册之后它就是首元素了，那么这时候就要唤醒定时器，通知他更 新自己的睡眠时间。所以我们就用了一个poll做定时器，在poll上监控了一 个socket pair，用来唤醒定时器。

应用上的超时比较好说，当然是应用要怎么超时就怎么超时。比方说超时30s 接收回复，那当然就是发出30s的超时请求。

麻烦的问题是如何进行连接超时，对连接超时的意思是说，如果连接长期空 闲，我们要把他关闭掉，或者另一种情况，我们是作为客户端，那就要向服 务端进行心跳，否则人家就把我们超时了。这里只谈服务端的情况，要判断 一个连接是不是超时，那就要维护它上面最后的读写操作发生的时间，也就 是说要有时间戳，另外，要间隔一定的时间去检查它是不是超时。

这里面主要的技巧，第一是时间戳缓存，我们还是用定时器去产生时间戳，对 定时器会有一个心跳间隔，也就是照前面的设计，不过他总是睡眠这个心跳间 隔和首元素之间较小的一个时间，每次醒来去更新一下时间戳。而在对连接 进行操作时候更新时间戳，就用定时器缓存的这个。另外，就是分代进行超 时，也就是说，不是针对每个连接，都发出一个超时请求，而是对相近的比 方一百个连接（或者最近1s产生的连接），用同一个超时请求去做超时。