J2EE常用资源管理方式总结。

转载 From http://www.jdon.com/jivejdon/thread/35191
大学四年的生活即将悄然的过去，我也即将踏入社会来真正地历练自己，武装自己，不断努力来实现心存已久的目标。虽然这学期学校开招聘会好多c和c++的（并且貌似做c++的待遇比做java要好），但是我还是毅然的爱着Java,爱着J2EE.爱着开源的精神。好了，闲话不多说了，现在总结一下几种J2EE中常见的资源管理方式：

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等)



第三种：每个请求一个实例
每个请求一个实例也是一种比较常用的方式，对于一些初始化不是很复杂的实例，我们就可以采用这种方法。采用这种方式得力与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中常用的，不能确定那个方案比较好，具体的问题具体分析才是上上策。


很好，这其实就是对象生命周期的基础，只有了解JEE中基本原理，你才知道你的对象该搭哪趟火车。搭错了，后果很严重。

实例池就是对象池，本站以前有不少讨论，你总结得比较全面，对象池在线程安全方面比单例要好些，但是 Java并发线程一书作者反对中小规模的类使用对象池，大类包括复杂系统业务类可以使用Object Pool，因为OP本身也有开销，另外一定要使用成熟的OP，不能自己编，因为线程安全很重要。

每个请求一个单例会造成大量内存垃圾，特别是并发高情况下，这其实就是OP使用的原因，Struts2等性能不好，特别是高并发，也是这个原因。

ThreadLocal除了框架内部使用，一般不推荐JEE应用使用，不要直接去接触线程。

除了每个请求一个单例，还有Session，一个客户端一个单例。

谈到单例，就一定要注意线程安全，这两者是矛盾的两个方面，为避免线程安全，struts2等就是要请求单例，但是这回引起大量小类的内存开销，这是FlyWeight模式诞生原因，所以，回避线程安全这条路并不能带来高性能，只有面对线程安全锁，正确处理它，才是高性能的唯一之道。

反过来说，如果能够回避，我们都是由请求单例，都用New，那多美妙简单，何必去研究复杂的锁呢？

下面赞一下楼主，xmuzyu学习能力很强，作为在校学生，能够掌握OO技术如此深入并有自己的体会，充分说明，在大学本科普及OO设计是有可能的，这比学过分那些算法搞C语言要少走弯路,因为时间有限啊，OO的一套知识不比算法那套简单，你学了这个就没时间学那个了，这个简单道理很多人不明白，还在和我争算法重要性，简直是不可理喻了，其实哪个不重要呢？关键是针对性。除非你有大量闲时间和闲钱，可以都学习。


[该贴被banq于2008-12-08 17:51修改过]


多谢banq老师的肯定和夸奖。我也觉得算法和OO不可能都学好，算法是理论的，要求有很好的数学基础，OO则更加偏向艺术。虽然我数学也不错，但是我还是比较喜欢OO。在学校期间，我只是认真学习了与数据结构相关的算法（比如排序，查找，以及树和图相关的算法），至于其他的算法，我就没仔细去学习了。

不过有得必有失，大学里我都只关注学习J2EE了，.net我不懂，c++学的也不精通，但是我觉得思想是最重要的，至于语言，我想如果思想掌握了，那么站在一个高度去学语言应该很快能学好。比如，服务器端组件模式这本书里面讲的就是思想，你如果掌握了她，就能对EJB有了很好的理解，并且对com+,CORBA也会有一个深层次的认识。

再说一下题外话，很多人都觉得EJB怎么怎么不好，EJB人家本来就是个分布式的组件，既然说是组件，那么组件除了完成业务逻辑外，当然需要容器做环境的，有些人非要把人家拿到容器外面来做对比，还说EJB不好等等的话，我觉得对比没啥意思。要想分布式还是EJB。大家都说spring好，我个人也觉得spring确实好，它的贡献是革命性的（但是EJB的贡献更是革命性的），并且当前ssh架构下，真的不利于DDD，就算是spring也无法对我们的领域模型进行依赖注入，这样容器里跑的还是一些服务和仓库或者是一些pojo facade,我们的domain model还是的自己管理，所以DDD，还是选择ROR和jdon（虽然ROR，jdon我目前正在学习，但是我知道它们是DDD框架，并且ruby支持mixin特性，这样更有利于DDD).

以上只是一个在校本科大4的学生一些不成熟的观点，不对的地方还请各位前辈指点。谢谢。
[该贴被xmuzyu于2008-12-09 00:38修改过]