最全总结SpringBean的作用域管理

一、前言

创建 BeanDefinition 时，就等于创建了一个配方，用于创建由 BeanDefinition 所定义的类实例。BeanDefinition 是配方的这种思想很重要，因为这意味着，与使用类一样，也可通过一个配方创建多个对象实例。

有如下优点：

• 可以控制要插入到从特定 BeanDefinition 创建的对象中的各种依赖项和配置值
• 可以控制从特定 BeanDefinition 创建的对象的作用域。

这种方式功能强大且灵活，因为开发者可以选择通过配置创建的对象的作用域，而不必在Java类级别上考虑对象的范围。

当然了，作为灵活的框架，Spring 还允许开发者创建自定义的作用域。

1.1 详细介绍下 singleton 作用域？

仅管理一个singleton bean的一个共享实例，并且所有对具有ID或与该 BeanDefinition 相匹配的ID的bean的请求都将导致该特定的bean实例由Spring容器返回。

换言之，当我们定义了一个 BeanDefinition 并且其作用域为 singleton 时，IoC容器将为该 BeanDefinition 所定义的对象创建一个实例。该单实例存储在此类单例bean的缓存中，并且对该命名bean的所有后续请求和引用都返回该缓存的对象。

1.2 和单例模式有何联系去区别呢？

Spring的 singleton bean概念与传说中的四人帮创建的《Gang of Four (GoF) patterns》一书中定义的单例模式并不一样。

• GoF的单例模式会硬编码对象的作用域，使得每个类加载器只能创建一个特定类的唯一实例
• 因此，最恰当的应该将Spring单例的作用域描述为一个容器对应一个bean。若我们在单个Spring容器中为特定类定义一个bean，则Spring容器将创建该 BeanDefinition 所定义的类的一个且只有一个实例。

单例作用域是Spring中的默认作用域。要将bean定义为XML中的单例，可以定义bean，如以下示例所示：

1.3 Prototype作用域

Bean部署的非单一原型作用域会在每次请求特定bean时创建一个新bean实例。也就是说，该Bean被注入到另一个Bean中，或者您可以通过容器上的getBean（）方法调用来请求它。通常，应将原型作用域用于所有有状态Bean，将单例作用域用于无状态Bean。

在 Spring 中，那些组成应用程序的主体及由 Spring IOC 容器所管理的对象，被称之为 bean。
简单地讲，bean 就是由 IOC 容器初始化、装配及管理的对象，除此之外，bean 就与应用程序中的其他对象没有什么区别了。
而 bean 的定义以及 bean 相互间的依赖关系将通过配置元数据来描述。

Spring中的bean默认都是单例的，这些单例Bean在多线程程序下如何保证线程安全呢？

例如对于Web应用来说，Web容器对于每个用户请求都创建一个单独的Sevlet线程来处理请求，引入Spring框架之后，每个Action都是单例的，那么对于Spring托管的单例Service Bean，如何保证其安全呢？

Spring的单例是基于BeanFactory也就是Spring容器的，单例Bean在此容器内只有一个Java的单例是基于 JVM，每个 JVM 内只有一个实例

二、bean的作用域

创建一个bean定义，其实质是用该bean定义对应的类来创建真正实例的“配方”。
把bean定义看成一个配方很有意义，它与class很类似，只根据一张“处方”就可以创建多个实例。
不仅可以控制注入到对象中的各种依赖和配置值，还可以控制该对象的作用域。
这样可以灵活选择所建对象的作用域，而不必在Java Class级定义作用域。

Spring Framework支持五种作用域，分别阐述如下表。

五种作用域中，request、session 和 global session 三种作用域仅在基于web的应用中使用（不必关心你所采用的是什么web应用框架），只能用在基于 web 的 Spring ApplicationContext 环境。

三、singleton —— 唯一 bean 实例

当一个 bean 的作用域为 singleton，那么Spring IoC容器中只会存在一个共享的 bean 实例，并且所有对 bean 的请求，只要 id 与该 bean 定义相匹配，则只会返回bean的同一实例。

singleton 是单例类型(对应于单例模式)，就是在创建起容器时就同时自动创建了一个bean的对象，不管你是否使用，但我们可以指定Bean节点的 lazy-init=”true” 来延迟初始化bean，这时候，只有在第一次获取bean时才会初始化bean，即第一次请求该bean时才初始化。

每次获取到的对象都是同一个对象。注意，singleton 作用域是Spring中的缺省作用域。要在XML中将 bean 定义成 singleton ，可以这样配置：

<bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" scope="singleton">

也可以通过 @Scope 注解（它可以显示指定bean的作用范围。）的方式

@Service
@Scope("singleton")
public class ServiceImpl{

}

四、prototype——每次请求都会创建一个新的 bean 实例

当一个bean的作用域为 prototype，表示一个 bean 定义对应多个对象实例。

prototype 作用域的 bean 会导致在每次对该 bean 请求（将其注入到另一个 bean 中，或者以程序的方式调用容器的 getBean() 方法）时都会创建一个新的 bean 实例。prototype 是原型类型，它在我们创建容器的时候并没有实例化，而是当我们获取bean的时候才会去创建一个对象，而且我们每次获取到的对象都不是同一个对象。

对有状态的 bean 应该使用 prototype 作用域，而对无状态的 bean 则应该使用 singleton 作用域。

在 XML 中将 bean 定义成 prototype

<bean id="account" class="com.foo.DefaultAccount" scope="prototype"/>
 或者
<bean id="account" class="com.foo.DefaultAccount" singleton="false"/>

通过 @Scope 注解的方式实现就不做演示了。

五、request——每一次HTTP请求都会产生一个新的bean

该bean仅在当前HTTP request内有效

request只适用于Web程序，每一次 HTTP 请求都会产生一个新的bean，同时该bean仅在当前HTTP request内有效，当请求结束后，该对象的生命周期即告结束。
在 XML 中将 bean 定义成 request ，可以这样配置：

<bean id="loginAction" class=cn.csdn.LoginAction" scope="request"/>

六、session——每一次HTTP请求都会产生一个新的 bean

该bean仅在当前 HTTP session 内有效。

session只适用于Web程序，session 作用域表示该针对每一次 HTTP 请求都会产生一个新的 bean，同时该 bean 仅在当前 HTTP session 内有效.与request作用域一样，可以根据需要放心的更改所创建实例的内部状态，而别的 HTTP session 中根据 userPreferences 创建的实例，将不会看到这些特定于某个 HTTP session 的状态变化。当HTTP session最终被废弃的时候，在该HTTP session作用域内的bean也会被废弃掉。

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

七、globalSession

global session 作用域类似于标准的 HTTP session 作用域，不过仅仅在基于 portlet 的 web 应用中才有意义。Portlet 规范定义了全局 Session 的概念，它被所有构成某个 portlet web 应用的各种不同的 portle t所共享。在global session 作用域中定义的 bean 被限定于全局portlet Session的生命周期范围内。

<bean id="user" class="com.foo.Preferences "scope="globalSession"/>

Spring框架支持5种作用域，有三种作用域是当开发者使用基于web的ApplicationContext的时候才生效的

下面就是Spring内置支持的作用域

作用域	描述
单例(singleton)	（默认）每一个Spring IoC容器都拥有唯一的一个实例对象
原型(prototype)	一个Bean定义可以创建任意多个实例对象
请求（request）	一个HTTP请求会产生一个Bean对象，也就是说，每一个HTTP请求都有自己的Bean实例。只在基于web的Spring ApplicationContext中可用
会话（session）	限定一个Bean的作用域为HTTPsession的生命周期。同样，只有基于web的Spring ApplicationContext才能使用
全局会话(global session）	限定一个Bean的作用域为全局HTTPSession的生命周期。通常用于门户网站场景，同样，只有基于web的Spring ApplicationContext可用
应用(application)	限定一个Bean的作用域为ServletContext的生命周期。同样，只有基于web的Spring ApplicationContext可用

在Spring 3.0中，线程作用域是可用的，但不是默认注册的

7.1 singleton

全局只有一个共享的实例,所有将单例Bean作为依赖的情况下,容器返回将是同一个实例

换言之，当开发者定义一个Bean的作用域为单例时，Spring IoC容器只会根据Bean定义来创建该Bean的唯一实例。这些唯一的实例会缓存到容器中，后续针对单例Bean的请求和引用，都会从这个缓存中拿到这个唯一的实例

7.2 单例Bean和单例模式

• 单例模式是将一个对象的作用域硬编码，一个ClassLoader只有唯一的一个实例
• 而Spring的单例作用域，是基于每个容器，每个Bean只有一个实例
  这意味着，如果开发者根据一个类定义了一个Bean在单个的Spring容器中，那么Spring容器会根据Bean定义创建一个唯一的Bean实例。默认情况下，它们为每个给定的org.springframework.context.ApplicationContext实例存在唯一的一个bean (有点别扭，也就是可以有多个Spring容器，每一个容器内存在唯一bean实例).这意味着如果你有两个或更多上下文，所有这些上下文都由同一Java的类加载器管理(因为在同一个jvm环境中)，则可能会有多个给定bean的实例。唯一需要做到的是必须在每个上下文中定义此bean.

所以你可以看到，bean只是一个上下文的单例
你不应该将Spring的单例概念与设计模式中的的单例混淆

单例作用域是Spring的默认作用域，下面的例子是在基于XML的配置中配置单例模式的Bean。

<bean id="accountService" class="com.sss.DefaultAccountService"/>

<!-- the following is equivalent, though redundant (singleton scope is the default) -->
<bean id="accountService" class="com.sss.DefaultAccountService" scope="singleton"/>

八、prototype

每次请求Bean实例时，返回的都是新实例的Bean对象
也就是说，每次注入到另外的Bean或者通过调用getBean()来获得的Bean都将是全新的实例。
这是基于线程安全性：

• 有状态的Bean对象用prototype作用域
• 无状态的Bean对象用singleton 作用域

下面的例子说明了Spring的原型作用域。DAO通常不会配置为原型对象，因为典型的DAO是不会有任何的状态的。

下面的例子展示了XML中如何定义一个原型的Bean：

<bean id="accountService"
	class="com.javaedge.DefaultAccountService" scope="prototype"/>

与其他的作用域相比，Spring不会完全管理原型Bean的生命周期：
Spring容器只会初始化配置以及装载这些Bean，传递给Client。
但是之后就不会再去管原型Bean之后的动作了。

也就是说，初始化生命周期回调方法在所有作用域的Bean是都会调用的，但是销毁生命周期回调方法在原型Bean是不会调用的

所以，客户端代码必须注意清理原型Bean以及释放原型Bean所持有的一些资源。
可以通过使用自定义的bean post-processor来让Spring释放掉原型Bean所持有的资源。

在某些方面来说，Spring容器的角色就是取代了Java的new操作符，所有的生命周期的控制需要由客户端来处理。

Singleton beans with prototype-bean dependencies 在原型bean中放置单例

如果注入的单例对象真的是一个单例的bean(没有状态)，这个真的没一点问题
想象一下，对于我们的购物车，我们需要注入产品服务。此服务只会检查添加到购物车的产品是否库存。由于服务没有状态，并且会基于在方法签名中所传递的对象进行验证，因此不存在风险

当使用单例Bean的时候，而该单例Bean的依赖是原型Bean时，需要注意的是依赖的解析都是在初始化的阶段
因此，如果将原型Bean注入到单例的Bean之中，只会请求一次原型Bean，然后注入到单例Bean中。这个依赖的原型Bean仍然属于只有一个实例的。

然而，假设你需要单例Bean对原型的Bean的依赖
需要每次在运行时都请求一个新的实例，那么你就不能够将一个原型的Bean来注入到一个单例的Bean当中了，因为依赖注入只会进行一次
当Spring容器在实例化单例Bean的时候，就会解析以及注入它所需的依赖
如果实在需要每次都请求一个新的实例，可以通过bean工厂手动获取实例,也可以参考Dependencies中的方法注入部分。

##使用单例还是原型？

Singleton适用于无状态的bean,比如一个service，DAO或者controller
他们都没有自己的状态(举个简单的例子，一个函数sin(x)，这个函数本身就是无状态的，所以我们现在喜欢的函数式编程也遵循这个理念)。而是根据传输的参数执行一些操作(作为HTTP请求参数)。

另一方面，我们可以通过状态bean管理一些状态。比如购物车bean，假如它是一个单例，那么两个不同消费者购买的产品将被放置在同一个对象上。而如果其中一个消费者想要删除一个产品，另一个消费者就铁定不高兴。这也就是状态类对象应该是原型
#3. Request
Spring容器会在每次用到loginAction来处理每个HTTP请求的时候都会创建一个新的LoginAction实例。也就是说，loginActionBean的作用域是HTTPRequest级别的。 开发者可以随意改变实例的状态，因为其他通过loginAction请求来创建的实例根本看不到开发者改变的实例状态，所有创建的Bean实例都是根据独立的请求来的。当请求处理完毕，这个Bean也会销毁。

每个请求初始化具有此作用域的Bean注解。这听起来像是原型作用域的描述，但它们有一些差异。

• 原型作用域在Spring的上下文中可用。而请求作用域仅适用于Web应用程序
• 原型bean根据需求进行初始化，而请求bean是在每个请求下构建的

需要说的是，request作用域bean在其作用域内有且仅有一个实例。而你可以拥有一个或多个原型作用域bean实例

在以下代码中，你可以看到请求作用域bean的示例：

<bean id="shoppingCartRequest" class="com.sss.scope.ShoppingCartRequest" scope="request">
    <aop:scoped-proxy/>
</bean>

当使用注解驱动组件或Java Config时，@RequestScope注解可以用于将一个组件分配给request作用域。

@RequestScope
@Component
public class ShoppingCartRequest {
	// ...
}
// request bean

// injection sample
@Controller
public class TestController {
    @Autowired
    private ShoppingCartRequest shoppingCartRequest;

    @RequestMapping(value = "/test", method = RequestMethod.GET)
    public String test(HttpServletRequest request) {
        LOGGER.debug("shoppingCartRequest is :"+shoppingCartRequest);
        // ...
    }
}

请注意定义内存在的<aop: scoped-proxy />标签。这代表着使用代理对象。所以实际上，TestController持有的是代理对象的引用。我们所有的调用该对象都会转发到真正的ShoppingCartRequest对象。

有时我们需要使用DispatcherServlet的另一个servlet来处理请求。在这种情况下，我们必须确保Spring中所有请求都可用(否则可以抛出与下面类似的异常)。为此，我们需要在web.xml中定义一个监听器:

<listener>
  <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>

调用/测试URL后，你应该能在日志中的发现以下信息:

shoppingCartRequest is :com.migo.scope.ShoppingCartRequest@2586b11c
shoppingCartRequest is :com.migo.scope.ShoppingCartRequest@3bd5b945

如果我们尝试在单例bean中使用request作用域的bean，则会在应用程序上下文加载阶段抛出一个BeanCreationException
#4. session
参考如下的Bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

Spring容器会在每次调用到userPreferences在一个单独的HTTP会话周期来创建一个新的UserPreferences实例。换言之，userPreferencesBean的作用域是HTTPSession级别的。 在request-scoped作用域的Bean上，开发者可以随意的更改实例的状态，同样，其他的HTTPSession基本的实例在每个Session都会请求userPreferences来创建新的实例，所以开发者更改Bean的状态，对于其他的Bean仍然是不可见的。当HTTPSession销毁了，那么根据这个Session来创建的Bean也就销毁了。

Session作用域的bean与request 作用域的bean没有太大不同。它们也与纯Web应用程序上下文相关联。注解为Session作用域的Bean对于每个用户的会话仅创建一次。他们在会话结束时被破坏销毁掉。

由Session作用域限制的Bean可以被认为是面向Web的单例，因为给定环境(用户会话)仅存在一个实例。但请记住，你无法在Web应用程序上下文中使用它们(说个好理解点的，就是一个函数内部自定义变量所在的作用域，函数执行完就销毁了，没有什么逃逸)。

想知道Session作用域bean在Spring中的操作，我们需要在配置文件中定义一个bean:

<bean id="shoppingCartRequest" class="com.migo.scope.ShoppingCartSession" scope="session">

    <aop:scoped-proxy/> 

</bean>

通过@Autowired注解，查找这个bean的方式与request 作用域的bean相同。可以看到以下结果:
你可以看到，前5个打印输出代表相同的对象。最后一个是不同的。这是什么意思 ?简单来说，这代表 着一个新的用户使用自动注入的Session作用域访问该页面。我们可以通过打开两个浏览器的测试页(/test)来观察它。每个都将初始化一个新的会话Session，因此也就创建新的ShoppingCartSession bean实例。
#5. global session

该部分主要是描述portlet的，详情可以Google更多关于portlet的相关信息。

参考如下的Bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="globalSession"/>

global session作用域比较类似之前提到的标准的HTTPSession，这种作用域是只应用于基于门户（portlet-based）的web应用的上下之中的。门户的Spec中定义的global session的意义：global session被所有构成门户的web应用所共享。定义为global session作用域的Bean是作用在全局门户Session的声明周期的。

如果在使用标准的基于Servlet的Web应用，而且定义了global session作用域的Bean，那么只是会使用标准的HTTPSession作用域，不会报错。

关于全局会话作用域(Global session scope)属于4.3x的范畴了，Spring5已经没有了，Spring5文档是去掉了因为4的存在所以还是说两句，它保留给portlet应用程序。 是不是一脸懵逼，so，来解释一下portlet是什么。Portlet是能够生成语义代码(例如：HTML)片段的小型Java Web插件。它们基于portlet容器，可以像servlet一样处理HTTP请求。但是，与servlet不同，每个portlet都有不同的会话。在这种情况下，Spring提供了一个名为global-session的作用域。通过它，一个bean可以通过应用程序中的多个portlet共享。

至此，我们解释了请求和面向会话的作用域。第一个的作用是在每个request请求上创建新的bean。第二个在Session会话开始的时候初始化bean。

到此这篇关于最全总结SpringBean的作用域管理的文章就介绍到这了,更多相关SpringBean的作用域管理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！