文章目录

一、Lifecycle Callbacks (生命周期回调函数)
- 1、Initialization Callbacks（初始化回调）
- 2、Destruction Callbacks（销毁回调）
- 3、Default Initialization and Destroy Methods（默认的初始化和销毁方法）
- 4、Combining Lifecycle Mechanisms（结合使用生命周期机制）
- 5、Startup and Shutdown Callbacks（启动和关闭回调）
- 6、Shutting Down the Spring IoC Container Gracefully in Non-Web Applications（在非 Web 应用程序中优雅地关闭 Spring IoC 容器）
二、ApplicationContextAware and BeanNameAware
三、Bean Definition Inheritance（Bean定义的继承）

生词汇总：

former ----------------------------------- 前任的, 原有的, 旧的
dispose ------------------------------------- 处置
consistency ------------------------------ 一致性
accordance -------------------------------- 根据，和谐, 匹配
resemble -------------------------------- 类似，像，相似
cascade --------------------------------- 级联, 小瀑布
delegate -------------------------------- 代表, 委派
spectrum ------------------------------ 光谱、范围
suffice ---------------------------------- 满足、合格
The latter ------------------------------- 后者
manipulate ------------------------------- 操作, 操纵, 摆布

一、Lifecycle Callbacks (生命周期回调函数)

To interact with the container’s management of the bean lifecycle, you can implement the Spring InitializingBean and DisposableBean interfaces. The container calls afterPropertiesSet() for the former and destroy() for the latter to let the bean perform certain actions upon initialization and destruction of your beans.

为了与容器的生命周期管理进行交互，你可以实现spring的InitializingBean 和DisposableBean 接口，容器会在bean初始化时调用前者的afterPropertiesSet()方法，在bean销毁时调用后者的destroy()方法。

The JSR-250 @PostConstruct and @PreDestroy annotations are generally considered best practice for receiving lifecycle callbacks in a modern Spring application. Using these annotations means that your beans are not coupled to Spring-specific interfaces.

JSR-250 @PostConstruct 和 @PreDestroy 注解通常被认为是在现代 Spring 应用程序中接收生命周期回调的最佳实践。使用这些注解意味着你的 bean 不会耦合到 Spring 特定的接口。

Internally, the Spring Framework uses BeanPostProcessor implementations to process any callback interfaces it can find and call the appropriate methods. If you need custom features or other lifecycle behavior Spring does not by default offer, you can implement a BeanPostProcessor yourself.

在内部，Spring 框架使用 BeanPostProcessor 实现来处理它可以找到的任何回调接口并调用适当的方法。如果你需要自定义功能或 Spring 默认不提供的其他生命周期行为，可以自己实现 BeanPostProcessor。

In addition to the initialization and destruction callbacks, Spring-managed objects may also implement the Lifecycle interface so that those objects can participate in the startup and shutdown process, as driven by the container’s own lifecycle.

除了初始化和销毁回调之外，Spring 管理的对象还可以实现 Lifecycle 接口，以便这些对象可以参与启动和关闭过程，由容器自身的生命周期驱动。

1、Initialization Callbacks（初始化回调）

The org.springframework.beans.factory.InitializingBean interface lets a bean perform initialization work after the container has set all necessary properties on the bean. The InitializingBean interface specifies a single method:

org.springframework.beans.factory.InitializingBean 接口在容器为bean 设置所有必要的属性后执行初始化工作。 InitializingBean 接口指定了一个方法：

void afterPropertiesSet() throws Exception;

We recommend that you do not use the InitializingBean interface, because it unnecessarily couples the code to Spring. Alternatively, we suggest using the @PostConstruct annotation or specifying a POJO initialization method. In the case of XML-based configuration metadata, you can use the init-method attribute to specify the name of the method that has a void no-argument signature. With Java configuration, you can use the initMethod attribute of @Bean.

我们建议你不要使用 InitializingBean 接口，因为它不必要地将代码耦合到 Spring。作为替代，我们建议使用 @PostConstruct 注释或指定 POJO的初始化方法。对于基于 XML 的配置元数据，可以使用 init-method 属性来指定具有 void 无参数签名方法的名称。通过 Java 配置，您可以使用@Bean 的 initMethod 属性。

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

public class ExampleBean {public void init() {// do some initialization work}
}

2、Destruction Callbacks（销毁回调）

Implementing the org.springframework.beans.factory.DisposableBean interface lets a bean get a callback when the container that contains it is destroyed. The DisposableBean interface specifies a single method:

实现 org.springframework.beans.factory.DisposableBean 接口可以让 bean 在包含它的容器被销毁时获得回调。 DisposableBean 接口指定了一个方法：

void destroy() throws Exception;

We recommend that you do not use the DisposableBean callback interface, because it unnecessarily couples the code to Spring. Alternatively, we suggest using the @PreDestroy annotation or specifying a generic method that is supported by bean definitions. With XML-based configuration metadata, you can use the destroy-method attribute on the . With Java configuration, you can use the destroyMethod attribute of @Bean.

我们建议你不要使用 DisposableBean 回调接口，因为它不必要地将代码耦合到 Spring。作为替代，我们建议你使用@PreDestroy注解或者指定一个普通的方法给bean定义。使用基于 XML 的配置元数据，你可以使用上的 destroy-method 属性。通过 Java 配置，你可以使用 @Bean 的 destroyMethod 属性。

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>

public class ExampleBean {public void cleanup() {// do some destruction work (like releasing pooled connections)}
}

3、Default Initialization and Destroy Methods（默认的初始化和销毁方法）

When you write initialization and destroy method callbacks that do not use the Spring-specific InitializingBean and DisposableBean callback interfaces, you typically write methods with names such as init(), initialize(), dispose(), and so on. Ideally, the names of such lifecycle callback methods are standardized across a project so that all developers use the same method names and ensure consistency.

当你没有使用特定于 Spring 的 InitializingBean 和 DisposableBean 接口进行初始化和销毁方法回调时，通常使用诸如 init()、initialize()、dispose() 等名称编写方法。理想情况下，此类生命周期回调方法的名称在整个项目中是标准化的，以便所有开发人员使用相同的方法名称并确保一致性。

You can configure the Spring container to “look” for named initialization and destroy callback method names on every bean. This means that you, as an application developer, can write your application classes and use an initialization callback called init(), without having to configure an init-method=“init” attribute with each bean definition. The Spring IoC container calls that method when the bean is created (and in accordance with the standard lifecycle callback contract described previously). This feature also enforces a consistent naming convention for initialization and destroy method callbacks.

你可以配置Spring容器去查找在每个bean中命名的初始化和销毁回调方法。这意味着对每一个开发者来说，可以在你的应用类中编写一个名为init()的初始化回调方法，不必在每个bean定义中配置init-method=“init”，spring容器会在bean被创建的时候调用这个方法。此功能还为初始化和销毁回调方法强制执行一致的命名约定。

Suppose that your initialization callback methods are named init() and your destroy callback methods are named destroy(). Your class then resembles the class in the following example:

假设你的初始化回调方法名为 init()，销毁回调方法名为 destroy()。然后，你的类类似于以下示例中的类：

public class DefaultBlogService implements BlogService {private BlogDao blogDao;public void setBlogDao(BlogDao blogDao) {this.blogDao = blogDao;}// this is (unsurprisingly) the initialization callback methodpublic void init() {if (this.blogDao == null) {throw new IllegalStateException("The [blogDao] property must be set.");}}
}

You could then use that class in a bean resembling the following:

你可以在XML中像以下示列使用该类：

<beans default-init-method="init"><bean id="blogService" class="com.something.DefaultBlogService"><property name="blogDao" ref="blogDao" /></bean></beans>

The presence of the default-init-method attribute on the top-level <beans/> element attribute causes the Spring IoC container to recognize a method called init on the bean class as the initialization method callback. When a bean is created and assembled, if the bean class has such a method, it is invoked at the appropriate time.
You can configure destroy method callbacks similarly (in XML, that is) by using the default-destroy-method attribute on the top-level element.

顶级 <beans/> 元素属性上存在的 default-init-method 属性会导致 Spring IoC 容器将 bean 类上名为 init 的方法识别为初始化回调方法。在创建和组装 bean 时，如果 bean 类具有这样的方法，则会在适当的时间调用它。你可以通过使用顶级\ 元素上的 default-destroy-method 属性类似地（即在 XML 中）配置销毁方法回调。

4、Combining Lifecycle Mechanisms（结合使用生命周期机制）

Multiple lifecycle mechanisms configured for the same bean, with different initialization methods, are called as follows:

为同一个 bean 配置的多个生命周期机制，具有不同的初始化方法，调用顺序如下：

Methods annotated with @PostConstruct
afterPropertiesSet() as defined by the InitializingBean callback interface
A custom configured init() method

Destroy methods are called in the same order:

Methods annotated with @PreDestroy
destroy() as defined by the DisposableBean callback interface
A custom configured destroy() method

5、Startup and Shutdown Callbacks（启动和关闭回调）

The Lifecycle interface defines the essential methods for any object that has its own lifecycle requirements (such as starting and stopping some background process):

Lifecycle 接口为任何具有自己生命周期要求的对象定义了基本方法(例如启动和停止时做一些背后的处理)：

public interface Lifecycle {void start();void stop();boolean isRunning();
}

Any Spring-managed object may implement the Lifecycle interface. Then, when the ApplicationContext itself receives start and stop signals (for example, for a stop/restart scenario at runtime), it cascades those calls to all Lifecycle implementations defined within that context. It does this by delegating to a LifecycleProcessor, shown in the following listing:

任何交由Spring管理的对象都可以实现该Lifecycle接口。如此一来，当ApplicationContext接收到启动和停止信号，它将级联调用这些定义到该上下文中的所有生命周期实现。它通过委托给 LifecycleProcessor 来做到这一点，如下面的列表所示：

public interface LifecycleProcessor extends Lifecycle {void onRefresh();void onClose();
}

Notice that the LifecycleProcessor is itself an extension of the Lifecycle interface. It also adds two other methods for reacting to the context being refreshed and closed.

可以注意到LifecycleProcessor本身继承了Lifecycle接口。它也额外添加了两个方法应对上下文的刷新和关闭。

The order of startup and shutdown invocations can be important. If a “depends-on” relationship exists between any two objects, the dependent side starts after its dependency, and it stops before its dependency. However, at times, the direct dependencies are unknown. You may only know that objects of a certain type should start prior to objects of another type. In those cases, the SmartLifecycle interface defines another option, namely the getPhase() method as defined on its super-interface, Phased. The following listing shows the definition of the Phased interface:

启动和停止调用的顺序是重要的。如果任意两个对象之间存在一个依赖关系，需要依赖的一方在依赖项之后启动，并且在依赖项之前停止。然而，在有些时候，直接依赖项是未知的，你可能只知道某种类型的对象需要在另一种类型的对象之前启动。在这种情况下，SmartLifecycle接口定义了另一种选择，名为getPhase()的方法定义在它的父接口Phase中。下面的代码展示了Phase接口的定义：

public interface Phased {int getPhase();
}

The following listing shows the definition of the SmartLifecycle interface:

public interface SmartLifecycle extends Lifecycle, Phased {boolean isAutoStartup();void stop(Runnable callback);
}

When starting, the objects with the lowest phase start first. When stopping, the reverse order is followed. Therefore, an object that implements SmartLifecycle and whose getPhase() method returns Integer.MIN_VALUE would be among the first to start and the last to stop. At the other end of the spectrum, a phase value of Integer.MAX_VALUE would indicate that the object should be started last and stopped first (likely because it depends on other processes to be running). When considering the phase value, it is also important to know that the default phase for any “normal” Lifecycle object that does not implement SmartLifecycle is 0. Therefore, any negative phase value indicates that an object should start before those standard components (and stop after them). The reverse is true for any positive phase value.

当启动的时候，phase值最低的对象最先启动。当停止的时候，反过来，phase值最大的最先停止。因此，一个实现 SmartLifecycle 并且其 getPhase() 方法返回 Integer.MIN_VALUE 的对象将是最先启动和最后一个停止的对象。对于int范围的最大值来说，Integer.MAX_VALUE 的phase值表示该对象应该最后启动并首先停止（可能是因为它依赖于其他正在运行的进程）。当考虑phase值的时候，知道那些没有实现SmartLifecycle接口的普通类的默认phase值是0也是很重要的。因此，一个越小的phase值表明一个对象越先启动，反之亦然。

The stop method defined by SmartLifecycle accepts a callback. Any implementation must invoke that callback’s run() method after that implementation’s shutdown process is complete. That enables asynchronous shutdown where necessary, since the default implementation of the LifecycleProcessor interface, DefaultLifecycleProcessor, waits up to its timeout value for the group of objects within each phase to invoke that callback. The default per-phase timeout is 30 seconds. You can override the default lifecycle processor instance by defining a bean named lifecycleProcessor within the context. If you want only to modify the timeout, defining the following would suffice:

SmartLifecycle 定义的 stop 方法接受一个Runnable的回调。任何实现都必须在该实现的关闭过程完成后调用该回调的 run() 方法。在必要的地方会启用同步关闭，由于 LifecycleProcessor 接口的默认实现，DefaultLifecycleProcessor，等待每个阶段中的对象组调用该回调的超时值。默认的每阶段超时为 30 秒。你可以通过在上下文中定义一个名为lifecycleProcessor 的 bean 来覆盖默认的生命周期处理器实例。如果你只想修改超时，定义以下内容就足够了：

<bean id="lifecycleProcessor" class="org.springframework.context.support.DefaultLifecycleProcessor"><!-- timeout value in milliseconds --><property name="timeoutPerShutdownPhase" value="10000"/>
</bean>

As mentioned earlier, the LifecycleProcessor interface defines callback methods for the refreshing and closing of the context as well. The latter drives the shutdown process as if stop() had been called explicitly, but it happens when the context is closing. The ‘refresh’ callback, on the other hand, enables another feature of SmartLifecycle beans. When the context is refreshed (after all objects have been instantiated and initialized), that callback is invoked. At that point, the default lifecycle processor checks the boolean value returned by each SmartLifecycle object’s isAutoStartup() method. If true, that object is started at that point rather than waiting for an explicit invocation of the context’s or its own start() method (unlike the context refresh, the context start does not happen automatically for a standard context implementation). The phase value and any “depends-on” relationships determine the startup order as described earlier.

正如前面所提到的，LifecycleProcessor接口定义了上下文刷新和关闭的回调方法。后者驱动关闭过程，就好像 stop() 已被显式调用一样，但它会在上下文关闭时发生。refresh回调，换句话说，启用 SmartLifecycle bean 的另一个功能。当上下文被刷新（所有对象被实例化和初始化后），该回调方法被执行。在这个时候，默认的生命周期处理器检查每个SmartLifecycle bean的isAutoStartup()方法返回的布尔值，如果为true，该对象在该点启动，而不是等待上下文或其自己的 start() 方法的显式调用（与上下文刷新不同，对于标准上下文实现，上下文启动不会自动发生）。phase值和任何“依赖”关系确定启动顺序，如前所述。

6、Shutting Down the Spring IoC Container Gracefully in Non-Web Applications（在非 Web 应用程序中优雅地关闭 Spring IoC 容器）

If you use Spring’s IoC container in a non-web application environment (for example, in a rich client desktop environment), register a shutdown hook with the JVM. Doing so ensures a graceful shutdown and calls the relevant destroy methods on your singleton beans so that all resources are released. You must still configure and implement these destroy callbacks correctly.To register a shutdown hook, call the registerShutdownHook() method that is declared on the ConfigurableApplicationContext interface, as the following example shows:

如果你在非 Web 应用程序环境（例如，富客户端桌面环境）中使用 Spring 的 IoC 容器，可以向 JVM 注册一个关闭钩子。这样做可确保正常关闭并在单例 bean 上调用相关的 destroy 方法，以便释放所有资源。你仍然必须正确配置和实现这些销毁回调。要注册关闭挂钩，请调用在 ConfigurableApplicationContext 接口上声明的 registerShutdownHook() 方法，如以下示例所示：

import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;public final class Boot {public static void main(final String[] args) throws Exception {ConfigurableApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");// add a shutdown hook for the above context...ctx.registerShutdownHook();// app runs here...// main method exits, hook is called prior to the app shutting down...}
}

二、ApplicationContextAware and BeanNameAware

When an ApplicationContext creates an object instance that implements the org.springframework.context.ApplicationContextAware interface, the instance is provided with a reference to that ApplicationContext. The following listing shows the definition of the ApplicationContextAware interface:

当ApplicationContext创建一个实现了org.springframework.context.ApplicationContextAware接口的实例时，这个实例就被提供了一个关于ApplicationContext的引用，以下代码展示了ApplicationContextAware接口的定义：

public interface ApplicationContextAware {void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}

Thus,beans can programmatically manipulate the ApplicationContext that created them,through the ApplicationContext interface or by casting the reference to a known subclass of this interface(such as ConfigurableApplicationContext,which exposes additional functionality).One use would be the programmatic retrieval of other beans. Sometimes this capability is useful. However, in general, you should avoid it, because it couples the code to Spring and does not follow the Inversion of Control style, where collaborators are provided to beans as properties. Other methods of the ApplicationContext provide access to file resources, publishing application events, and accessing a MessageSource.

因此，bean可以编程式的操作创建它们的ApplicationContext，通过 ApplicationContext 接口或通过将引用转换为该接口的已知子类（例如 ConfigurableApplicationContext，它公开了附加功能）。其中一个用途是编程式的获取其他bean，有时候这个功能很有用。然而，通常情况下，你应该避免这样做，因为这样代码就耦合到了Spring，不符合控制反转的风格，协作者应该以属性的方式依赖注入。ApplicationContext的其他方法提供访问文件资源、发布应用事件和访问消息资源等。

Autowiring is another alternative to obtain a reference to the ApplicationContext. The traditional constructor and byType autowiring modes (as described in Autowiring Collaborators) can provide a dependency of type ApplicationContext for a constructor argument or a setter method parameter, respectively. For more flexibility, including the ability to autowire fields and multiple parameter methods, use the annotation-based autowiring features. If you do, the ApplicationContext is autowired into a field, constructor argument, or method parameter that expects the ApplicationContext type if the field, constructor, or method in question carries the @Autowired annotation.

自动注入是获取一个ApplicationContext引用的另一个方法，传统的构造函数和通过类型自动装配模式可以分别为构造函数参数或 setter 方法参数提供 ApplicationContext 类型的依赖项。为了获得更大的灵活性，包括自动装配字段和多参数方法的能力，请使用基于注解的自动装配功能。如果这样做，带有 @Autowired 注释的字段、构造函数或方法， ApplicationContext 将自动装配到这些字段、构造函数参数或方法参数中。

When an ApplicationContext creates a class that implements the org.springframework.beans.factory.BeanNameAware interface, the class is provided with a reference to the name defined in its associated object definition. The following listing shows the definition of the BeanNameAware interface:

当ApplicationContext创建了一个实现了BeanNameAware的类，该类被提供了一个引用以对其关联对象定义中定义的名称进行设置，以下代码展示了BeanNameAware 接口的定义：

public interface BeanNameAware {void setBeanName(String name) throws BeansException;
}

The callback is invoked after population of normal bean properties but before an initialization callback such as InitializingBean, afterPropertiesSet, or a custom init-method.

在填充普通 bean 属性之后但在初始化回调（例如 InitializingBean、afterPropertiesSet 或自定义 init-method）之前调用这些回调。

三、Bean Definition Inheritance（Bean定义的继承）

A bean definition can contain a lot of configuration information, including constructor arguments, property values, and container-specific information, such as the initialization method, a static factory method name, and so on. A child bean definition inherits configuration data from a parent definition. The child definition can override some values or add others as needed. Using parent and child bean definitions can save a lot of typing. Effectively, this is a form of templating.

一个Bean的定义能够包含许多配置信息，包括构造器参数、属性值和一些特定于容器的信息，例如初始化方法静态工厂类等等。一个从父bean定义继承了配置信息的子bean定义能够根据需要重写一些值。使用父子bean定义信息能够节省许多类型定义，这是一种有效的模板。

If you work with an ApplicationContext interface programmatically, child bean definitions are represented by the ChildBeanDefinition class. Most users do not work with them on this level. Instead, they configure bean definitions declaratively in a class such as the ClassPathXmlApplicationContext. When you use XML-based configuration metadata, you can indicate a child bean definition by using the parent attribute, specifying the parent bean as the value of this attribute. The following example shows how to do so:

如果你编程式的使用ApplicationContext接口，子bean定义由ChildBeanDefinition类表示。大多数用户并不使用它们，而是在例如ClassPathXmlApplicationContext直接配置bean的定义信息。当年使用基于XML的配置元数据，你可以使用parent属性指明一个子bean的定义，下例展示了如何操作：

<bean id="inheritedTestBean" abstract="true"class="org.springframework.beans.TestBean"><property name="name" value="parent"/><property name="age" value="1"/>
</bean><bean id="inheritsWithDifferentClass"class="org.springframework.beans.DerivedTestBean"parent="inheritedTestBean" init-method="initialize">  <property name="name" value="override"/><!-- the age property value of 1 will be inherited from parent -->
</bean>

A child bean definition inherits scope, constructor argument values, property values, and method overrides from the parent, with the option to add new values. Any scope, initialization method, destroy method, or static factory method settings that you specify override the corresponding parent settings.The remaining settings are always taken from the child definition: depends on, autowire mode, dependency check, singleton, and lazy init.The preceding example explicitly marks the parent bean definition as abstract by using the abstract attribute. If the parent definition does not specify a class, explicitly marking the parent bean definition as abstract is required, as the following example shows:

一个子bean定义继承作用域、构造器参数值、属性值并且覆盖父级中的方法，也可以增加新值。你指定的任何范围、初始化方法、销毁方法或静态工厂方法设置都会覆盖相应的父设置。其余的设置总是取自子定义：依赖、自动装配模式、依赖项检查、单例和惰性初始化。前面的例子通过使用抽象属性显式地将父 bean 定义标记为抽象。如果父定义未指定类，则需要将父 bean 定义显式标记为抽象，如以下示例所示：

<bean id="inheritedTestBeanWithoutClass" abstract="true"><property name="name" value="parent"/><property name="age" value="1"/>
</bean><bean id="inheritsWithClass" class="org.springframework.beans.DerivedTestBean"parent="inheritedTestBeanWithoutClass" init-method="initialize"><property name="name" value="override"/><!-- age will inherit the value of 1 from the parent bean definition-->
</bean>

When a definition is abstract, it is usable only as a pure template bean definition that serves as a parent definition for child definitions，cannot be instantiated.

当定义是抽象的时候，它只能用作纯模板 bean 定义，作为子定义的父定义，不能个实例化。

Spring Core之 Customizing the Nature of a Bean（自定义bean的相关性质）相关推荐

Spring官方文档解读（五）之自定义 bean 的性质
Spring 框架提供了许多接口,可用于自定义 Bean 的性质.本节将它们分组如下: Lifecycle Callbacks ApplicationContextAware 和 BeanNameAw ...
【Spring开发】—— Spring Core
原文:[Spring开发]-- Spring Core 前言最近由于一些工作的需要,还有自己知识的匮乏再次翻开spring.正好整理了一下相关的知识,弥补了之前对spring的一些错误认知.这一次学 ...
Spring Core Container 源码分析七：注册 Bean Definitions
前言原本以为,Spring 通过解析 bean 的配置,生成并注册 bean defintions 的过程不太复杂,比较简单,不用单独开辟一篇博文来讲述:但是当在分析前面两个章节有关 @Autowi ...
Spring教程– Spring Core Framework教程
Spring is one of the most widely used Java EE frameworks. I have written a lot on Spring Tutorial an ...
No qualifying bean of type ‘org.apache.rocketmq.spring.core.RocketMQTemplate‘ av
前言整合springboot+rocketMq报错错误信息如下: org.springframework.beans.factory.NoSuchBeanDefinitionException: ...
Java 统计运行时间之 Apache Commons-lang3和Spring Core提供的StopWatch分析
前言编码过程中我们经常会希望得到一段代码(一个方法)的执行时间,本文将介绍两种时间监视器(秒表)来让你优雅的.灵活的处理这个问题. Java源生方式这种方式最最简单,最好理解,当然也是最为常用:我 ...
spring core之Ioc介绍
1.ApplicationContext是BeanFactory的子接口. 2.BeanFactory提供配置框架和基本功能,ApplicationContext添加更多特定于企业的功能. 3.org ...
（转）Spring读书笔记-----Spring的Bean之Bean的基本概念
从前面我们知道Spring其实就是一个大型的工厂,而Spring容器中的Bean就是该工厂的产品.对于Spring容器能够生产那些产品,则取决于配置文件中配置. 对于我们而言,我们使用Spring框架 ...
Spring bean依赖注入、bean的装配及相关注解
依赖注入 Spring主要提供以下两种方法用于依赖注入基于属性Setter方法注入基于构造方法注入 Setter方法注入例子: public class Communication {priva ...

Spring Core之 Customizing the Nature of a Bean（自定义bean的相关性质）