Servlet 线程池 和 EJB 对象池

Servlet 线程池 和 EJB 对象池


目前所有的B/S系统应用可以分为：有状态(statefull)和无状态(stateless)两大类别。有状态是指在整个系统的处理过程中要保留记住一些信息，而无状态则相反，每次request都是独立的连接，不需要在每个request之间共享数据等等。

对于这两种应用，通常第一考虑是性能要最优，性能是我们选择IT技术的主要依据之一。

为达到最大化的性能，对于Java系统，以前通常的作法是使用对象池，这样节约对象生成时的性能开销，也就是说系统启动时，预先生成一定数目的对象实例在内存中，需要使用时，从对象池中取出实例，用完，归还对象池，对于有状态的应用，可以使用相关持久化（persistence）策略来保存状态。

下一步，如何并行访问对象池将是非常重要，java的多线程技术为我们提供了实现可能，线程的创建销毁也是可能非常耗时的，那么，无疑象使用对象池一样，我们必须使用线程池来实现多线程并行计算的最优化。

使用线程池和对象池，每次客户端请求发生一次就从线程池中借用一个线程，处理完这个请求就将线程返回线程池，同样，使用线程快速的访问对象，对象也是从对象池中借用，用完就还回对象池。 整个这样的架构设计在性能上是最优的。

有了性能保证，安全机制、事务机制、集群(cluster)技术也将是选择IT技术的主要依据。

J2EE就是这样一个实现上述多种考量的综合标准框架系统，在具体使用中，也许我们对所有这些考量的要求并不都一样重视，比如：如果纯粹追求性能是第一，可以忽视事务机制，那么，完整的J2EE技术也许就并不适合你。

那么我们先看看J2EE是如何从性能上保证我们的应用系统以最快速度运行的，也就是说J2EE中必然应该有上述线程池和对象池的实现技术，servlet实际是基于线程池的更好的线程容器；EJB是基于对象池的更好的对象容器。

看看Servler的架构图：


当client1发生请求时servlet容器会从线程池中分配一个线程给这个request.


再看看EJB的架构图：




instance Pool作为一个对象实例池，维持着EJB实例，当然这个对象池是用生命周期的，简单的说 EJB=对象池+远程对象池

但是，EJB还整合了相当的其它增强功能，如安全 事务机制等，这些对于一般应用都是必需的，当然你还必须根据你的需要来选择是否使用J2EE，如果你的应用对安全 事务机制没有要求，直接使用线程池和对象池技术肯定获得最好的性能。

所以，根据Servler和EJB的原理，我们已经可以规划我们的应用，什么可以放在servlet，或什么需要放在EJB中实现：

线程的本质决定了servlet只适合一些轻量的应用，如分析简单XML文档, 通过JDBC访问数据源，使用JMS或JavaMail处理简单的信息Message，或使用JTS/JTA处理简单的事务机制，注意这些用词都是"简单"的，一旦复杂了，就要使用EJB了。

下面从客户端和服务器端两个方面来具体考量这两个技术的使用，这里的客户端不一定是指最终客户端，因为J2EE是多层结构，中间层可能在多个服务器上实现，如果一个服务器上的服务是供另外一个服务器上的应用访问的，那么后者我们也称为客户端。

根据应用的复杂程度和要求不同，分下列情况：

1.在WEB层可以实现的一些应用

如果你的系统没有很复杂的事务处理，或访问很多企业原有的资源，那么可以借助javabean这样的一些Help性质的类来实现你的应用，但是，这样的方案不是最干净clean, 最有效efficient, 或最有扩展性的scalable。

否则，将所有核心计算放置入EJB中。

2.所有的复杂商务计算核心都在EJB中完成

如果你的客户端和服务器端之间有防火墙，那么目前能够无障碍通过防火墙的协议只有Http了(Web Service也是基于http就是这个道理)，既然使用http了，而Servlet是基于Http协议的，那么就需要通过servlet来访问 EJB，这是我们最普遍的应用情况。

但是，如果你的客户端和服务器端可以放置在一个网络内，之间没有防火墙，那么就不必使用Servlet，直接使用Java调用RMI来访问EJB，这样性能是最好的，这时的Servlet大概只有用于控制Jsp的页面的输出了(MVC模式中的控制作用)。

如果是非java客户端，可以通过CORBA组件来访问EJB。

3.如果你的应用对速度要求很高，要求非常快，对于事务处理等方面几乎无要求

直接使用J2SE，加上线程池和对象池技术，将会使你的java系统性能发挥极致。Jakarta.Apache.org有这两种技术的源码，线程池可以从Servlet容器Tomcat的源码中发现。