Spring 有状态bean 无状态bean

https://blog.csdn.net/anyoneking/article/details/5182164

在Spring的Bean配置中，存在这样两种情况：

 

[xhtml] view plain copy

1. <bean id="testManager" class="com.sw.TestManagerImpl" scope="singleton" />  
2.   
3.  <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

 

 

[java] view plain copy

1. package com.sw;  
2.   
3. public class TestManagerImpl implements TestManager{  
4.     private User user;    
5.   
6.     public void deleteUser(User e) throws Exception {  
7.         user = e ;           //1  
8.         prepareData(e);  
9.     }  
10.   
11.     public void prepareData(User e) throws Exception {  
12.         user = getUserByID(e.getId());            //2  
13.         .....  
14.         //使用user.getId();                       //3  
15.         .....  
16.         .....  
17.     }     
18. }  

 

 

如果该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的对象。

 

而如果是prototype的话，就不会出现资源共享的问题。

对于SSH来说，Bean的配置是没错的，配置为singleton ;实际应该是这个例子不应该用私有变量。这样就使得这个Bean

由无状态变成了有状态Bean.还是应该尽量使用无状态Bean.如果在程序中出现私有变量，尽量替换为参数。
对于每个访问私有变量的方法增加变量传入或者通过ThreadLocal来获取也是不错的方法。

 

真正出现上面代码问题的也是少数，出现的时候，一般是为了图方便，一个很多方法都要用到的变量，如果都需要用参数的

方式传递多麻烦呀，这样私有变量多好，不用参数那样丑陋。但是丑陋并不代表不好，以对的，自己习惯的方式编程，才能

尽量避免问题的发生。

https://blog.csdn.net/lingxiao301415/article/details/1806503

Session   Bean   主要的目的是让程序开发者将逻辑层抽离；
    Entity   Bean   主要是资料组件，  Entity   Bean   主要的目的，在于提供资料，也就是说程序设计师可以将   Entity   Bean   当程序资料；
     Message   Driven   Bean   与   Session   Bean   或是   Entity   Bean   均不相同，一般   Session   Bean   或是Entity   Bean   都可以让使用者主动触发，但是   Message   Driven Bean   主要的目的在于反应   Message   Queue   中的事件。也就是当   Message   Queue   中有讯息传入时，   Message   Driven   Bean   可以主动被触发，做出相对应的反应。


有状态会话Bean(SLSB)和无状态会话Bean(SFSB)的区别
  1   无状态   (Stateless)    
      在不同方法调用间不保留任何状态   。 
      事务处理必须在一个方法中结束   。 
      通常资源占用较少；可以被共享(因为它是无状态的)  。
      无状态Bean不会"专门"保存客户端的状态----(需要强调“专门”是因为无状态会话Bean也会有成员变量，有成员变量就可以保存状态，但它不会专门为特定的客户端保存状态。)。
      ----你对ENTITY   BEAN的数据操作不会被容器维护，当其他的用户要用ENTITY   BEAN时，里面的数据不
会被钝化到服务器的磁盘上。也就是被保存起来。

  2   有状态   (Stateful)    
      可以在不同的方法调用间保持针对各个客户端的状态   。 
      与客户端的联系必需被维持；通常开销较大  。 
      有状态会话Bean会保存客户端的状态 。
      --你对ENTITY   BEAN的数据操作会被容器维护起来，当其他的用户要用你正在使用的ENTITY   BEAN时，里面的数据会被钝化到服务器的磁盘上，例如网上的购物车。
 

区别的根本原因

这与无状态会话Bean和有状态会话Bean的运行原理是相关的。

对于有状态会话Bean来说，只要有客户端发送对有状态会话Bean的访问，服务器都会创建一个会话Bean实例与该客户端对应，这样这个实例与这个客户端就是一一对应的。如果客户端在Bean实例中保存了信息，之后还可以使用。

对 于无状态会话Bean来说，服务器端会维持一个实例池，创建好若干个实例对象供客户端调用。当从客户端发送创建会话Bean的请求时，并不一定会真的创建 EJB，多数情况下是从实例池中得到一个实例，用完之后重新放回实例池。如果下次再访问，再从实例池中取出一个实例使用，并不一定是上次的实例。即使两次 访问使用的是同一个实例，在两次访问之间也有可能有其他的客户端访问了该实例。所以，并不能保证在多次访问之间的信息会被保存。所以，无状态会话Bean 不会专门保存客户端的信息。

各自的优缺点

因 为有状态会话Bean需要保存特定客户端的信息，一个客户端对应一个实例，既是在当时客户端有连接没有访问的情况下，也要为这个客户端保留这个实例。这样 随着客户端数量的增加，服务器端需要创建的实例的数量也在增加，增加到一次程度对服务器的性能就会有一定的影响。为了不对服务器的性能产生影响，通常服务 器会进行一些优化。当客户端的数量超过某个值之后，就不创建新的实例。虽然不创建新的实例，还是需要对用户响应，这时候就采用共享实例的方式。会查看哪个 实例虽然处于连接状态，但是没有访问，然后把这个实例的状态保存起来，使用这个实例为新的请求服务，对于原来的客户端来说，称为挂起。如果原来的客户端又 发送请求了，会重新查找一个空闲的实例并且把已经保存好的状态恢复回来，这个过程称为激活。所以在有状态会话Bean的访问过程，经常会发生查找实例，激 活挂起等操作，所以效率比较低。

而发送对无状态会话Bean的请求的时候，可以随便取一个空闲的实例为客户端服务，所以效率比较高。

有状态会话Bean的好处是，可以保存客户端的状态，所以客户端在后续访问的时候就可以少传递一些参数。而状态会话Bean需要传递方法执行过程中需要的所有参数。

如何选择

根据上面分析的有状态会话Bean和无状态会话Bean的优缺点。如果要频繁的访问，并且多次访问之间会共享一些信息，这时候应该使用有状态会话Bean。对于不经常使用的功能，可以使用无状态会话Bean。无状态会话Bean的使用要比有状态会话Bean的使用多。

 

 

现实中，很多朋友对两种session bean存在误解，认为有状态是实例一直存在，保存每次调用后的状态，并对下一次调用起作用，而认为无状态是每次调用实例化一次，不保留用户信息。仔细分析并用实践检验后，你会发现，事实恰好相反： 
有状态和无状态会话bean的本质区别是它们的生命期。 
首先解释一个下面要用到的概念－－用户：session bean 的用户实际上就是直接调用ejb的类的实例，甚至是这个实例的某个方法。同一个类的不同实例对于session bean 来说是不同的用户。 
有状态会话bean ：每个用户有自己特有的一个实例，在用户的生存期内，bean保持了用户的信息，即“有状态”；一旦用户灭亡（调用结束或实例结束），bean的生命期也告结束。即每个用户最初都会得到一个初始的bean。 
无状态会话bean ：bean一旦实例化就被加进会话池中，各个用户都可以共用。即使用户已经消亡，bean 的生命期也不一定结束，它可能依然存在于会话池中，供其他用户调用。由于没有特定的用户，那么也就不能保持某一用户的状态，所以叫无状态bean。但无状态会话bean 并非没有状态，如果它有自己的属性（变量），那么这些变量就会受到所有调用它的用户的影响，这是在实际应用中必须注意的。

1.无状态会话Bean 
从字面意思来理解，无状态会话Bean是没有能够标识它的目前状态的属性的Bean。例如：

 public class A {
       public A() {}
       public String hello() {
          return "Hello 谁？";
       }
    }
public class Client {
       public Client() {
          A a = new A();
          System.out.println(a.hello());
          A b = new A();
          System.out.println(b.hello());
       }
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

在Client中生成了两个A的实例，不管是对象a还是b，它们是没有状态的。对于Client来说a和b是没有差别的（但a != b）。所以同一个无状态会话Bean的实例都是相同的，可以被不同的客户端重复使用。

2.状态会话Bean 
至于状态会话Bean，可以这样理解：它是有存储能力的。也就是说至少有一个属性来标识它目前的状态。例如：

public class B {
       private String name;
       public B(String arg) {
       this.name = arg;
       }
       public String hello() {
          return "Hello" + this.name;
       }
    }

    public class Client {
       public Client() {
          B a = new B("中国");
          System.out.println(a.hello());
          B b = new B("世界");
          System.out.println(b.hello());
       }
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

3.调度池： 
其实调度池的概念同数据连接池概念基本相同，都是为了提高系统性能而设计的。就像是饺子馆一样，饺子的做法可以有两种，一种是不管当前有没有客人，先将一些饺子下锅，等到客人来后可以马上捞出来给客人吃。还有一种是客人来后才将饺子下锅。这个例子显然不是十分恰当，但它的确能说明问题。调度池的概念就像是饺子的第一种做法一样，先将一些Bean实例放入池中，（也就是缓存起来，具体缓存多少取决于不同的容器）等到客户端调用时直接可以取来使用。它和饺子的区别还是很大的，要是饺子下锅后没有客人来吃可惨了

4.无状态会话Bean实现调度池调度： 
因为无状态会话Bean是不保存会话状态的，所以无论哪个客户端调用了某个无状态会话Bean，都没有差别，也就是说任何一个无状态会话Bean的实例都可以为客户端程序提供服务。而且无状态会话Bean同客户端的关系是1：n。也就是说，同一个会话Bean实例可以供不同客户端使用。因此无状态会话Bean可以被存储在调度池中，供不同客户端重用。

5.状态会话Bean实现调度池调度： 
因为状态会话Bean是保持当前会话的状态的，所以实现起来远比无状态会话Bean困难。因为它要保存会话状态，但物理内存的空间是有限的，想要保存n多客户端当前会话状态是不可能的。EJB容器采取了同操作系统相同的做法，将状态会话Bean对话状态保存在硬盘或其它存储器中（钝化passivation）。当被钝化的Bean原先的客户端调用其方法时，被钝化的状态重新交还给Bean（激活activation）。也许容器把被钝化的状态交还给不同的Bean实例，那又有什么关系呢？只要这个Bean实例能跟原先钝化之前的那个Bean实例一模一样就行了。事实上它的确一模一样：）大多数容器采用最近最少被使用（Least Recently Used:LRU）的钝化策略。因为客户端是不可能一直在执行操作，他可能在看新闻或其它什么的。所以以这种方式钝化Bean是非常合理有效的。但有一个例外：正在进行事务处理的Bean一定要等到事务处理完毕后才能被钝化。大多数容器采用根据需要被激活（Just-in-time）的策略。客户有请求，ok没问题，激活那个被钝化了的Bean：）注：钝化和激活跟无状态会话Bean没关系。

6.对话状态遵从的规则： 
Bean遵从Java对象序列化规则(Java Object Serialization)。因为javax.ejb.EnterpriseBean接口扩展了java.io.Serializable这个接口，所以每个Enterprise Bean类都间接实现了这个接口。

7.状态会话Bean钝化时保存的内容如下： 
a.EJB对象引用。 
b.Home对象引用。 
d.EJB上下文的引用。 
e.JNDI命名上下文。

8.激活和钝化的回调方法： 
每个会话Bean都实现了SessionBean，所以每个会话Bean都有ejbPassivate()和ejbActivate()方法，EJB容器调用ejbPassivate()方法使Bean释放或处理占用的资源。调用ejbActivate()方法使Bean恢复在ejbPassivate()过程中释放的资源。

 

https://blog.csdn.net/baidu_18820065/article/details/50849692

 

一、Spring单例模式与线程安全

 

 

Spring框架里的bean，或者说组件，获取实例的时候都是默认的单例模式，这是在多线程开发的时候要尤其注意的地方。

 

单例模式的意思就是只有一个实例。单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。

当多用户同时请求一个服务时，容器会给每一个请求分配一个线程，这是多个线程会并发执行该请求多对应的业务逻辑（成员方法），此时就要注意了，如果该处理逻辑中有对该单列状态的修改（体现为该单列的成员属性），则必须考虑线程同步问题

同步机制的比较　　ThreadLocal和线程同步机制相比有什么优势呢？ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。 

　　在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。 

　　而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。 

　　由于ThreadLocal中可以持有任何类型的对象，低版本JDK所提供的get()返回的是Object对象，需要强制类型转换。但JDK 5.0通过泛型很好的解决了这个问题，在一定程度地简化ThreadLocal的使用

　概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。 

　　Spring使用ThreadLocal解决线程安全问题 

　　我们知道在一般情况下，只有无状态的Bean才可以在多线程环境下共享，在Spring中，绝大部分Bean都可以声明为singleton作用域。就是因为Spring对一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非线程安全状态采用ThreadLocal进行处理，让它们也成为线程安全的状态，因为有状态的Bean就可以在多线程中共享了。 

　　一般的Web应用划分为展现层、服务层和持久层三个层次，在不同的层中编写对应的逻辑，下层通过接口向上层开放功能调用。在一般情况下，从接收请求到返回响应所经过的所有程序调用都同属于一个线程

ThreadLocal是解决线程安全问题一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。 

如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。 或者说:一个类或者程序所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性,也就是说我们不用考虑同步的问题。 　线程安全问题都是由全局变量及静态变量引起的。  

若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则就可能影响线程安全。

1） 常量始终是线程安全的，因为只存在读操作。 

2）每次调用方法前都新建一个实例是线程安全的，因为不会访问共享的资源。

3）局部变量是线程安全的。因为每执行一个方法，都会在独立的空间创建局部变量，它不是共享的资源。局部变量包括方法的参数变量和方法内变量。

有状态就是有数据存储功能。有状态对象(Stateful Bean)，就是有实例变量的对象  ，可以保存数据，是非线程安全的。在不同方法调用间不保留任何状态。

无状态就是一次操作，不能保存数据。无状态对象(Stateless Bean)，就是没有实例变量的对象  .不能保存数据，是不变类，是线程安全的。

有状态对象:

无状态的Bean适合用不变模式，技术就是单例模式，这样可以共享实例，提高性能。有状态的Bean，多线程环境下不安全，那么适合用Prototype原型模式。Prototype: 每次对bean的请求都会创建一个新的bean实例。

Struts2默认的实现是Prototype模式。也就是每个请求都新生成一个Action实例，所以不存在线程安全问题。需要注意的是，如果由Spring管理action的生命周期， scope要配成prototype作用域。

 

二、线程安全案例：

SimpleDateFormat(下面简称sdf)类内部有一个Calendar对象引用,它用来储存和这个sdf相关的日期信息,例如sdf.parse(dateStr), sdf.format(date) 诸如此类的方法参数传入的日期相关String, Date等等, 都是交友Calendar引用来储存的.这样就会导致一个问题,如果你的sdf是个static的, 那么多个thread 之间就会共享这个sdf, 同时也是共享这个Calendar引用, 并且, 观察 sdf.parse() 方法,你会发现有如下的调用:

Date parse() {

  calendar.clear(); // 清理calendar

  ... // 执行一些操作, 设置 calendar 的日期什么的

  calendar.getTime(); // 获取calendar的时间

}

这里会导致的问题就是, 如果 线程A 调用了 sdf.parse(), 并且进行了 calendar.clear()后还未执行calendar.getTime()的时候,线程B又调用了sdf.parse(), 这时候线程B也执行了sdf.clear()方法, 这样就导致线程A的的calendar数据被清空了(实际上A,B的同时被清空了). 又或者当 A 执行了calendar.clear() 后被挂起, 这时候B 开始调用sdf.parse()并顺利i结束, 这样 A 的 calendar内存储的的date 变成了后来B设置的calendar的date

这个问题背后隐藏着一个更为重要的问题--无状态：无状态方法的好处之一，就是它在各种环境下，都可以安全的调用。衡量一个方法是否是有状态的，就看它是否改动了其它的东西，比如全局变量，比如实例的字段。format方法在运行过程中改动了SimpleDateFormat的calendar字段，所以，它是有状态的。

　　这也同时提醒我们在开发和设计系统的时候注意下一下三点:

　　1.自己写公用类的时候，要对多线程调用情况下的后果在注释里进行明确说明

　　2.对线程环境下，对每一个共享的可变变量都要注意其线程安全性

　　3.我们的类和方法在做设计的时候，要尽量设计成无状态的

　三.解决办法

　　1.需要的时候创建新实例：

　　说明：在需要用到SimpleDateFormat 的地方新建一个实例，不管什么时候，将有线程安全问题的对象由共享变为局部私有都能避免多线程问题，不过也加重了创建对象的负担。在一般情况下，这样其实对性能影响比不是很明显的。

　　2.使用同步：同步SimpleDateFormat对象

public class DateSyncUtil {

    private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

      

    public static String formatDate(Date date)throws ParseException{

        synchronized(sdf){

            return sdf.format(date);

        }  

    }

    

    public static Date parse(String strDate) throws ParseException{

        synchronized(sdf){

            return sdf.parse(strDate);

        }

    } 

}

　　说明：当线程较多时，当一个线程调用该方法时，其他想要调用此方法的线程就要block，多线程并发量大的时候会对性能有一定的影响。

　　3.使用ThreadLocal：　

public class ConcurrentDateUtil {

    private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>() {

        @Override

        protected DateFormat initialValue() {

            return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        }

    };

    public static Date parse(String dateStr) throws ParseException {

        return threadLocal.get().parse(dateStr);

    }

    public static String format(Date date) {

        return threadLocal.get().format(date);

    }

}

或

public class ThreadLocalDateUtil {

    private static final String date_format = "yyyy-MM-dd HH:mm:ss";

    private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>(); 

 

    public static DateFormat getDateFormat()   

    {  

        DateFormat df = threadLocal.get();  

        if(df==null){  

            df = new SimpleDateFormat(date_format);  

            threadLocal.set(df);  

        }  

        return df;  

    }  

    public static String formatDate(Date date) throws ParseException {

        return getDateFormat().format(date);

    }

    public static Date parse(String strDate) throws ParseException {

        return getDateFormat().parse(strDate);

    }   

}

　　说明：使用ThreadLocal, 也是将共享变量变为独享，线程独享肯定能比方法独享在并发环境中能减少不少创建对象的开销。如果对性能要求比较高的情况下，一般推荐使用这种方法。

　　4.抛弃JDK，使用其他类库中的时间格式化类：

　　1.使用Apache commons 里的FastDateFormat，宣称是既快又线程安全的SimpleDateFormat, 可惜它只能对日期进行format, 不能对日期串进行解析。

　　2.使用Joda-Time类库来处理时间相关问题

　　做一个简单的压力测试，方法一最慢，方法三最快，但是就算是最慢的方法一性能也不差，一般系统方法一和方法二就可以满足，所以说在这个点很难成为你系统的瓶颈所在。从简单的角度来说，建议使用方法一或者方法二，如果在必要的时候，追求那么一点性能提升的话，可以考虑用方法三，用ThreadLocal做缓存。

　　Joda-Time类库对时间处理方式比较完美，建议使用