公所周知J2EE底层是多线程的，无论何种资源管理的策略都是与线程相关的，因此通过合理的资源管理来应对多线程的环境是非常关键的。下面就我所知道的，总结如下：

第一种：实例池

   实例池管理策略就是通过将我们的业务组件的实例保存到池中，这样可以达到重用的目的。说到实例池，需要明确一下单线程模型的概念，所谓单线程模型就是一个实例在某一时间只能服务于同一个线程，单线程模型使得无状态的业务组件不需要关注复杂的线程问题（通俗点讲，单线程模型使得业务开发人员可以采用不需要显示的同步机制来编写业务组件代码，但是业务组件可以安全的运行与多线程环境之下）。如果采用实例池将有助于实现单线程模型。比如EJB对于无状态的会话bean的管理就采取的是实例池的管理策略，这样以来我们的SLSB中是不需要同步的（这也是为什么EJB组件中不能有显示的同步代码的原因，因为EJB本来就是单线程的模型），从而减轻了业务开发人员的负担。

下面总结一下这种方法的优缺点：

优点：

 1 采用实例池可以使得无状态的业务组件不需要同步，这样就减轻了业务开发人员的负担。

 2. 采用实例池可以限制并发执行的线程的数量，当实例池没有可用的实例可用时，线程就需要挂起，这样防止大的并发对服务器造成的压力。

缺点：

 1 因为采用了实例池，增加了管理实例池的开销，增加了系统的复杂性。

 2 采用实例池还是没有从根本上解决线程的问题，因为虽然实例池的实例不用同步，但是实例池的实例需要其它的组件来协作，这样其它组件的实例还是需要同步的。

具体的应用：

EJB的无状态会话bean，数据库连接池技术，TCP连接技术，web容器和ejb容器的线程池等。

PS：面向模式的软件体系结构-卷3对“实例池”有详细的描述。

第二种：容器管理的单例 

  目前各种IOC容器一般都采取了此种概念，系统只维护一个无状态业务组件的实例。比如目前流行的IOC容器（spring,Picocontainer等)，它们都有将业务组件设置为单例的功能。这样以来减轻了维护实例池的开销，并且通过容器可以管理组件的生命周期，不是像以前那样用完了就丢给垃圾收集器，从而减轻了一些复杂的初始化的开销。

下面是此种方式的优缺点：

 优点：

1. 减轻了一些需要复杂初始化的实例创建开销，从而提高了系统性能。

2. 通过IOC进行了组件的生命周期管理，减低了开发人员的负担。

 缺点：

1 需要我们业务人员确保每个实例是无状态的，如果业务组件是有状态的，那么就要进行显示的同步，而多线程编程不是每个业务开发人员都能胜任的。

2  任意多的线程都可以进行并发调用，这样以来服务器也许无法应对巨大的负载而崩溃。

具体的应用：

目前的Servlet规范就采用一个实例（抛弃了以前的servlet单线程模型）来服务于多线程调用，这样我们必须确保servlet内部的线程安全性。

各种IOC容器（spring,Picocontainer等)

第三种：每个session一个实例

在开发过程中，我们的业务状态如何保存？这就涉及到了业务状态管理的问题，那么我们就可以采取每个session一个实例来进行，比如httpsession，但是在当今的分层架构下，用httpsession来保存业务状态是有缺点的，首先导致了业务状态泄露到了表现层，不利于层的内聚性，并且httpsession中保存的状态太大的话，会造成内存浪费太多。另外还有就是EJB中的statefull session bean，也采取了这种模式，每个有状态的会话bean只为一个客户服务，并且好的一点是statefull session bean支持钝化技术，并且它还支持完整的事务语义，所以它将业务状态的管理和事务结合了起来，这一点是比较好的，唯一不好的地方就是因为EJB是组件，要想运行必须要结合容器才行。

具体的应用：

Web中的httpsession，以及EJB中statefull session bean 

第四种：每个请求一个实例

   每个请求一个实例也是一种比较常用的方式，对于一些初始化不是很复杂的实例，我们就可以采用这种方法。采用这种方式得力与JVM性能的改进，在以前垃圾收集器算法还不成熟的时候，如果采用这种方式将会对系统性能产生很大的影响。但是现在垃圾收集器算法优化已经抵消了一定的开销。比如表现层框架webwork、struts2，它们的xwork内核就是在每个请求过来，都新建一个命令实例（action），目前也没有出现严重的性能问题。

下面总结一下此种方式的优缺点：

优点：

1 因为是每个请求（也就是每个线程）一个实例，那么业务开发人员就不需要对业务对象进行显示的同步，这样减轻了业务开发人员的负担。

缺点：  

1 对于一些需要复杂初始化的实例，这样会给系统性能带来负面的影响。

具体的应用：

Webwork以及struts2的action都采取如此的策略，以及spring框架的prototype方式。

第五种：ThreadLocal策略

此种策略在J2EE中也是比较常用的。它是以线程管理来驱动我们的资源管理的方式，每个线程都独自保存面向自己的变量，这样以来就可以避免多线程访问造成对共享变量的破坏。比如hibernate中，当我们采用JDBC事务的时候，配置hibernate.current_session_context_class=thread,内部就将当前的session与线程绑定，这样以来在同一个线程中操作将是当前绑定的session。还比如webwork中对于ActionContext的管理也采取了Treadlocal的策略，这样以来ActionContext（action的执行上下文）就与当前线程绑定（具体实现是采用一个ActionContext内部类来实现，以前看的源代码，记得不是很清楚了。。），避免多线程访问带来的复杂性。

以上的各种策略看起来是资源管理的策略，但是它们都是与多线程环境有密切关系的，每一种都有自己的优点和缺点，虽然目前框架已经为我们做好了资源管理工作，但是理解它们管理的方式对于业务开发人员还是大有裨益的。以上这些策略也是目前J2EE中常用的，不能确定那个方案比较好，具体的问题具体分析才是上上策。