Spring Framework Documentation (5.3.10)
Core | IoC Container, Events, Resources, i18n, Validation, Data Binding, Type Conversion, SpEL, AOP. |
1. The IoC Container
1.1. Introduction to the Spring IoC Container and Beans(Spring IoC容器和bean简介)
1.2. Container Overview (容器概览)
1.5.1. The Singleton Scope (单例作用域)
1.5.2. The Prototype Scope(Prototype作用域)
1.5.3. Singleton Beans with Prototype-bean Dependencies(单例和原型Bean的依赖)
1.5.4. Request, Session, Application, and WebSocket Scopes
1.5.4.1. Initial Web Configuration (初始化Web配置)
1.5.4.4. Application Scope(应用作用域)
1.5.4.5. Scoped Beans as Dependencies (具有作用域的bean作为依赖项)
1.5.4.5.1 Choosing the Type of Proxy to Create(选择待创建代理的类型)
1.5.5.1. Creating a Custom Scope(创建自定义作用域)
1.5.5.2. Using a Custom Scope (使用自定义作用域)
下载此文档精编完整版
No. | 内容 | 下载地址 | 文档内容目录 |
1 | 中英双语精编版 第一部分 | PDF下载 | 内容目录 |
2 | 中英双语精编版 第二部分 | PDF下载 | 内容目录 |
3 | 中文精编版 第一部分 | PDF下载 | 内容目录 |
4 | 中文精编版 第二部分 | PDF下载 | 内容目录 |
更多章节内容,请点击查看: Core Technologies
1.5.2. The Prototype Scope(Prototype作用域)
The non-singleton prototype scope of bean deployment results in the creation of a new bean instance every time a request for that specific bean is made. That is, the bean is injected into another bean or you request it through a getBean()
method call on the container. As a rule, you should use the prototype scope for all stateful beans and the singleton scope for stateless beans.
The following diagram illustrates the Spring prototype scope:
Bean部署的非单例原型作用域(non-singleton prototype scope)导致每次对特定bean发出请求时都创建一个新的bean实例。也就是说,bean被注入到另一个bean中,或者通过容器上的getBean() 方法调用来请求它。通常,所有有状态bean都应该使用prototype作用域,无状态bean应该使用singleton作用域。
下图说明了Springprototype作用域:
(A data access object (DAO) is not typically configured as a prototype, because a typical DAO does not hold any conversational state. It was easier for us to reuse the core of the singleton diagram.)
The following example defines a bean as a prototype in XML:
(数据访问对象(DAO)通常不配置为prototype,因为典型的DAO不包含任何会话状态。我们更容易重用singleton图的核心。)
以下示例将bean定义为XML中的prototype:
<bean id="accountService" class="com.something.DefaultAccountService" scope="prototype"/>
In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean. The container instantiates, configures, and otherwise assembles a prototype object and hands it to the client, with no further record of that prototype instance. Thus, although initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. The client code must clean up prototype-scoped objects and release expensive resources that the prototype beans hold. To get the Spring container to release resources held by prototype-scoped beans, try using a custom bean post-processor, which holds a reference to beans that need to be cleaned up.
与其他作用域(scope)不同,Spring并不管理原型bean(prototype bean)的整个生命周期。容器实例化、配置和以其他方式组装原型(prototype)对象并将其交给客户端,而不再记录该原型实例。因此,尽管对所有对象调用初始化生命周期回调(initialization lifecycle callback)方法,而不考虑作用域,但对于原型(prototype),不会调用配置的销毁生命周期回调(destruction lifecycle callback)。客户端代码必须清理原型作用域的对象(prototype-scoped object),并释放原型bean所持有的昂贵资源。要让Spring容器释放原型作用域bean所持有的资源,请尝试使用定制的bean后处理器(bean post-processor),该后处理器持有对需要清理的bean的引用。
In some respects, the Spring container’s role in regard to a prototype-scoped bean is a replacement for the Java new
operator. All lifecycle management past that point must be handled by the client. (For details on the lifecycle of a bean in the Spring container, see Lifecycle Callbacks.)
在某些方面,Spring容器在原型作用域bean(prototype-scoped bean)中的角色是Java new
运算符的替代项。所有超过该点的生命周期管理(lifecycle management)都必须由客户端处理(有关Spring容器中bean生命周期的详细信息,请参阅生命周期回调(Lifecycle Callbacks)。)