Struts2单例引起的问题及解决思考

转自：http://blog.csdn.net/kebikakaxi/article/details/8120365

项目采用了Struts2+Spring的装配方式，Spring管理Struts2的Action自动设置为单例。这样Action的生命周期为服务器生命周期，也就是说不关闭应用服务器，Action一直存在，Action中的属性也一直存在。

这种现象的好处在于，分页对象所需要的数据对象存在于Action中是不被销毁的，直到页面重新对数据对象输入查询条件。

这样做的缺点在于，一，两个浏览器同时操作一个页面，会在查询等条件的保存上产生冲突，致使A浏览器的查询条件影响到B浏览器的查询结果；二，没有良好设计的系统中，重用Action和多次利用Action的时候无法有效甄别数据的有效性。

举个例子，有一个查询分类的Action，实现对分类的查询和定位功能，在人员Action中可能也会用到分类Action，如果单独使用两个Action都是好用的，但是如果先调用了分类的Action，再调用人员Action，因为人员Action中存在基于分类选择后的条件查询，分类Action的查询结果就会直接影响到人员Action的结果。这种结果在逻辑上可以解释的通，但是在客户体验上是很难说得过去的。

因此思考是否可以通过一些办法来解决此类问题。

办法一：设置Action bean的生命周期为Session，即每个浏览器的打开影响着一套Action的生命周期，解决不同用户互相影响的问题；

(通常和spring整合使用的时候，在struts.xml文件要配置一个元素 或者在struts.property文件中配置 struts.objectFactory = spring 。。。可以在spring的配置文件中的bean元素里用一个scope属性来配置action是用什么生命周期，singleton，prototype，request，session等等)

办法二：通过设置过滤器或者拦截器，或者设置类中的单独属性，判断查询条件是否由理想对象传来，如果不是则销毁值对象，如果是则继承值对象的查询条件。

一些关于拦截器的资料：http://blog.csdn.net/feng_sundy/archive/2007/10/11/1820668.aspx

2.Struts2的Action的线程安全问题

背景 :

1) Struts2 默认会对每一个请求,产生一个新的Action的实例来处理.

2) Spring的Ioc容器管理的bean默认是单实例的.

当Struts2与Spring整合后,由Spring来管理Struts2的Action,会遇到什么问题 ?如何解决 ?

---

会遇到什么问题?

Struts2与Spring整合后, 由spring来管理Struts2的Action, bean默认是单实例有情况下,会有如下问题:

1) Struts2的Action是单例,其中的FieldError,actionerror中的错误信息会累加, 即使再次输入了正确的信息,也过不了验证.

2) Struts2的Action是有状态的,他有自己的成员属性, 所以在多线程下,会有线程安全问题，这是最大的问题。

---

如何解决?

方案一: 就是不用单例, spring中bean的作用域设为prototype,每个请求对应一个Action实例.(建议这样做)

方案二: spring中bean的作用域设为session ,每个session对应一个实例,解决了多线程问题.

(如何设置作用域请看: 4 spring中bean的作用域 )再写一个拦截器, 清空 FieldError与actionerror

Java代码 收藏代码

源自网络  

public class ClearFieldErrorInterceptor extends AbstractInterceptor {  

@Override  
public String intercept(ActionInvocation invocation) throws Exception {  
ActionSupport actionSupport = (ActionSupport)invocation.getAction();  
actionSupport.clearErrorsAndMessages();  
String resultCode = invocation.invoke();  
return resultCode;  
}   

---

总结 :

方案一：bean的作用域设为prototype, 不用担心性能不好, 实际测试过,多实例Action性能没问题.

方案二: 有人担心方案一性能不好， 所有才有了方案二, 不知比方案一性能 能高多少？应该不会高多少。

《转》详解Spring中bean的scope singleton prototype request…

‍这里的scope就是用来配置spring bean的作用域，它标识bean的作用域。在spring2.0之前bean只有2种作用域即：singleton(单例)、non-singleton（也称prototype）, Spring2.0以后，增加了session、request、global session三种专用于Web应用程序上下文的Bean。因此，默认情况下Spring2.0现在有五种类型的Bean。当然，Spring2.0对Bean的类型的设计进行了重构，并设计出灵活的Bean类型支持，理论上可以有无数多种类型的Bean，用户可以根据自己的需要，增加新的Bean类型，满足实际应用需求。!

‍1、singleton作用域

‍‍当一个bean的作用域设置为singleton, 那么Spring IOC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。换言之，当把一个bean定义设置为singleton作用域时，Spring IOC容器只会创建该bean定义的唯一实例。这个单一实例会被存储到单例缓存（singleton cache）中，并且所有针对该bean的后续请求和引用都将返回被缓存的对象实例，这里要注意的是singleton作用域和GOF设计模式中的单例是完全不同的，单例设计模式表示一个ClassLoader中只有一个class存在，而这里的singleton则表示一个容器对应一个bean，也就是说当一个bean被标识为singleton时候，spring的IOC容器中只会存在一个该bean。

‍配置实例：
‍
‍或者

‍2、prototype
‍prototype作用域部署的bean，每一次请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）都会产生一个新的bean实例，相当与一个new的操作，对于prototype作用域的bean，有一点非常重要，那就是Spring不能对一个prototype bean的整个生命周期负责，容器在初始化、配置、装饰或者是装配完一个prototype实例后，将它交给客户端，随后就对该prototype实例不闻不问了。不管何种作用域，容器都会调用所有对象的初始化生命周期回调方法，而对prototype而言，任何配置好的析构生命周期回调方法都将不会被调用。清除prototype作用域的对象并释放任何prototype bean所持有的昂贵资源，都是客户端代码的职责。（让Spring容器释放被singleton作用域bean占用资源的一种可行方式是，通过使用bean的后置处理器，该处理器持有要被清除的bean的引用。）

‍3、request

‍request表示该针对每一次HTTP请求都会产生一个新的bean，同时该bean仅在当前HTTP request内有效，配置实例： request、session、global session使用的时候首先要在初始化web的web.xml中做如下配置：如果你使用的是Servlet 2.4及以上的web容器，那么你仅需要在web应用的XML声明文件web.xml中增加下述ContextListener即可:

‍
org.springframework.web.context.request.RequestContextListener

‍4、session

‍session作用域表示该针对每一次HTTP请求都会产生一个新的bean，同时该bean仅在当前HTTP session内有效

‍5、global session
‍global session作用域类似于标准的HTTP Session作用域，不过它仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。如果你在web中使用global session作用域来标识bean，那么web会自动当成session类型来使用

‍6、自定义bean装配作用域在spring2.0中作用域是可以任意扩展的，你可以自定义作用域，甚至你也可以重新定义已有的作用域（但是你不能覆盖singleton和prototype），spring的作用域由接口org.springframework.beans.factory.con**.Scope来定义，自定义自己的作用域只要实现该接口即可

再议singleton与prototype：

‍scope=”prototype”没写的问题,项目中对一个表的增删该操作是用一个action，这个 actionadd,update,delete,save这些方法， 添加和修改是共用一个页面，当页面得到id时代表进行的修改操作，反之是添加操作。因为在配置spring的bean是忘了写 scope=”prototype” 所以每次添加时都显示最后一次访问过的记录,scope=”prototype” 会在该类型的对象被请求 时创建一个新的action对象。如果没有配置scope=prototype则添加的时候不会新建一个action，他任然会保留上次访问的过记录的信息 webwork的Action不是线程安全的，要求在多线程环境下必须是一个线程对应一个独立的实例，不能使用 singleton。所以，我们在Spring配置Webwork Action Bean时，需要加上属性scope=”prototype”或singleton=”false”。
singleton模式指的是对某个对象的完全共享，包括代码空间和数据空间，说白了，如果一个类是singleton的，假如这个类有成员变量，那么这个成员变量的值是各个线程共享的（有点类似于static的样子了），当线程A往给变量赋了一个值以后，线程B就能读出这个值。因此，对于前台Action，肯定不能使用singleton的模式，必须是一个线程请求对应一个独立的实例。推而广之，只要是带数据成员变量的类，为了防止多个线程混用数据，就不能使用singleton。对于我们用到的Service、Dao，之所以用了singleton，就是因为他们没有用到数据成员变量，如果谁的 Service需要数据成员变量，请设置singleton=false。 有状态的bean都使用Prototype作用域，而对无状态的bean则应该使用singleton作用域。

   在 Spring2.0中除了以前的Singleton和Prototype外又加入了三个新的web作用域，分别为request、session和 global session。如果你希望容器里的某个bean拥有其中某种新的web作用域，除了在bean级上配置相应的scope属性，还必须在容器级做一个额外的初始化配置。即在web应用的web.xml中增加这么一个ContextListener： org.springframework.web.context.request.RequestContextListener 以上是针对Servlet 2.4以后的版本。比如Request作用域。