本文由黄文海首次发布在infoq中文站上：http://www.infoq.com/cn/articles/Java-multithreaded-programming-mode-active-object-part1 。转载请注明作者： 黄文海 出处：http://viscent.iteye.com。
Active Object模式简介
Active Object模式是一种异步编程模式。它通过对方法的调用与方法的执行进行解耦来提高并发性。若以任务的概念来说，Active Object模式的核心则是它允许任务的提交（相当于对异步方法的调用）和任务的执行（相当于异步方法的真正执行）分离。这有点类似于 System.gc()这个方法：客户端代码调用完gc()后，一个进行垃圾回收的任务被提交，但此时JVM并不一定进行了垃圾回收，而可能是在gc() 方法调用返回后的某段时间才开始执行任务——回收垃圾。我们知道，System.gc()的调用方代码是运行在自己的线程上（通常是main线程派生的子 线程），而JVM的垃圾回收这个动作则由专门的线程（垃圾回收线程）来执行的。换言之，System.gc()这个方法所代表的动作（其所定义的功能）的 调用方和执行方是运行在不同的线程中的，从而提高了并发性。
再进一步介绍Active Object模式，我们可先简单地将其核心理解为一个名为ActiveObject的类，该类对外暴露了一些异步方法，如图1所示。
图 1. ActiveObject对象示例
doSomething方法的调用方和执行方运行在各自的线程上。在并发的环境下，doSomething方法会被多个线程调用。这时所需的线程安 全控制封装在doSomething方法背后，使得调用方代码无需关心这点，从而简化了调用方代码：从调用方代码来看，调用一个Active Object对象的方法与调用普通Java对象的方法并无太大差别。如清单1所示。
清单 1. Active Object方法调用示例
ActiveObject ao=...;
Future future = ao.doSomething("data");
//执行其它操作
String result = future.get();
System.out.println(result);
Active Object模式的架构
当Active Object模式对外暴露的异步方法被调用时，与该方法调用相关的上下文信息，包括被调用的异步方法名（或其代表的操作）、调用方代码所传递的参数等，会 被封装成一个对象。该对象被称为方法请求（Method Request）。方法请求对象会被存入Active Object模式所维护的缓冲区（Activation Queue）中，并由专门的工作线程负责根据其包含的上下文信息执行相应的操作。也就是说，方法请求对象是由运行调用方代码的线程通过调用Active Object模式对外暴露的异步方法生成的，而方法请求所代表的操作则由专门的线程来执行，从而实现了方法的调用与执行的分离，产生了并发。
Active Object模式的主要参与者有以下几种。其类图如图2所示。
图 2. Active Object模式的类图
(点击图像放大)
- Proxy：负责对外暴露异步方法接口。当调用方代码调用该参与者实例的异步方法doSomething时，该方法会生成一个相 应的MethodRequest实例并将其存储到Scheduler所维护的缓冲区中。doSomething方法的返回值是一个表示其执行结果的外包装 对象：Future参与者的实例。异步方法doSomething运行在调用方代码所在的线程中。
- MethodRequest：负责将调用方代码对Proxy实例的异步方法的调用封装为一个对象。该对象保留了异步方法的名称及调用方代码传递的参数等上下文信息。它使得将Proxy的异步方法的调用和执行分离成为可能。其call方法会根据其所包含上下文信息调用Servant实例的相应方法。
- ActivationQueue：负责临时存储由Proxy的异步方法被调用时所创建的MethodRequest实例的缓冲区。
- Scheduler：负责将Proxy的异步方法所创建的MethodRequest实例存入其维护的缓冲区中。并根据一定的调 度策略，对其维护的缓冲区中的MethodRequest实例进行执行。其调度策略可以根据实际需要来定，如FIFO、LIFO和根据 MethodRequest中包含的信息所定的优先级等。
- Servant：负责对Proxy所暴露的异步方法的具体实现。
- Future：负责存储和返回Active Object异步方法的执行结果。
Active Object模式的序列图如图3所示。
图 3. Active Object模式的序列图
(点击图像放大)
第1步：调用方代码调用Proxy的异步方法doSomething。
第2～7步：doSomething方法创建Future实例作为该方法的返回值。并将调用方代码对该方法的调用封装为MethodRequest 对象。然后以所创建的MethodRequest对象作为参数调用Scheduler的enqueue方法，以将MethodRequest对象存入缓冲 区。Scheduler的enqueue方法会调用Scheduler所维护的ActivationQueue实例的enqueue方法，将 MethodRequest对象存入缓冲区。
第8步：doSomething返回其所创建的Future实例。
第9步：Scheduler实例采用专门的工作线程运行dispatch方法。
第10～12步：dispatch方法调用ActivationQueue实例的dequeue方法，获取一个MethodRequest对象。然后调用MethodRequest对象的call方法
第13～16步：MethodRequest对象的call方法调用与其关联的Servant实例的相应方法doSomething。并将Servant.doSomething方法的返回值设置到Future实例上。
第17步：MethodRequest对象的call方法返回。
上述步骤中，第1～8步是运行在Active Object的调用者线程中的，这几个步骤实现了将调用方代码对Active Object所提供的异步方法的调用封装成对象（Method Request），并将其存入缓冲区。这几个步骤实现了任务的提交。第9～17步是运行在Active Object的工作线程中，这些步骤实现从缓冲区中读取Method Request，并对其进行执行，实现了任务的执行。从而实现了Active Object对外暴露的异步方法的调用与执行的分离。
如果调用方代码关心Active Object的异步方法的返回值，则可以在其需要时，调用Future实例的get方法来获得异步方法的真正执行结果。
Active Object模式实战案例
某电信软件有一个彩信短号模块。其主要功能是实现手机用户给其它手机用户发送彩信时，接收方号码可以填写为对方的短号。例如，用户13612345678给其同事13787654321发送彩信时，可以将接收方号码填写为对方的短号，如776，而非其真实的号码。
该模块处理其接收到的下发彩信请求的一个关键操作是查询数据库以获得接收方短号对应的真实号码（长号）。该操作可能因为数据库故障而失败，从而使整 个请求无法继续被处理。而数据库故障是可恢复的故障，因此在短号转换为长号的过程中如果出现数据库异常，可以先将整个下发彩信请求消息缓存到磁盘中，等到 数据库恢复后，再从磁盘中读取请求消息，进行重试。为方便起见，我们可以通过Java的对象序列化API，将表示下发彩信的对象序列化到磁盘文件中从而实 现请求缓存。下面我们讨论这个请求缓存操作还需要考虑的其它因素，以及Active Object模式如何帮助我们满足这些考虑。
首先，请求消息缓存到磁盘中涉及文件I/O这种慢的操作，我们不希望它在请求处理的主线程（即Web服务器的工作线程）中执行。因为这样会使该模块 的响应延时增大，降低系统的响应性。并使得Web服务器的工作线程因等待文件I/O而降低了系统的吞吐量。这时，异步处理就派上用场了。Active Object模式可以帮助我们实现请求缓存这个任务的提交和执行分离：任务的提交是在Web服务器的工作线程中完成，而任务的执行（包括序列化对象到磁盘 文件中等操作）则是在Active Object工作线程中执行。这样，请求处理的主线程在侦测到短号转长号失败时即可以触发对当前彩信下发请求进行缓存，接着继续其请求处理，如给客户端响 应。而此时，当前请求消息可能正在被Active Object线程缓存到文件中。如图4所示。
图 4 .异步实现缓存
其次，每个短号转长号失败的彩信下发请求消息会被缓存为一个磁盘文件。但我们不希望这些缓存文件被存在同一个子目录下。而是希望多个缓存文件会被存 储到多个子目录中。每个子目录最多可以存储指定个数（如2000个）的缓存文件。若当前子目录已存满，则新建一个子目录存放新的缓存文件，直到该子目录也 存满，依此类推。当这些子目录的个数到达指定数量（如100个）时，最老的子目录（连同其下的缓存文件，如果有的话）会被删除。从而保证子目录的个数也是 固定的。显然，在并发环境下，实现这种控制需要一些并发访问控制（如通过锁来控制），但是我们不希望这种控制暴露给处理请求的其它代码。而Active Object模式中的Proxy参与者可以帮助我们封装并发访问控制。
下面，我们看该案例的相关代码通过应用Active Object模式在实现缓存功能时满足上述两个目标。首先看请求处理的入口类。该类就是本案例的Active Object模式的客调用方代码。如清单2所示。
清单 2. 彩信下发请求处理的入口类
public class MMSDeliveryServlet extends HttpServlet {
private static final long serialVersionUID = 5886933373599895099L;
@Override
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
//将请求中的数据解析为内部对象
MMSDeliverRequest mmsDeliverReq = this.parseRequest(req.getInputStream());
Recipient shortNumberRecipient = mmsDeliverReq.getRecipient();
Recipient originalNumberRecipient = null;
try {
// 将接收方短号转换为长号
originalNumberRecipient = convertShortNumber(shortNumberRecipient);
} catch (SQLException e) {
// 接收方短号转换为长号时发生数据库异常，触发请求消息的缓存
AsyncRequestPersistence.getInstance().store(mmsDeliverReq);
// 继续对当前请求的其它处理，如给客户端响应
resp.setStatus(202);
}
}
private MMSDeliverRequest parseRequest(InputStream reqInputStream) {
MMSDeliverRequest mmsDeliverReq = new MMSDeliverRequest();
//省略其它代码
return mmsDeliverReq;
}
private Recipient convertShortNumber(Recipient shortNumberRecipient)
throws SQLException {
Recipient recipent = null;
//省略其它代码
return recipent;
}
}
清单2中的doPost方法在侦测到短号转换过程中发生的数据库异常后，通过调用AsyncRequestPersistence类的store方 法触发对彩信下发请求消息的缓存。这里，AsyncRequestPersistence类相当于Active Object模式中的Proxy参与者。尽管本案例涉及的是一个并发环境，但从清单2中的代码可见，AsyncRequestPersistence类的 调用方代码无需处理多线程同步问题。这是因为多线程同步问题被封装在AsyncRequestPersistence类之后。
AsyncRequestPersistence类的代码如清单3所示。
清单 3. 彩信下发请求缓存入口类（Active Object模式的Proxy）
// ActiveObjectPattern.Proxy
public class AsyncRequestPersistence implements RequestPersistence {
private static final long ONE_MINUTE_IN_SECONDS = 60;
private final Logger logger;
private final AtomicLong taskTimeConsumedPerInterval = new AtomicLong(0);
private final AtomicInteger requestSubmittedPerIterval = new AtomicInteger(0); // ActiveObjectPattern.Servant
private final DiskbasedRequestPersistence
delegate = new DiskbasedRequestPersistence();
// ActiveObjectPattern.Scheduler
private final ThreadPoolExecutor scheduler; private static class InstanceHolder {
final static RequestPersistence INSTANCE = new AsyncRequestPersistence();
} private AsyncRequestPersistence() {
logger = Logger.getLogger(AsyncRequestPersistence.class);
scheduler = new ThreadPoolExecutor(1, 3,
60 * ONE_MINUTE_IN_SECONDS,
TimeUnit.SECONDS,
// ActiveObjectPattern.ActivationQueue
new LinkedBlockingQueue(200),
new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
Thread t;
t = new Thread(r, "AsyncRequestPersistence");
return t;
} }); scheduler.setRejectedExecutionHandler(
new ThreadPoolExecutor.DiscardOldestPolicy()); // 启动队列监控定时任务
Timer monitorTimer = new Timer(true);
monitorTimer.scheduleAtFixedRate(
new TimerTask() { @Override
public void run() {
if (logger.isInfoEnabled()) { logger.info("task count:"
+ requestSubmittedPerIterval
+ ",Queue size:"
+ scheduler.getQueue().size()
+ ",taskTimeConsumedPerInterval:"
+ taskTimeConsumedPerInterval.get()
+ " ms");
} taskTimeConsumedPerInterval.set(0);
requestSubmittedPerIterval.set(0); }
}, 0, ONE_MINUTE_IN_SECONDS * 1000);
} public static RequestPersistence getInstance() {
return InstanceHolder.INSTANCE;
} @Override
public void store(final MMSDeliverRequest request) {
/*
* 将对store方法的调用封装成MethodRequest对象, 并存入缓冲区。
*/
// ActiveObjectPattern.MethodRequest
Callable methodRequest = new Callable() {
@Override
public Boolean call() throws Exception {
long start = System.currentTimeMillis();
try {
delegate.store(request);
} finally {
taskTimeConsumedPerInterval.addAndGet(
System.currentTimeMillis() - start);
} return Boolean.TRUE;
} };
scheduler.submit(methodRequest); requestSubmittedPerIterval.incrementAndGet();
} }
AsyncRequestPersistence类所实现的接口RequestPersistence定义了Active Object对外暴露的异步方法：store方法。由于本案例不关心请求缓存的结果，故该方法没有返回值。其代码如清单4所示。
清单 4. RequestPersistence接口源码
public interface RequestPersistence {
void store(MMSDeliverRequest request);
}
AsyncRequestPersistence类的实例变量scheduler相当于Active Object模式中的Scheduler参与者实例。这里我们直接使用了JDK1.5引入的Executor Framework中的ThreadPoolExecutor。在ThreadPoolExecutor类的实例化时，其构造器的第5个参数 （BlockingQueue<Runnable> workQueue）我们指定了一个有界阻塞队列：new LinkedBlockingQueue<Runnable>(200)。该队列相当于Active Object模式中的ActivationQueue参与者实例。
AsyncRequestPersistence类的实例变量delegate相当于Active Object模式中的Servant参与者实例。
AsyncRequestPersistence类的store方法利用匿名类生成一个 java.util.concurrent.Callable实例methodRequest。该实例相当于Active Object模式中的MethodRequest参与者实例。利用闭包（Closure），该实例封装了对store方法调用的上下文信息（包括调用参 数、所调用的方法对应的操作信息）。AsyncRequestPersistence类的store方法通过调用scheduler的submit方法， 将methodRequest送入ThreadPoolExecutor所维护的缓冲区（阻塞队列）中。确切地说，ThreadPoolExecutor 是Scheduler参与者的一个“近似”实现。ThreadPoolExecutor的submit方法相对于Scheduler的enqueue方 法，该方法用于接纳MethodRequest对象，以将其存入缓冲区。当ThreadPoolExecutor当前使用的线程数量小于其核心线程数量 时，submit方法所接收的任务会直接被新建的线程执行。当ThreadPoolExecutor当前使用的线程数量大于其核心线程数时，submit 方法所接收的任务才会被存入其维护的阻塞队列中。不过，ThreadPoolExecutor的这种任务处理机制，并不妨碍我们将它用作 Scheduler的实现。
methodRequest的call方法会调用delegate的store方法来真正实现请求缓存功能。delegate实例对应的类DiskbasedRequestPersistence是请求消息缓存功能的真正实现者。其代码如清单5所示。
清单 5. DiskbasedRequestPersistence类的源码
public class DiskbasedRequestPersistence implements RequestPersistence {
// 负责缓存文件的存储管理
private final SectionBasedDiskStorage storage = new SectionBasedDiskStorage();
private final Logger logger = Logger
.getLogger(DiskbasedRequestPersistence.class);
@Override
public void store(MMSDeliverRequest request) {
// 申请缓存文件的文件名
String[] fileNameParts = storage.apply4Filename(request);
File file = new File(fileNameParts[0]);
try {
ObjectOutputStream objOut = new ObjectOutputStream(
new FileOutputStream(file));
try {
objOut.writeObject(request);
} finally {
objOut.close();
}
} catch (FileNotFoundException e) {
storage.decrementSectionFileCount(fileNameParts[1]);
logger.error("Failed to store request", e);
} catch (IOException e) {
storage.decrementSectionFileCount(fileNameParts[1]);
logger.error("Failed to store request", e);
}
}
class SectionBasedDiskStorage {
private Deque sectionNames = new LinkedList();
/*
* Key->value: 存储子目录名->子目录下缓存文件计数器
*/
private Map sectionFileCountMap
= new HashMap();
private int maxFilesPerSection = 2000;
private int maxSectionCount = 100;
private String storageBaseDir = System.getProperty("user.dir") + "/vpn";
private final Object sectionLock = new Object();
public String[] apply4Filename(MMSDeliverRequest request) {
String sectionName;
int iFileCount;
boolean need2RemoveSection = false;
String[] fileName = new String[2];
synchronized (sectionLock) {
//获取当前的存储子目录名
sectionName = this.getSectionName();
AtomicInteger fileCount;
fileCount = sectionFileCountMap.get(sectionName);
iFileCount = fileCount.get();
//当前存储子目录已满
if (iFileCount >= maxFilesPerSection) {
if (sectionNames.size() >= maxSectionCount) {
need2RemoveSection = true;
}
//创建新的存储子目录
sectionName = this.makeNewSectionDir();
fileCount = sectionFileCountMap.get(sectionName);
}
iFileCount = fileCount.addAndGet(1);
}
fileName[0] = storageBaseDir + "/" + sectionName + "/"
+ new DecimalFormat("0000").format(iFileCount) + "-"
+ request.getTimeStamp().getTime() / 1000 + "-"
+ request.getExpiry()
+ ".rq";
fileName[1] = sectionName;
if (need2RemoveSection) {
//删除最老的存储子目录
String oldestSectionName = sectionNames.removeFirst();
this.removeSection(oldestSectionName);
}
return fileName;
}
public void decrementSectionFileCount(String sectionName) {
AtomicInteger fileCount = sectionFileCountMap.get(sectionName);
if (null != fileCount) {
fileCount.decrementAndGet();
}
}
private boolean removeSection(String sectionName) {
boolean result = true;
File dir = new File(storageBaseDir + "/" + sectionName);
for (File file : dir.listFiles()) {
result = result && file.delete();
}
result = result && dir.delete();
return result;
}
private String getSectionName() {
String sectionName;
if (sectionNames.isEmpty()) {
sectionName = this.makeNewSectionDir();
} else {
sectionName = sectionNames.getLast();
}
return sectionName;
}
private String makeNewSectionDir() {
String sectionName;
SimpleDateFormat sdf = new SimpleDateFormat("MMddHHmmss");
sectionName = sdf.format(new Date());
File dir = new File(storageBaseDir + "/" + sectionName);
if (dir.mkdir()) {
sectionNames.addLast(sectionName);
sectionFileCountMap.put(sectionName, new AtomicInteger(0));
} else {
throw new RuntimeException(
"Cannot create section dir " + sectionName);
}
return sectionName;
}
}
}
methodRequest的call方法的调用者代码是运行在ThreadPoolExecutor所维护的工作者线程中，这就保证了store 方法的调用方和真正的执行方是分别运行在不同的线程中：服务器工作线程负责触发请求消息缓存，ThreadPoolExecutor所维护的工作线程负责 将请求消息序列化到磁盘文件中。
DiskbasedRequestPersistence类的store方法中调用的SectionBasedDiskStorage类的 apply4Filename方法包含了一些多线程同步控制代码（见清单5）。这部分控制由于是封装在 DiskbasedRequestPersistence的内部类中，对于该类之外的代码是不可见的。因 此，AsyncRequestPersistence的调用方代码无法知道该细节，这体现了Active Object模式对并发访问控制的封装。
小结
本篇介绍了Active Object模式的意图及架构，并以一个实际的案例展示了该模式的代码实现。下篇将对Active Object模式进行评价，并结合本文案例介绍实际运用Active Object模式时需要注意的一些事项。
Active Object模式的评价与实现考量
Active Object模式通过将方法的调用与执行分离，实现了异步编程。有利于提高并发性，从而提高系统的吞吐率。
Active Object模式还有个好处是它可以将任务（MethodRequest）的提交（调用异步方法）和任务的执行策略（Execution Policy）分离。任务的执行策略被封装在Scheduler的实现类之内，因此它对外是不“可见”的，一旦需要变动也不会影响其它代码，降低了系统的 耦合性。任务的执行策略可以反映以下一些问题：
- 采用什么顺序去执行任务，如FIFO、LIFO、或者基于任务中包含的信息所定的优先级？
- 多少个任务可以并发执行？
- 多少个任务可以被排队等待执行？
- 如果有任务由于系统过载被拒绝，此时哪个任务该被选中作为牺牲品，应用程序该如何被通知到？
- 任务执行前、执行后需要执行哪些操作？
这意味着，任务的执行顺序可以和任务的提交顺序不同，可以采用单线程也可以采用多线程去执行任务等等。
当然，好处的背后总是隐藏着代价，Active Object模式实现异步编程也有其代价。该模式的参与者有6个之多，其实现过程也包含了不少中间的处理：MethodRequest对象的生成、 MethodRequest对象的移动（进出缓冲区）、MethodRequest对象的运行调度和线程上下文切换等。这些处理都有其空间和时间的代价。 因此，Active Object模式适合于分解一个比较耗时的任务（如涉及I/O操作的任务）：将任务的发起和执行进行分离，以减少不必要的等待时间。
虽然模式的参与者较多，但正如本文案例的实现代码所展示的，其中大部分的参与者我们可以利用JDK自身提供的类来实现，以节省编码时间。如表1所示。
表 1. 使用JDK现有类实现Active Object的一些参与者
|
参与者名称 |
可以借用的JDK类 |
备注 |
|
Scheduler |
Java Executor Framework中的java.util.concurrent.ExecutorService接口的相关实现类，如java.util.concurrent.ThreadPoolExecutor。 |
ExecutorService接口所定义的submit(Callable<T> task)方法相当于图2中的enqueue方法。 |
|
ActivationQueue |
java.util.concurrent.LinkedBlockingQueue |
若Scheduler采用java.util.concurrent.ThreadPoolExecutor，则java.util.concurrent.LinkedBlockingQueue实例作为ThreadPoolExecutor构造器的参数。 |
|
MethodRequest |
java.util.concurrent.Callable接口的匿名实现类。 |
Callable接口比起Runnable接口的优势在于它定义的call方法有返回值，便于将该返回值传递给Future实例。 |
|
Future |
java.util.concurrent.Future |
ExecutorService接口所定义的submit(Callable<T> task)方法的返回值类型就是java.util.concurrent.Future。 |
错误隔离
错误隔离指一个任务的处理失败不影响其它任务的处理。每个MethodRequest实例可以看作一个任务。那么，Scheduler的实现类在执 行MethodRequest时需要注意错误隔离。选用JDK中现成的类（如ThreadPoolExecutor）来实现Scheduler的一个好处 就是这些类可能已经实现了错误隔离。而如果自己编写代码实现Scheduler，用单个Active Object工作线程逐一执行所有任务，则需要特别注意线程的run方法的异常处理，确保不会因为个别任务执行时遇到一些运行时异常而导致整个线程终止。 如清单6的示例代码所示。
清单 6. 自己动手实现Scheduler的错误隔离示例代码
public class CustomScheduler implements Runnable {
private LinkedBlockingQueue<Runnable> activationQueue =
new LinkedBlockingQueue<Runnable>();
@Override
public void run() {
dispatch();
}
public <T> Future<T> enqueue(Callable<T> methodRequest) {
final FutureTask<T> task = new FutureTask<T>(methodRequest) {
@Override
public void run() {
try {
super.run();
//捕获所以可能抛出的对象，避免该任务运行失败而导致其所在的线程终止。
} catch (Throwable t) {
this.setException(t);
}
}
};
try {
activationQueue.put(task);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
return task;
}
public void dispatch() {
while (true) {
Runnable methodRequest;
try {
methodRequest = activationQueue.take();
//防止个别任务执行失败导致线程终止的代码在run方法中
methodRequest.run();
} catch (InterruptedException e) {
// 处理该异常
}
}
}
}
缓冲区监控
如果ActivationQueue是有界缓冲区，则对缓冲区的当前大小进行监控无论是对于运维还是测试来说都有其意义。从测试的角度来看，监控缓 冲区有助于确定缓冲区容量的建议值（合理值）。清单3所示的代码，即是通过定时任务周期性地调用ThreadPoolExecutor的getQueue 方法对缓冲区的大小进行监控。当然，在监控缓冲区的时候，往往只需要大致的值，因此在监控代码中要避免不必要的锁。
缓冲区饱和处理策略
当任务的提交速率大于任务的执行数率时，缓冲区可能逐渐积压到满。这时新提交的任务会被拒绝。无论是自己编写代码还是利用JDK现有类来实现 Scheduler，对于缓冲区满时新任务提交失败，我们需要一个处理策略用于决定此时哪个任务会成为“牺牲品”。若使用 ThreadPoolExecutor来实现Scheduler有个好处是它已经提供了几个缓冲区饱和处理策略的实现代码，应用代码可以直接调用。如清单 3的代码所示，本文案例中我们选择了抛弃最老的任务作为处理策略。 java.util.concurrent.RejectedExecutionHandler接口是ThreadPoolExecutor对缓冲区饱和 处理策略的抽象，JDK中提供的具体实现如表2所示。
表 2. JDK提供的缓冲区饱和处理策略实现类
|
实现类 |
所实现的处理策略 |
|
ThreadPoolExecutor.AbortPolicy |
直接抛出异常。 |
|
ThreadPoolExecutor.DiscardPolicy |
放弃当前被拒绝的任务（而不抛出任何异常）。 |
|
ThreadPoolExecutor.DiscardOldestPolicy |
将缓冲区中最老的任务放弃，然后重新尝试接纳被拒绝的任务。 |
|
ThreadPoolExecutor.CallerRunsPolicy |
在任务的提交方线程中运行被拒绝的任务。 |
当然，对于ThreadPoolExecutor而言，其工作队列满不一定就意味着新提交的任务会被拒绝。当其最大线程池大小大于其核心线程池大小 时，工作队列满的情况下，新提交的任务会用所有核心线程之外的新增线程来执行，直到工作线程数达到最大线程数时，新提交的任务会被拒绝。
Scheduler空闲工作线程清理
如果Scheduler采用多个工作线程（如采用ThreadPoolExecutor这样的线程池）来执行任务。则可能需要清理空闲的线程以节约 资源。清单3的代码就是直接使用了ThreadPoolExecutor的现有功能，在初始化其实例时通过指定其构造器的第3、4个参数（ long keepAliveTime, TimeUnit unit），告诉ThreadPoolExecutor对于核心工作线程以外的线程若其已经空闲了指定时间，则将其清理掉。
可复用的Active Object模式实现
尽管利用JDK中的现成类可以极大地简化Active Object模式的实现。但如果需要频繁地在不同场景下使用Active Object模式，则需要一套更利于复用的代码，以节约编码的时间和使代码更加易于理解。清单7展示一段基于Java动态代理的可复用的Active Object模式的Proxy参与者的实现代码。
清单 7. 可复用的Active Object模式Proxy参与者实现
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Future;
public abstract class ActiveObjectProxy { private static class DispatchInvocationHandler implements InvocationHandler {
private final Object delegate;
private final ExecutorService scheduler; public DispatchInvocationHandler(Object delegate,
ExecutorService executorService) {
this.delegate = delegate;
this.scheduler = executorService;
} private String makeDelegateMethodName(final Method method,
final Object[] arg) {
String name = method.getName();
name = "do" + Character.toUpperCase(name.charAt(0))
+ name.substring(1); return name;
} @Override
public Object invoke(final Object proxy, final Method method,
final Object[] args) throws Throwable { Object returnValue = null;
final Object delegate = this.delegate;
final Method delegateMethod; //如果拦截到的被调用方法是异步方法，则将其转发到相应的doXXX方法
if (Future.class.isAssignableFrom(method.getReturnType())) {
delegateMethod = delegate.getClass().getMethod(
makeDelegateMethodName(method, args),
method.getParameterTypes()); final ExecutorService scheduler = this.scheduler; Callable<Object> methodRequest = new Callable<Object>() {
@Override
public Object call() throws Exception {
Object rv = null; try {
rv = delegateMethod.invoke(delegate, args);
} catch (IllegalArgumentException e) {
throw new Exception(e);
} catch (IllegalAccessException e) {
throw new Exception(e);
} catch (InvocationTargetException e) {
throw new Exception(e);
}
return rv;
}
};
Future<Object> future = scheduler.submit(methodRequest);
returnValue = future; } else { //若拦截到的方法调用不是异步方法，则直接转发
delegateMethod = delegate.getClass()
.getMethod(method.getName(),method.getParameterTypes()); returnValue = delegateMethod.invoke(delegate, args);
} return returnValue;
}
} /**
* 生成一个实现指定接口的Active Object proxy实例。
* 对interf所定义的异步方法的调用会被装发到servant的相应doXXX方法。
* @param interf 要实现的Active Object接口
* @param servant Active Object的Servant参与者实例
* @param scheduler Active Object的Scheduler参与者实例
* @return Active Object的Proxy参与者实例
*/
public static <T> T newInstance(Class<T> interf, Object servant,
ExecutorService scheduler) { @SuppressWarnings("unchecked")
T f = (T) Proxy.newProxyInstance(interf.getClassLoader(),
new Class[] { interf },
new DispatchInvocationHandler(servant, scheduler)); return f;
}
}
清单7的代码实现了可复用的Active Object模式的Proxy参与者ActiveObjectProxy。ActiveObjectProxy通过使用Java动态代理，动态生成指定接 口的代理对象。对该代理对象的异步方法（即返回值类型为java.util.concurrent.Future的方法）的调用会被 ActiveObjectProxy实现InvocationHandler（DispatchInvocationHandler）所拦截，并转发给 ActiveObjectProxy的newInstance方法中指定的Servant处理。
清单8所示的代码展示了通过使用ActiveObjectProxy快速Active Object模式。
清单 8. 基于可复用的API快速实现Active Object模式
public static void main(String[] args) throws
InterruptedException, ExecutionException { SampleActiveObject sao = ActiveObjectProxy.newInstance(
SampleActiveObject.class, new SampleActiveObjectImpl(),
Executors.newCachedThreadPool());
Future<String> ft = sao.process("Something", 1);
Thread.sleep(500);
System.out.println(ft.get());
从清单8的代码可见，利用可复用的Active Object模式Proxy实现，应用开发人员只要指定Active Object模式对外保留的接口（对应ActiveObjectProxy.newInstance方法的第1个参数），并提供一个该接口的实现类（对应 ActiveObjectProxy.newInstance方法的第2个参数），再指定一个 java.util.concurrent.ExecutorService实例（对应ActiveObjectProxy.newInstance方法 的第3个参数）即可以实现Active Object模式。
总结
本文介绍了Active Object模式的意图及架构。并提供了一个实际的案例用于展示使用Java代码实现Active Object模式，在此基础上对该模式进行了评价并分享了在实际运用该模式时需要注意的事项。
参考资源
- 本文的源代码在线阅读：https://github.com/Viscent/JavaConcurrencyPattern/
- *Active Object模式词条：http://en.wikipedia.org/wiki/Active_object
- Douglas C. Schmidt对Active Object模式的定义：http://www.laputan.org/pub/sag/act-obj.pdf。
- Schmidt, Douglas et al. Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects. Volume 2. Wiley, 2000
- Java theory and practice: Decorating with dynamic proxies：http://www.ibm.com/developerworks/java/library/j-jtp08305/index.html