设计模式- 主动对象（Active Object）

译者注：
1.对象分为主动对象和被动对象，主动对象内部包含一个线程，能够自动完成动做或改变状态，而通常的被动对象只能经过被其余对象调用才有所做为。在多线程程序中，常常把一个线程封装到主动对象里面。
2.在翻译过程当中，发现的原文不妥处被更正。
3.原文中许多内容一再重复，很有蛇足之感，取精用宏，删繁就简。
4.尝试更高程度的意译。

关键词
这个文章介绍主动对象模式，主动对象是内部拥有本身的控制线程的对象。为了简化异步调用的复杂性，这个模式分离了方法的执行和调用。使用这个模式，一个对象中不管是否有独立的线程，客户从外部访问它时，感受是同样的。生产者/消费者，读者/写者，这两个应用普遍的模型中，这种策略很是适合。这个模式经常使用在多线程的，分布式系统中。另外，一些客户端应用，如：视窗系统和网络浏览器，也可使用主动对象模式，对并行的、异步调起的IO操做简化处理。

1  目的

主动对象模式隔离了方法执行和方法调用的过程，提升了并行性，对内部拥有控制线程的主动对象，下降了异步访问的复杂性。

2  别名

并行行为对象（ConcurrentObjectandActor）

3  例子

为了说明主动对象模式，考虑一个通讯网关的设计。网关隔离互相协做的多个组成单元，让交互过程不直接依赖于对方。参照图1，一个分布式系统中，来自多个生产者（卫星设备）的消息，被网管转发给多个消费者（局域网内的主机）。

咱们的例子中，生产者和消费者使用TCP协议通讯，这是面向链接的通讯协议。网关上的进程向消费者发送数据时，操做会发生阻塞。这是由于，网络传输能力有限，TCP进行流量控制，防止过量的数据不能及时缓冲和处理。

要提升总体的效率，网关处理进程不能因一个链接上的阻塞而等待。另外，当生产者和消费者的数目增长的时候，整个进程必须相应的增长处理能力（译者注：经过增长处理线程）。

一个提升性能的有效方法，就是使用并行。应用并行后，服务对象拥有独立线程，线程实际完成操做，和方法调用的过程分开。而且，不一样线程处理不一样TCP链接，一个链接上的线程被阻塞，不会影响到其余链接的线程。

4  场景

对象的访问者（Client，下统称为客户）和对象的实如今不一样的线程中。

5  问题

许多应用场景，服务者并行处理多客户端的请求，提升服务的质量（QoS）。被动对象在客户线程中完成操做过程，主动对象使用专用的线程完成。一个对象的数据被多个线程共享时，必须处理好线程的同步。这致使三个约束。

1.对一个对象调用不能阻塞整个进程，不能影响其余线程的执行：好比，通讯网关的例子中，一个TCP链接上的数据传送被阻塞，整个进程仍然能继续处理。一样，其余没有被阻塞的网络链接，应该正常的发送数据。

2.对共享对象同步访问的逻辑应该简化：客户在使用共享对象地时候，若是面对底层的同步机制，必须记得先要获取互斥锁，后要释放互斥锁，编码就比较麻烦。通常状况，共享对象的方法隐藏这些细节，当多个客户线程访问同一个对象时，这些约束是透明的。

3.存在能够平行进行的操做，设计成同时执行：在通讯网关的例子中，同时使用多个TCP链接给不一样的消费者发送数据。若是网关的进程在单个线程上执行，及时使用多个处理器不能明显的提升性能。

6  方案

对每个要求并发执行的对象，分离其方法的调用和执行。这样，这个对象的客户就像是调用一个常规的方法同样。这个方法，自动把任务交给另外的线程完成执行。

主动对象的组成：一个代理者（Proxy）实现外部的访问接口；一个执行者（Servant）。代理和执行者在不一样的线程执行，分离方法调用和执行的过程：代理者在客户线程中被调用执行，执行者在另外的线程完成操做。运行时，代理者把客户的调用信息封装“调用请求”（MethodRequest），经过调度者（Scheduler）把这个请求放到一个活动队列（ActivationQueue）。调度者和执行者运行在另外的线程中，这个线程启动后，不断地从活动队列中获得“调用请求”对象，派发给执行者完成客户请求的操做。客户调用代理者后立刻获得一个预定容器（Future），从此能够经过这个预定容器获得返回的结果。

7  结构

下面使用Booch风格的类图，对主动对象的组成结构进行说明。（译者注：这是Booch在《面向对象的分析和设计》书中使用的类图风格）

在这个模式中，共有六个参与者。

代理者（Proxy）
代理者定义了被客户调用的接口。这个接口是函数调用的方式，而不是像传统线程通讯，使用数据传递的方式。当函数被调用的，代理者构造一个“调用请求”对象，并把它放到活动队列中，这一切都发生在客户线程中。

调用请求（MethodRequest）
“调用请求”用来保存相关函数调用的部上下文信息，好比函数标识，函数的参数，这些信息将在不一样线程间传递。一个抽象的“调用请求”类，定义了执行活动对象方法的接口Call。而且包含一个Guard函数，Guard用来检查调用的条件是否知足。对代理者提供的每个主动对象方法，在访问其执行者的时候须要条件判断。代理者被调用的时候会建立具体“调用请求”对象，对象中包含了执行这个方法必须的参数和数据的返回方式。

活动队列（ActivationQueue）
这个队列维护了一个缓冲区（译者注：不必定是先进先出的队列），缓冲区中存放了待执行的“调用请求”。正是这个队列分离可客户线程和执行操做的线程。

调度者（Scheduler）
调度者管理活动队列。调度者决定队列中的哪个调用请求先被执行。调度的决定可能决定与多个规则：关键字顺序，入队的顺序，要知足的执行条件或等待发生的事件，如：在一个数据结构中出现空闲区。调度者使用Guard方法的调用，来检查是否知足执行条件。

执行者（Servant）
真正完成操做的对象。执行者实际完成代理者定义的主动对象方法，响应一个“调用请求”。调度者给“调用请求”分派一共执行者，而后调用“调用请求”中的Call方法。对应的执行者的方法将被调用。执行者的方法运行在调度者的线程中。执行者可能同时提供了一些方法供“调用请求”实现Guard。

预定容器（Future）
当执行者完成操做，客户经过预定容器获取返回结果。当客户调用代理者的方法后，一共空预定容器立刻返回。预定容器指向一块内存空间，用来保存返回结果。客户能够经过轮训或阻塞调用的方法，经过预定容器获得返回结果。

8  运行

下面的图说明了一个调用过程当中的三个阶段。

注×：原图中“enqueue(M1)”的位置有误，入队操做应该在返回Future以前，本图已经更正。黄色表现客户线程空间，绿色表示调度者线程空间。

1.构造“调用请求”：在这个阶段，客户调用代理者的一个方法m1()。“调用请求”对象被建立，这个对象中包含了全部的参数。代理者把这个“调用请求”对象传递给调度者，调度者把它入队到活动队列。若是方法m1()有返回值，就返回一个预定容器（Future），不然不返回。

2.调度执行：调度者的执行线程中，监控活动队列，当队列中的一个请求知足执行条件时，调度者把它出队，把一个执行者绑定到这个请求上。而后经过“调用请求”的Call方法，Call再调用执行者的m1()，完成客户请求的操做。

3.完成：在这个阶段，若是有返回值，就把返回值存储到对应的预定容器中。而后调度者线程继续在活动队列中查找下一个要执行的“调用请求”。客户就能够在预定容器中找到返回值。当“调用请求”和“预定容器”不在使用的时候，注意销毁，防止内存漏洞。

9  实现

这一节说明一个主动对象模式使用的过程。这个应用是上面例子的部分实现。图2说明了各个组成部分。这节的例子，使用到了ACE框架的可重用组件。ACE提供了丰富的包装器和框架组件，用来完成软件间的通讯任务，而且ACE是跨平台的。

1.执行者的实现：咱们的例子中，执行者是个消息队列，用来缓冲发送到消费者的消息。对每个远程的消费者，对应一个ConsumerHandler，Handler中包含一个到消费者进程的TCP链接（译者注：每个主动对象要包装一个ConsumerHandler）。每个ConsumerHandler对应的活动对象缓存的消息（译者：经过活动队列缓存“请求调用“的方式缓存消息），是从生产者发给网关的，而且等待网关把它发送给对应的消费者。下面的类定义了执行者的接口。

 

class MQ_Servant {
    public:
        MQ_Servant (size_t mq_size);
        // 消息队列实现的操做
        void put_i (const Message &msg);
        Message get_i (void);
        // 状态检查
        bool empty_i (void) const;
        bool full_i (void) const;
    private:
        // 内部队列的实现，多是循环数组，链表之类
};

 

put_i和get_i实现队列的插入和删除操做。另外的两个函数，empty_i和full_i用来检查队列的状态，队列共有三种状态，（1）空，（2）满，和（3）非空非满。这两个函数将帮助实现“调用请求”的Guard（）。

注意，执行者MQ_Servant把线程同步的任务交给了外部。在咱们的例子中，MQ_Servant没有包含任何线程同步的代码。这个类仅提供了检查其内部状态的方法。这种设计避免了“Inheritance anomaly”（继承反常）问题：若是规定了同步实现，会制约MQ_Servant被重用。而这样，同步方式的改变不影响MQ_Servant的实现（译者：放下即自在）。

2.代理者和“调用请求”的实现：例子中，代理者MQ_Proxy提供了和执行者MQ_Servant同样的接口函数。另外，代理MQ_Proxy又是一个创造“调用请求”对象的工厂。下面是它的C++代码。

class MQ_Proxy {
    public:
    //  消息队列的长度
    enum { MAX_SIZE = 100 };
    MQ_Proxy (size_t size = MAX_SIZE) : scheduler_ (new MQ_Scheduler (size)),
    servant_ (new MQ_Servant (size)) {}
    // 调度<put> 在活动对象上执行
    void put (const Message &m) {
        Method_Request *method_request =
        new Put (servant_, m);
        scheduler_->enqueue (method_request);
    }
    // <Get>返回预定容器：Message_Future 
    Message_Future get (void) {
        Message_Future result;
        Method_Request *method_request =
        new Get (servant_, result);
        scheduler_->enqueue (method_request);
        return result;
    }
    // ... empty() and full() 用来检查队列状态
    protected:
    // 实际完成操做的执行者
    MQ_Servant *servant_;
    // 调度者
     MQ_Scheduler *scheduler_;
};

虚拟基类Method_Request，定义了“调用请求”的接口：

class Method_Request {
    public:
    // 检查是否准备好
    virtual bool guard (void) const = 0;
    // 执行操做
    virtual void call (void) = 0;
};

不一样的请求，使用不一样的子类定义

class Put : public Method_Request {
public:
    Put (MQ_Servant *rep, Message arg) : servant_ (rep), arg_ (arg) {}
    virtual bool guard (void) const {
        // 约束检查
        return !servant_->full_i (); 
    }
    virtual void call (void) {
        // 插入消息
        servant_->put_i (arg_);  
    }
private:
    MQ_Servant *servant_;
    Message arg_;
};

上面的Guard函数，使用了MQ_Servant的full_i函数实现。

另一个“调用请求”子类：

class Get : public Method_Request {
public:
    Get (MQ_Servant *rep, const Message_Future &f) : servant_ (rep), result_ (f) {}
    bool guard (void) const {
        // Synchronization constraint:
        // cannot call a <get_i> method until
        // the queue is not empty.
        return !servant_->empty_i ();
    }
    virtual void call (void) {
        // Bind the dequeued message to the
        // future result object.
        result_ = servant_->get_i (); 
    }
private:
    MQ_Servant *servant_;
    // Message_Future result value.
    Message_Future result_;
};

这个对象要使用预定容器，处理最终返回的结构。其内部保存了预定容器。

3.活动队列的实现：每个“调用请求”。一个典型的实现，是一个线程安全的缓冲区。通常还要实现遍历其元素的循环子（Iterator）。下面是本例的C++实现。

class Activation_Queue {
public:
    // Block for an "infinite" amount of time
    // waiting for <enqueue> and <dequeue> methods
    // to complete.
    const int INFINITE = -1;
    // Define a "trait".
    typedef Activation_Queue_Iterator
    iterator;
    // Constructor creates the queue with the
    // specified high water mark that determines
    // its capacity.
    Activation_Queue (size_t high_water_mark);
    // Insert <method_request> into the queue, waiting
    // up to <msec_timeout> amount of time for space
    // to become available in the queue.
    void enqueue (Method_Request *method_request,
    long msec_timeout = INFINITE);
    // Remove <method_request> from the queue, waiting
    // up to <msec_timeout> amount of time for a
    // <method_request> to appear in the queue.
    void dequeue (Method_Request *method_request, long msec_timeout = INFINITE);
private:
    // Synchronization mechanisms, e.g., condition
    // variables and mutexes, and the queue
    // implementation, e.g., an array or a linked
    // list, go here.
    // ...
};

入队和出队的操做，是经典的“生产者、消费者”模型。很容易实现互斥访问。

4.调度者的实现：调度者要通常实现一个入队操做。调度执行线程函数。通常做为静态函数存在，调用dispatch，实现调度执行线程。

class MQ_Scheduler {
public:
    // Initialize the Activation_Queue to have the
    // specified capacity and make the Scheduler
    // run in its own thread of control.
    MQ_Scheduler (size_t high_water_mark);
    // ... Other constructors/destructors, etc.,
    // Insert the Method Request into
    // the Activation_Queue. This method
    // runs in the thread of its client, i.e.,
    // in the Proxy’s thread.
    void enqueue (Method_Request *method_request) {
        act_queue_->enqueue (method_request); 
    }
    // Dispatch the Method Requests on their Servant
    // in the Scheduler’s thread.
    virtual void dispatch (void);
protected:
    // Queue of pending Method_Requests.
    Activation_Queue *act_queue_;
    // Entry point into the new thread.
    static void *svc_run (void *arg);
};

例子中，线程的启动和活动队列的建立都在调度者的构造函数里面：

MQ_Scheduler (size_t high_water_mark) : act_queue_ (new Activation_Queue (high_water_mark)) {
    // Spawn a separate thread to dispatch
    // method requests.
    Thread_Manager::instance ()->spawn (svc_run, this);
}

线程函数很是简单，就是调用Dispatch：

void * MQ_Scheduler::svc_run (void *args) {
    MQ_Scheduler *this_obj = reinterpret_cast<MQ_Scheduler *> (args);
    this_obj->dispatch ();
}

Dispatch的实现以下：

virtual void MQ_Scheduler::dispatch (void) {
    // Iterate continuously in a
    // separate thread.
    for (;;) {
        Activation_Queue::iterator i;
        // The iterator’s <begin> call blocks
        // when the <Activation_Queue> is empty.
        for (i = act_queue_->begin (); i != act_queue_->end (); i++) {
                  // Select a Method Request ‘mr’
                  // whose guard evaluates to true.
                  Method_Request *mr = *i;
                  if (mr->guard ()) {
                    // Remove <mr> from the queue first
                    // in case <call> throws an exception.
                    act_queue_->dequeue (mr);
                    mr->call ();
                    delete mr;
                  }
            }
      }
}

5.异步调用之后，客户对返回结果的检测。调用活动对象的客户，如何获取和处理返回值？这有不一样的策略。有下面三种返回值策略。
1)同步调用，阻塞等待。客户线程阻塞，一直到操做完成、数据返回。
2)同步调用，限时等待。客户线程阻塞，一直到数据返回、数据返回或者发生超时。
3)异步调用。预定容器对象，提供某种异步方式返回数据或执行失败信息。
预定容器种的空间，被多个线程共享，当全部的线程都再也不使用的时候，才能被清空内存。要特别注意。
在咱们的例子种，Message_Future以下定义：

class Message_Future {
public:
      // Copy constructor binds <this> and <f> to the
      // same <Message_Future_Rep>, which is created if
      // necessary.
      Message_Future (const Message_Future &f);
      // Constructor that initializes <Message_Future> to
      // point to <Message> <m> immediately.
      Message_Future (const Message &m);
      // Assignment operator that binds <this> and <f>
      // to the same <Message_Future_Rep>, which is
      // created if necessary.
      void operator= (const Message_Future &f);
      // ... other constructors/destructors, etc.,
      // Type conversion, which blocks
      // waiting to obtain the result of the
      // asynchronous method invocation.
      operator Message ();
};

可使用引用计数的方法，处理Message的清除。
客户经过预定容器获取数据的两种方式：

当即方式：

MQ_Proxy mq;
// ...
// Conversion of Message_Future from the
// get() method into a Message causes the
// thread to block until a message is
// available.
Message msg = mq.get ();
// Transmit message to the consumer.
send (msg);

延迟方式：

// Obtain a future (does not block the client).
Message_Future future = mq.get ();
// Do something else here...
// Evaluate future in the conversion operator;
// may block if the result is not available yet.
Message msg = Message (future);

10  完成的例子

通讯网关程序内部，包含生产者（Supplier）和消费者（Consumer）的Handler，它们分别是远程生产者和远程消费者的代理。以下面的图3所示，生产者的Handler从远程设备上接收消息，分析消息中的地址，根据消息中的地址查找路由表，肯定哪个远程的消费者应该接收这个消息。路由表维护地址到消费者Handler的影射关系。每一个消费者的Handler实际经过对应的TCP链接把数据送出。

每个消费者Handler使用上面讲的主动对象的模式，内部包含一个消息队列（译者：经过保存“调用请求”的活动队列间接实现了消息的缓存）。来实现消息的异步发送。

class Consumer_Handler {
public:
      Consumer_Handler (void);
      // Put the message into the queue.
      void put (const Message &msg) {
            message_queue_.put (msg);
      }
private:
      // Proxy to the Active Object.
      MQ_Proxy message_queue_;
      // Connection to the remote consumer.
      SOCK_Stream connection_;
      // Entry point into the new thread.
      static void *svc_run (void *arg);
};

生产者的Handler，使用下面的方式，给消费者发送消息。

Supplier_Handler::route_message (const Message &msg) {
      // Locate the appropriate consumer based on the
      // address information in the Message.
      Consumer_Handler *ch = routing_table_.find (msg.address ());
      // Put the Message into the Consumer Handler’s queue.ch->put (msg);
};

消费者的Handler，就是Cosumer_Handler，在构造函数里面建立其调度处理线程。

Consumer_Handler::Consumer_Handler (void) {
      // Spawn a separate thread to get messages
      // from the message queue and send them to
      // the consumer.
      Thread_Manager::instance ()->spawn (svc_run, this);
}

下面是消费者Handler的线程函数的实现

void * Consumer_Handler::svc_run (void *args) {
      Consumer_Handler *this_obj = reinterpret_cast<Consumer_Handler *> (args);
      for (;;) {
            // Conversion of Message_Future from the
            // get() method into a Message causes the
            // thread to block until a message is
            // available.
            Message msg = this_obj->message_queue_.get ();
            // Transmit message to the consumer.this_obj->connection_.send (msg);
      }
}

当一个消费者的网络传送被阻塞的时候，只会阻塞其对应的线程，不会影响到其它消费者的Handler的处理。

11  变化

集成的调度者：

在实现主动对象模式的时候，为了减小对象的个数。能够把代理者和执行者的角色都分派到调度者身上。甚至“调用请求”的Call函数也能够由调度者实现。好比下面的代码，消息队列例子的集成实现方式。

class MQ_Scheduler {
public:
      MQ_Scheduler (size_t size) : act_queue_ (new Activation_Queue (size)) {}
      // ... other constructors/destructors, etc.,
      void put (const Message &msg) {
            Method_Request *method_request =
            // The <MQ_Scheduler> is the servant.
            new Put (this, msg);
            act_queue_->enqueue (method_request);
      }
      Message_Future get (void) {
            Message_Future result;
            Method_Request *method_request =
            // The <MQ_Scheduler> is the servant.
        new Get (this, result);
            act_queue_->enqueue (method_request);
            return result;
      }
      // ...
private:
      // Message queue servant operations.
      void put_i (const Message &msg);
      Message get_i (void);
      // Predicates.
      bool empty_i (void) const;
      bool full_i (void) const;
      Activation_Queue *act_queue_;
      // ...
};

这样集成后，减小了组件，实现更加简化。固然，这样也带来了缺点，调度者必须知道代理者和执行者的具体类型，具体实现。这样就很难在不一样的活动对象中，重用调度者。

消息的直接传递：

更近一步的简化，代理者和执行者都删除掉。在客户线程和调度者线程之间直接使用数据的方式传递消息。

class Scheduler {
public:
      Scheduler (size_t size) : act_queue_ (new Activation_Queue (size)) {}
      // ... other constructors/destructors, etc.,
      // Enqueue a Message Request in the thread of
      // the client.
      void enqueue (Message_Request *message_request) {
            act_queue_->enqueue (message_request);
      }
      // Dispatch Message Requests in the thread of
      // the Scheduler.
      virtual void dispatch (void) {
            Message_Request *mr;
            // Block waiting for next request to arrive.
            while (act_queue_->dequeue (mr)) {
                  // Process the message request <mr>.  
            }
      }
protected:
      Activation_Queue *act_queue_;
      // ...
};

由于没有了代理者，客户直接建立“调用请求”对象，而后调用调度者的函数把它入队到活动队列。一样的，没有了执行者，调度者的线程，在活动队列中获得请求，直接执行完成。

通常来讲，这样这样实现的一个消息传递的机制，比实现一个主动对象要简单的多。消息传递这种复杂的逻辑直接暴露给其客户，不但增长开发的难度，还容易滋生BUG，这样想来，不如把这种逻辑封装在主动对象的内部。具体如何选择，根据实际状况和本身的喜爱而定。

预定容器的泛型实现：

一个泛型的预定容器可使用返回值的类型进行定制。预定容器实现了一个一次写屡次读的同步机制。当容器中的值尚未准备好的时候，客户的访问操做被阻塞。这个泛型预定容器，部分实现了读者/写者模型，又部分实现了生产者/消费者模型。

下面是C++模板实现的例子

template <class T>
class Future {
    // This class implements a ‘single write, multiple
      // read’ pattern that can be used to return results
      // from asynchronous method invocations.
public:
      // Constructor.
      Future (void);
      // Copy constructor that binds <this> and <r> to
      // the same <Future> representation
      Future (const Future<T> &r);
      // Destructor.
      ~Future (void);
      // Assignment operator that binds <this> and
      // <r> to the same <Future>.
      void operator = (const Future<T> &r);
      // Cancel a <Future>. Put the future into its
      // initial state. Returns 0 on success and -1
      // on failure.
      int cancel (void);
      // Type conversion, which obtains the result
      // of the asynchronous method invocation.
      // Will block forever until the result is
      // obtained.
      operator T ();
      // Check if the result is available.
      int ready (void);
private:
      Future_Rep<T> *future_rep_;
      // Future representation implemented using
      // the Counted Pointer idiom.
};

这个模板能够以下使用：

// Obtain a future (does not block the client).
Future<Message> future = mq.get ();
// Do something else here...
// Evaluate future in the conversion operator;
// may block if the result is not available yet.
Message msg = Message (future);

分布式活动对象：

代理者和调度者之间跨过网络。代理者把要把“调用请求”对象序列化，而后经过网络传输给另外机器上的调度者，调度者接收并再造“调用请求”对象。

使用线程池：

使用线程池，可让一个活动对象支持多个执行者。多个执行者提供相同的服务。每个执行者运行在不一样的线程中，由调度者统一调度，当有新的请求时，调度者立刻安排一个工做线程工做。

12  已知的应用

1.CORBAORBS
2.ACEFramework
3.SiemensMedCom
4.SiemensCallCentermanagementsystem:
5.Actors

译者：此节只列出他们的名字，感兴趣的同志请参考原文。和看《设计模式》的时候状况同样，我不太关注这一节。

13  后果

有下面的好处：
1.加强了程序的并行性，下降了同步的复杂性。客户线程和异步调起操做并行执行。同步的复杂性由调度者独立处理。
2.让多个耗时的操做并行执行。只要软件和硬件支持，可让多个活动的对象彼此不干扰地同时运行。
3.方法的执行和调用的顺序能够不一致。方法的调用是异步调用。而方法的执行决定于如何调度。
固然，主动对象也有如下负面的影响
1.性能过多消耗：系统消耗的程度决定于调度者的实现。用户态和系统态的上下文切换，同步信号的时候，数据的传送都会带来消耗。通常说来，主动对象模式适合大粒度的对象，对很小的对象使用这个模式容易带来性能的过分消耗。请和其它并发模式比较如监控者模式。
2.增长调试的难度：并发的复杂和调度的不可预测，会增长调试的困难。而且，许多调试工具都不能彻底的支持并发程序的调试。

14  更多相关模式

译者：这些模式许多我还也没有接触，准备逐个学习，高兴的话还会翻译

监控者（Monitor）模式使用后，不管多少线程对一个被动对象调用，保证同时只有一个在实际执行。由于更少的上下文切换和数据传递，这个模式比主动对象效率告。但此模式较难把客户和服务线程分布在不一样机器上。

反应堆（Reactor）模式，当不会再发生阻塞的时候，触发多个事件处理器，分解和触发任务。在存在回调机制的被动对象时，经常使用这个模式代替主动对象。也经常用它来链接主动对象和下面的半同步半异步模式一块儿使用。

半同步半异步（Half-Sync/Half-Async）模式，这个摸索用来分离同步和异步调用。这个模式经常使用活动对象来实现异步任务层。
命令处理器（CommandProcessor）模式，这个模式和主动对象差很少。它用来分离请求的发出和执行，一个命令处理器就至关于一个调度者。然而，他没有代理者，客户直接发布命令。

Broker模式，这个也和主动对象相似。主要的不一样是，代理者和执行者是分布边界而不是线程边界。

互斥体（Mutex）模式。有时代替主动对象模式，简单的在一个主动对象上加一个锁，使其能够并发的被调用。他有多种实现方式，如重叠的锁，支持权限继承的锁。