多对一的关系。一个 Runnable 可以被多个 Thread 执行。只要将 Runnable 的执行代码
设置成上述的消息调度函数，并和消息队列对应上，那么就可以通过控制为它服务的
Thread 个数来决定消息队列执行的快慢，并且在运行时可以动态地新增(new)和退出
Thread 对象。这样就能任意调整不同消息队列在执行时所占用 CPU 资源的多少。至此，
任何一个 Java 调用都可以在 Thread 个数不同的消息队列中选择，并可以调整这些消息
队列服务的 Thread 个数，从而实现在运行时调整任务所占用的 CPU 资源。
　　纵观整个方案，由于仅仅基于 Java 语言固有的 Method 对象，不同任务间动态分配
CPU 资源并没有对任务的性质及其处理流程有任何限制，那么在消息队列中没有高优先
级消息时，低优先级消息的处理函数自然会全部占用 CPU 资源。在不同消息队列处理速
度任意设置时，并没有将特定的消息限制在快的或者慢的消息队列上。如果系统的负荷超
出(比如消息队列长度超过一定限制)，只要将队列中低优先级消息换出或者拒绝不能处
理的消息进入，那么系统的运行就可以基本上不受负荷压力的影响，从而最大保障用户
的关键业务需求。
　　当然，协调式多任务的思想也有其局限性，主要就是它的调度粒度比较大。系统能够
保证的粒度是一次消息处理过程。如果消息处理逻辑非常费时，那么编程人员就必须再处
理函数内部，让系统主动让出 CPU 资源。这虽然需要在处理消息响应逻辑时增加一个考
虑因素，但是，在 Windows 系统盛行的今天，这是一个已经被普遍接受的思路。由于方
案中并没有局限为消息队列服务的线程数目，所以一个长时间的消息响应只会影响一个
线程，而不会对整个系统产生致命的影响。除了调度粒度的问题以外，还有访问消息队列
操作在各个线程间互斥的问题。取出消息的过程是串行化的，因此对于这一瓶颈的解决方
案就是：假设取出一条消息的操作相对于处理消息的消耗可以忽略不计，那么对于多次
调用且仅有两三行响应逻辑的消息，编程人员通过函数调用就可以直接执行。
　　前面比较详细地阐述了多任务系统中任务的划分以及执行等内容。虽然这些是一个系
统的核心，但是在一个实用的系统中，还需要任务间的同步、互斥等机制。在上述框架内，
互斥可以简单地用 Java 的 Synchronized 机制实现。由于任务可以主动让出执行权限，
要实现等待(Wait 任务中止)和通知(Notify 任务继续)，从而实现任务同步也就比较容易
了。