构建可扩展的Java EE应用（一） - 编程入门网

Figure 1: Throughput in a 4CPU server

传统的阻塞I/O为每个请求分配一个工作线程，这个工作线程负责请求的整个 过程的处理，包括从网络读取请求数据、解析参数、计算或调用其他的业务逻辑 、编码结果并将其返回给请求者，然后这个线程将返回到线程池中供其他线程复 用。Tomcat 5采用的这种方式在应对完美的网络环境、简单的逻辑以及小量的并 发用户时是非常高效的。

但如果请求包括了复杂的逻辑、或需要和外部的系统（例如文件系统、数据库 或消息服务器）进行交互时，工作线程在其处理的大部分时间都会处于等待同步 的调用或网络传输返回的状态中，这个阻塞的线程会被请求持有直到请求处理完 毕，但操作系统需要暂停线程来保证CPU能够处理其他的请求，如果客户端和服务 器端的网络状况不太好的话，网络的延时会导致线程被阻塞更长时间，在更糟的 状况下，当需要keep-alive的话，当前的工作线程会在请求处理完毕后阻塞很长 一段时间，在这样的情况下，为了更好的使用CPU，就必须增加更多的工作线程了 。

Tomcat采用了一个线程池，每个请求都会被线程池中一个空闲的线程进行处理 。"maxThreads"表示Tomcat 能创建的处理请求的最大线程数。如果我们 把"maxThreads"设置的太小的话，就不能充分的使用CPU了，更为重要的是，随着 并发用户的增长，会有很多请求被服务器抛弃和拒绝。在此次测试中，我们 将"maxThreads"设置为了1000（这对于Tomcat来说有些太大了），在这样的设置 下，当并发用户增长到较高数量时，Tomcat会创建很多的线程。大量的Java线程 会导致JVM和OS忙于执行和维护这些线程，而不是执行业务逻辑处理，同时，太多 的线程也会消耗更多的JVM heap内存（每个线程堆栈需要占用一些内存），并且 会导致更为频繁的gc。

Glassfish不需要这么多的线程，在非阻塞IO中，一个工作线程并不会绑定到 一个特定的请求上，如果请求被某些原因所阻塞，那么这个线程将被其他的请求 复用。在这样的方式下，Glassfish可以用几十个工作线程来处理几千的并发用户 。通过限制线程资源，非阻塞IO拥有了更好的可扩展性，这也是Tomcat 6采用非 阻塞IO的原因了。

Figure 2: scalability test result

构建可扩展的Java EE应用（一）(7)

单线程任务问题

几个月前我们实验室测试了一个基于Java EE的ERP系统，它其中的一个测试场 景是为了产生非常复杂的分析报告，我们在不同的服务器上测试了这个应用场景 ，发现竟然是在最便宜的AMD PC服务器上拥有最好的性能。这台AMD的服务器只有 两个2.8HZ的CPU以及4G的内存，但它的性能竟然超过了昂贵的拥有8 CPU和32G内 存的SPARC服务器。

原因就在于这个场景是个单线程的任务，它同时只能被一个用户运行（并发的 多用户执行在这个案例中毫无意义），因此当运行时它只使用了一个CPU，这样的 任务是没法扩展到多个处理器的，在大多数时候，这种场景下的性能仅取决于CPU 的运行速度。

并行是解决这个问题的方案。为了让一个单线程的任务并行执行，你需要按顺 序找出这个操作的过程中从某种程度上来讲不依赖的操作，然后采用多线程从而 实现并行。在上面的案例中，客户重新定义了"分析报告产生"的任务，改为先生 成月度报告，之后基于产生的这些12个月的月度报告来生成分析报告，由于最终 用户并不需要“月度报告”，因此这些“月度报告”只是临时产生的结果，但"月 度报告"是可以并行生成的，然后用于快速的产生最后的分析报告，在这样的方式 下，这个应用场景可以很好的扩展到4 CPU的SPARC服务器上运行，并且在性能上 比在AMD Server高80%多。

重新调整架构和重写代码的解

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!