无状态会话bean :bean一旦实例化就被加进会话池中,各个用户都可以共用。即使用户已经消亡,bean 的生命期也不一定结束,它可能依然存在于会话池中,供其他用户调用。由于没有特定的用户,那么也就不能保持某一用户的状态,所以叫无状态bean。但无状态会话bean 并非没有状态,如果它有自己的属性(变量),那么这些变量就会受到所有调用它的用户的影响,这是在实际应用中必须注意的。
- <bean id="testManager" class="com.sw.TestManagerImpl" scope="singleton" />
- <bean id="testManager" class="com.sw.TestManagerImpl" scope="prototype" />
当然,scope的值不止这两种,还包括了request,session 等。但用的最多的还是singleton单态,prototype多态。
singleton表示该bean全局只有一个实例,Spring中bean的scope默认也是singleton.
prototype表示该bean在每次被注入的时候,都要重新创建一个实例,这种情况适用于有状态的Bean.
对于SSH架构的系统,很少关心这方面,因为我们用到的一般都是singleton. Bean的注入由Spring管理。
对于有状态的Bean呢?
下面是一个有状态的Bean
- package com.sw;
- public class TestManagerImpl implements TestManager{
- private User user;
- public void deleteUser(User e) throws Exception {
- user = e ; //1
- prepareData(e);
- }
- public void prepareData(User e) throws Exception {
- user = getUserByID(e.getId()); //2
- .....
- //使用user.getId(); //3
- .....
- .....
- }
- }
如果该Bean配置为singleton,会出现什么样的状况呢?
如果有2个用户访问,都调用到了该Bean.
假定为user1,user2
当user1 调用到程序中的1步骤的时候,该Bean的私有变量user被付值为user1
当user1的程序走到2步骤的时候,该Bean的私有变量user被重新付值为user1_create
理想的状况,当user1走到3步骤的时候,私有变量user应该为user1_create;
但如果在user1调用到3步骤之前,user2开始运行到了1步骤了,由于单态的资源共享,则私有变量user被修改为user2
这种情况下,user1的步骤3用到的user.getId()实际用到是user2的对象。(我的理解是配置成singleton会造成资源混乱问题-对于有状态的bean)
而如果是prototype的话,就不会出现资源共享的问题。(即不会出现线程安全的问题)
对于SSH来说,Bean的配置是没错的,配置为singleton ;
实际应该是这个例子不应该用私有变量,这样就使得这个Bean由无状态变成了有状态Bean.
还是应该尽量使用无状态Bean.如果在程序中出现私有变量(该bean会变为有状态的,一旦在其他线程中发生改变,就会产生线程不安全),解决方案就是尽量替换为方法中的参数。
对于每个访问私有变量的方法增加变量传入(参数传入)或者通过ThreadLocal来获取也是不错的方法。(重点解决方案,可以防止多线程带来的不安全问题)
真正出现上面代码问题的也是少数,出现的时候,一般是为了图方便,使用了一个很多方法都要用到的变量(变量在传递过程中发生改变,就会产生多线程不安全问题)。如果变量都需要用参数的方式传递多麻烦呀,这样私有变量多好,不用参数那样丑陋。但是丑陋并不代表不好,以对的,自己习惯的方式编程,才能尽量避免问题的发生。
引申:
Spring中的有状态(Stateful)和无状态(Stateless) (web中的并发通过单例可以避免)
1.通过上面的分析,相信大家已经对有状态和无状态有了一定的理解。无状态的Bean适合用不变模式,技术就是单例模式,这样可以共享实例,提高性能。有状态的Bean,多线程环境下不安全,那么适合用Prototype原型模式(解决多线程问题)。Prototype: 每次对bean的请求都会创建一个新的bean实例。
2.默认情况下,从Spring bean工厂所取得的实例为singleton(scope属性为singleton),容器只存在一个共享的bean实例。
3.理解了两者的关系,那么scope选择的原则就很容易了:有状态的bean都使用prototype作用域,而对无状态的bean则应该使用singleton作用域。
4.如Service层、Dao层用默认singleton就行,虽然Service类也有dao这样的属性,但dao这些类都是没有状态信息的,也就是相当于不变(immutable)类,所以不影响。Struts2中的Action因为会有User、BizEntity这样的实例对象,是有状态信息的,在多线程环境下是不安全的,所以Struts2默认的实现是Prototype模式。在Spring中,Struts2的Action中,scope要配成prototype作用域。
Servlet、Struts中的有状态和无状态:
1.Servlet体系结构是建立在Java多线程机制之上的,它的生命周期是由Web 容器负责的。一个Servlet类在Application中只有一个实例存在,也就是有多个线程在使用这个实例。这是单例模式的应用。无状态的单例是线程安全的,但我们如果在Servlet里用了实例变量(私有变量),那么就变成有状态了,是非线程安全的。如下面的用法就是不安全的,因为user,out都是有状态信息的。
- /**
- * 非线程安全的Servlet。
- * @author Peter Wei
- *
- */
- public class UnSafeServlet HttpServlet{
- User user;
- PrintWriter out;
- public void doGet (HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException{
- //do something...
- }
- }
Out,Request,Response,Session,Config,Page,PageContext是线程安全的,Application在整个系统内被使用,所以不是线程安全的.
2.Struts1也是基于单例模式实现,也就是只有一个Action实例供多线程使用。默认的模式是前台页面数据通过actionForm传入,在action中的excute方法接收,这样action是无状态的,所以一般情况下Strunts1是线程安全的。如果Action中用了实例变量,那么就变成有状态了,同样是非线程安全的。像下面这样就是线程不安全的。
- /**
- * 非线程安全的Struts1示例
- *
- * @author Peter Wei
- *
- */
- public class UnSafeAction1 extends Action {
- // 因为Struts1是单例实现,有状态情况下,对象引用是非线程安全的
- User user;
- public void execute() {
- // do something...
- }
- public User getUser() {
- return user;
- }
- public void setUser(User user) {
- this.user = user;
- }
- }
3.Struts2默认的实现是Prototype模式。也就是每个请求都新生成一个Action实例,所以不存在线程安全问题。需要注意的是,如果由Spring管理action的生命周期, scope要配成prototype作用域。
4.如何解决Servlet和Struts1的线程安全问题,当我们能比较好的理解有状态和无状态的原理,自然很容易得出结论: 不要使用有状态的bean,也就是不要用实例变量(私有变量) 。如果用有状态的bean,就要用prototype模式,每次在注入的时候就重新创建一个bean,在多线程中互不影响。Struts1 user guide里有: Only Use Local Variables - The most important principle that aids in thread-safe coding is to use only local variables, not instance variables , in your Action class.
总结:
Stateless无状态用单例Singleton模式,Stateful有状态就用原型Prototype模式。
Stateful 有状态是多线程编码的天敌,所以在开发中尽量用Stateless无状态,无状态是不变(immutable)模式的应用,有很多优点:不用管线程和同步的问题 ,如果值是不可变的,程序不用担心多个线程改变共享状态,所以可以避免线程竞争的bugs. 因为没有竞争,就不用用locks等机制,所以无状态的不变机制,也可以避免产生死锁现象。