J2EE常用资源管理方式总结

J2EE底层是多线程的，无论何种资源管理的策略都是与线程相关的，因此通过合理的资源管理来应对多线程的环境是非常关键的。现在总结一下几种J2EE中常见的资源管理方式： 实例池
容器管理的单例
每个请求一个实例
ThreadLocal策略
第一种：实例池
实例池管理策略就是通过将我们的业务组件的实例保存到池中，这样可以达到重用的目的。说到实例池，需要明确一下单线程模型的概念，所谓单线程模型就是一个实例在某一时间只能服务于同一个线程，单线程模型使得无状态的业务组件不需要关注复杂的线程问题（通俗点讲，单线程模型使得业务开发人员可以采用不需要显示的同步机制来编写业务组件代码，但是业务组件可以安全的运行与多线程环境之下）。如果采用实例池将有助于实现单线程模型。比如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等)
第三种：每个请求一个实例

每个请求一个实例也是一种比较常用的方式，对于一些初始化不是很复杂的实例，我们就可以采用这种方法。采用这种方式得力与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中常用的，不能确定那个方案比较好，具体的问题具体分析才是上上策。 实例池就是对象池，对象池在线程安全方面比单例要好些，但是 Java并发线程一书作者反对中小规模的类使用对象池，大类包括复杂系统业务类可以使用Object
Pool，因为OP本身也有开销，另外一定要使用成熟的OP，不能自己编，因为线程安全很重要。
每个请求一个单例会造成大量内存垃圾，特别是并发高情况下，这其实就是OP使用的原因，Struts2等性能不好，特别是高并发，也是这个原因。
ThreadLocal除了框架内部使用，一般不推荐JEE应用使用，不要直接去接触线程。
除了每个请求一个单例，还有Session，一个客户端一个单例。
谈到单例，就一定要注意线程安全，这两者是矛盾的两个方面，为避免线程安全，struts2等就是要请求单例，但是这回引起大量小类的内存开销，这是
FlyWeight模式诞生原因，所以，回避线程安全这条路并不能带来高性能，只有面对线程安全锁，正确处理它，才是高性能的唯一之道。
反过来说，如果能够回避，我们都是由请求单例，都用New，那多美妙简单，何必去研究复杂的锁呢？