问题场景示例

    某个特殊的客户遇到了以下问题，导致一切变得异常糟糕：

    某个网络路由器出现了问题，导致 WebSphere Application Server 服务区域的很多工作线程阻塞。
    工作请求进入队列，等待工作线程。
    工作负载管理系统判断 the WebSphere Application Server 服务区域已挂起，发出了 EC3 abend 来终止服务进程。
    EC3 abend 导致正在处理的事务回滚。 服务器服务速率缓慢再加上事务回滚的影响，导致其他 WebSphere
    Application Server 服务区域回滚。

    此影响将对很多其他服务和子系统重复，从而导致停机。

    
    图 7. 阻塞线程的连锁效应

    阻塞工作线程和不当的服务部署与分配可能会极大地降低中间件基础架构的总体性能。这可通过从 J2EE 和 CORBA 领域获得的非常好的实践予以解决。这些非常好的实践包括并列配置相互连接的应用程序模块，并尽可能减少有些分布式域中的远程调用数量。实际上，相同进程（例如 Java Virtual Machine [JVM] 或寻址空间）中并列执行的服务可以通过优化加以改进，例如按引用传递值、在当前执行线程上执行，以及避免对网络堆栈进行遍历。远程访问服务可能至少会导致随后发生过载。

    服务使用者必须：

    对请求参数进行序列化。
    遍历网络堆栈，以寻找出站调用。
    如果安全策略要求，则对请求进行加密。
    阻塞工作线程并等待响应。
    遍历网络堆栈，以处理返回值。
    如果安全策略要求，则对请求进行解密。
    对返回值进行反序列化。
    恢复阻塞工作线程。

    服务提供者必须：

    遍历网络堆栈，以接受入站请求。
    如果安全策略要求，则对请求进行解密。
    对请求参数进行反序列化。
    将请求分配给新工作线程。
    对返回值进行序列化。
    如果安全策略要求，则对请求进行加密。
    遍历网络堆栈，以发送返回值。

    图 8 给出了基于实际客户部署的场景。对于此客户，多个组件在单个全局事务范围内进行大量的交互。在此场景中，系统不仅可能会在任意时间存在大量阻塞工作线程，而且还表现出性能低效，且会产生较高的每秒百万条指令（Mmillions-of-Instructions-Per-Second，MIPS）成本。

    让我们对图 8 进行一下详细分析，以便您了解应该如何解释此图：

    组件 1 通过 Remote Method Invocation over Internet InterORB Protocol (RMI/IIOP) 调用组件 2。组件 1 阻塞并等待组件 2 响应。
    组件 2 然后通过 RMI/IIOP 调用组件 3。组件 2 等待组件 3 响应。组件 2 和组件 1 现在都被阻塞。
    组件 3 响应组件 2。
    组件 2 响应组件 1，事务完成。