Pooled Service Model in HiveMind

    基于池的服务模型和与线程绑定的服务模型是非常象的。一个服务的实例会和一个特定的线程绑定，直到这个线程消亡（或者只是清空数据）。和与线程绑定模式不同的是，服务实例并不会被抛弃，会重新放入池中供之后的请求使用并与新的线程绑定。
    和与线程绑定的模型一样，所有的绑定与取消绑定都是由自动生成的代理类完成的，用户代码不需要涉及这些。
    核心服务实例可以实现RegistryShutdownListener接口，接收最后清空的回调消息（像单例的服务模型一样）。
    另外，一个服务可以实现PoolManageable接口，接受基于池的服务特有的回调函数。服务会在它被激活（绑定到一个线程）和挂起（取消绑定并返回到池中）时收到消息。
    基于池的服务模型和与线程绑定的服务模型生成的代理类结构上基本是一样的，外层代理会调用内层代理，内层代理再去获取合适的服务实例（在有拦截器的时候外层代理首先调用拦截器，拦截器再调用内层代理）。自动生成的代理类代码可以参考与线程绑定的模型（Threaded Service Model）。它的内外层代理和拦截器对所有线程也是共享的，变化的只是服务的实例。
    为了完成使用池管理服务的目的，基于池的服务模式比与线程绑定的服务模型多了一个用于保存挂起状态服务的List,和用于包装服务实例的PooledService类。此时，绑定到线程的或者缓存在池中的就不是服务的实例了，而是一个PooledService对象。这个对象会接受线程清空的消息，必要时使自身回到池中。

    上图展示了PooledServiceModel用到的主要类，其中PooledServiceModel是用于管理服务是的生成和生存周期的。每个服务的扩展点都会有一个相对应的Model，基于池的模型用的就是这个PooledServiceModel。PooledService是PooledServiceModel的一个内部类。UserService是一个虚设的接口，根据每个不同的服务不同。

    上图展示了当一个服务接口中的方法被调用时proxy是如何完成将最终请求传递到服务实例中去的。上图中省略掉了拦截器，如果有服务配置了拦截器只是在OuterProxy和InnerProxy之间插入一层，不影响整个结构。
    从上图还可以看到，每当一个PooledService绑定到一个线程的时候都会注册一个Thread Cleanup的事件。那么在线程清空的时候就会触发这个事件，通知PooledService返回池中供以后使用。