1.缘起：
有些系统需要每隔一段时间就执行一下某个动作，比如，一个监控系统每隔10秒钟就要检测一下被监控对象的状态是否正常，那这时我们就可以用到循环引擎了。
有人说可以使用.NET框架自带定时器如System.Threading.Timer，嗯，没错。但是若这个类使用不当可能会引发后台池线程耗尽的后果。因为Timer的定时事件触发实在后台线程池中的某个线程中处理的。也就是说Timer的每次定时事件触发都会用到一个线程，如果定时的时间间隔小于事件处理的时间，则后台线程池中将会有越来越多的线程被Timer使用掉，直至线程池中再无空闲的线程。
而ESBasic.Threading.Engines.ICycleEngine的设计目标是永远都只使用一个线程。比如，它会隔10秒执行一个Action，执行完后再隔10秒再执行Action。间隔时间的等待与Action的执行都是在同一个线程中处理的。
循环引擎的形象示意图如下：
2.适用场合：
根据上面的描述你应该已经看到了ICycleEngine与Timer之间的区别。由于Action的执行会占用额外的时间，所以ICycleEngine不适合于精确定时的任务。比如上面的例子，下一个Action开始的时刻与上一个Action开始的时刻的真正的时间差可能是12秒，而不是10秒，因为上一个Action的执行花费了2秒。
所以，如果你的系统不需要精确的定时任务，而且又不想花费过多的精力去防范使用Timer时线程耗尽的窘境出现，那么ICycleEngine将是个不错的选择。
3．设计思想与实现
ICycleEngine接口的源码如下：
/// <summary>
/// ICycleEngine 在后台线程中进行间隔循环的引擎
/// zhuweisky 2006.12.21
/// </summary>
public interface ICycleEngine
{
/// <summary>
/// Start 启动后台引擎线程
/// </summary>
void Start();
/// <summary>
/// Stop 停止后台引擎线程，只有当线程安全退出后，该方法才返回
/// </summary>
void Stop();
/// <summary>
/// IsRunning 引擎是否运行中
/// </summary>
bool IsRunning { get; }
/// <summary>
/// DetectSpanInSecs 引擎进行轮询的间隔，DetectSpanInSecs=0，表示无间隙运作引擎；DetectSpanInSecs小于0则表示不使用引擎
/// </summary>
int DetectSpanInSecs { get;set; }
/// <summary>
/// OnEngineStopped 当引擎由运行变为停止状态时，将触发此事件。如果是异常停止，则事件参数为异常对象，否则，事件参数为null。
/// </summary>
event CbException OnEngineStopped;
}
如何实现这个接口了？
由于不同的系统要求执行的Action不一样，所以，我们可以实现一个abstract基类BaseCycleEngine来保证循环引擎的正常运转，而派生类只要override基类的abstract方法DoDetect来执行自己的Action。
关于BaseCycleEngine的实现要注意以下几点：
（1）循环引擎是在后台线程池的某个线程上运行的。
（2）循环引擎可以无限次的启动、停止、启动、停止……
（3）为了保证调用Stop方法时能迅速地停止引擎，我将间隔时间划分为多个BaseCycleEngine.SleepTime。而不是一次性地Sleep间隔时间。
（4）为了保证循环引擎真正停止后，才返回Stop方法的调用，我使用了ManualResetEvent来进行控制。
（5）DoDetect方法的返回值为false，则表示在该Action执行完后将停止循环引擎。此后，可以重新调用Start方法再次启动循环引擎。
4. 使用时的注意事项
（1） 要确保我们的Action（即派生类的DoDetect方法）不任何抛出异常，否则会导致循环引擎异常停止，并导致循环引擎的内部状态损坏而不可用。所以在派生类的DoDetect方法方法实现时捕捉所有的异常并加以处理。
（2） 在DoDetect方法实现中不能调用Stop方法，否则会导致死锁出现。
（3） 如果将DetectSpanInSecs设为0，则表示无间隙的执行DoDetect方法。而如果将DetectSpanInSecs设为负数，则表示不启动循环引擎。
（4） 当引擎已经启动并正在运行的过程中，如果要改变DetectSpanInSecs的值并使其生效，则必须重新启动（先调用Stop方法再调用Start方法）引擎才可。
5.扩展
（1）AgileCycleEngine
在上面的介绍中，我们都是以DoDetect方法来表示要执行的Action，而且我们必须以继承BaseCycleEngine的方式来使用循环引擎，这无疑限制了循环引擎的使用。
AgileCycleEngine的存在便是为了突破这个限制。
public sealed class AgileCycleEngine :BaseCycleEngine
{
private IEngineActor engineActor;
public AgileCycleEngine(IEngineActor _engineActor)
{
this.engineActor = _engineActor;
}
protected override bool DoDetect()
{
return this.engineActor.EngineAction();
}
}
AgileCycleEngine继承自BaseCycleEngine，但是它是非abstract的。AgileCycleEngine通过组合而非继承的方式来使用循环引擎，我们可以将Action的执行者抽象为一个接口IEngineActor。
public interface IEngineActor
{
/// <summary>
/// EngineAction 执行引擎动作，返回false表示停止引擎。
/// 注意，该方法不能抛出异常，否则会导致引擎停止运行（循环线程遭遇异常退出）。
/// </summary>
bool EngineAction() ;
}
通过实现IEngineActor来表明我们要执行的Action，然后将其注入到AgileCycleEngine中。
（2）永不停止的循环引擎
我们再考虑一个扩展的情况，假设我们的系统要求在启动时就将引擎运行起来，而且在整个运行的生命周期中，都不需要停止引擎，那么我们可能不想将Start方法、Stop方法暴露出来以免意外的调用Stop方法而导致引擎停止运行，那这个时候我们可以使用类似下面的技巧来做到：
public sealed class MyCircleEngine : IEngineActor
{
private AgileCycleEngine agileCycleEngine;
public void Initialize()
{
this.agileCycleEngine = new AgileCycleEngine(this);
this.agileCycleEngine.DetectSpanInSecs = 10;
this.agileCycleEngine.Start();
}
#region IEngineActor 成员
public bool EngineAction()
{
// My Action
return true;
}
#endregion
}
用于示例的MyCycleEngine内部使用了AgileCycleEngine，但它没有暴露循环引擎的任何控制方法，而且Initialize方法表明MyCycleEngine只要一初始化便开始运行，而且没有办法让其停止运行。MyCycleEngine实现了IEngineActor接口，并把自己注入到AgileCycleEngine类型的成员中，于是引擎将每隔10秒钟执行一次MyCycleEngine的EngineAction方法。
注： ESBasic已经开源，点击这里下载源码。
ESBasic开源前言