服务实例（Service Instance）生命周期如何控制

服务调用的目的体现在对某项服务功能的消费上，而功能的实现又定义在相应的服务类型中。不论WCF服务端框架处理服务调用请求的流程有多么复杂，最 终都落实在服务实例的激活和操作方法的执行上面。WCF中的实例管理（Instance Management）旨在解决服务实例的激活和服务实例生命周期的控制。

会话（Session）的目的在于保持来自相同客户端（服务 代理）多次服务调用之间的状态。从消息交换的角度来讲，会话通过消息识别机制判断调用某个服务的消息来源，从而将来自相同客户端的所有消息关联在一起。所 以，会话实现了消息关联（Message Correlation）。

实例与会话是WCF非常重要的两个特性，它们既相对独立，又互相 制约。实例模式与对会话支持程度的不同组合，会让最终的服务表现出截然不同的行为。对实例管理和会话的合理利用，对于改善和提高WCF服务应用的可扩展性 （Scalability）、性能（Performance）、吞吐量（Throughput）等具有决定性作用。服务实例对象并不是孤立存在的，而是被 封装到一个特殊实例上下文（InstanceContext）对象之中，本系列文章从实例上下文说起。

一、 实例上下文（InstanceContext）

实例上下文是对服务实例的封装，是WCF管理服务实例 生命周期的依托。我们先撇开WCF，来简单介绍一下在托管的环境中，公共语言运行时（CLR）是如何进行托管对象的生命周期的。在一个托管应用程序中，我 们通过不同的方式创建一个托管对象（比如通过new关键字、反射或反序列化等）时，CLR会在托管堆为该对象开辟一块内存空间。对象的本质就是存储于某块 内存中数据的体现，对象的生命周期终止于相应内存被回收之时。对于CLR来说，负责对托管堆（在这里主要指GC堆）进行回收的组件是垃圾收集器 （GC），GC掌握着托管对象的生杀大权，决定着托管对象的生命周期。

当GC在进行垃圾回收的时候，会将“无用”的对象标记为垃圾对 象，然后再对垃圾对象进行清理。GC对“无用”对象的识别机制很简单：判断对象是否被“根（Root）”所引用。在这里，“根”是对一组当前正被使用，或 者以后可能被使用的对象的统称，大体包括这样的对象：类型的静态字段或当前的方法参数和局部变量、CPU寄存器等。

所以，孤立存在的对 象将难逃被GC回收的厄运。反之，如果希望某个对象常驻内存中，我们唯一的方式就是通过某个“根”引用该对象。本章所讲的实例管理，就是对服务实例生命周 期的管理，即让服务实例按照我们希望的方式创建、存活和消亡，所以我们唯一的方式也只能是：在希望服务实例存活的时候让它被某个“根”引用，从而阻止GC 将其回收；在希望服务实例被回收的时候连“根”去除，使GC能够将其回收。而本节所讲的实例上下文（InstanceContext）就扮演着“根”的角 色。

说到实例上下文，相信读者不会感到陌生，因为在进行WCF双向（Duplex）通信的时候，我们通过实例上下文来封装回调对象。在 WCF中，实例上下文不仅仅用于对回调对象的封装，也用于对真正服务实例的封装。实际上可以将WCF的双向通信理解成一种对等通信，通信的双方是对等的参 与者，并没有严格的服务端和客户端之分，或者说通信的双方交替地扮演着服务与客户的角色。客户端正常调用服务端操作是一种服务调用；服务端回调客户端操作 也可以看成是一种服务调用。因此，通过实例上下文对回调对象和服务实例进行封装本质上是一致的。

实例上下文对服务实例的封装大体可以通 过图1 表示。一个WCF服务通过一个ServiceHost进行寄宿，并添加一到多个终结点。对于接收到的服务调用请 求，如果相应的实例上下文存在，则通过它得到服务实例来处理服务请求，否则创建服务实例并通过实例上下文对其进行封装，然后再通过实例上下文得到具体的服 务实例进行服务请求处理。

图 1 实例上下文对服务实例的封装

实例上下文通过类型 System.ServiceModel.InstanceContext表示。InstanceContext继承自 CommunicationObject，实现了IExtensibleObject<InstanceContext>接口。 InstanceContext的定义如下面的代码所示：