bean 的生命周期从调用 beanFactory 的 getBean 开始，到这个 bean 被销毁，可以总结为以下七个阶段：
-
处理名称，检查缓存
-
处理父子容器
-
处理 dependsOn
-
选择 scope 策略
-
创建 bean
-
类型转换处理
-
销毁 bean
1. 处理名称，检查缓存
-
这一步会处理别名，将别名解析为实际名称
-
对 FactoryBean 也会特殊处理，如果以 & 开头表示要获取 FactoryBean 本身，否则表示要获取其产品
-
这里针对单例对象会检查一级、二级、三级缓存
-
singletonFactories 三级缓存，存放单例工厂对象
-
earlySingletonObjects 二级缓存，存放单例工厂的产品对象
-
如果发生循环依赖，产品是代理；无循环依赖，产品是原始对象
-
-
singletonObjects 一级缓存，存放单例成品对象
-
1.1循环依赖详细介绍
什么是循环依赖？
循环依赖（Circular Dependency），也称为循环引用，是指两个或多个Bean之间相互依赖，形成一个环状依赖链。例如，Bean A依赖于Bean B，而Bean B又依赖于Bean A，这就形成了一个简单的循环依赖。
在Spring框架中，循环依赖问题主要发生在单例（Singleton）Bean的创建过程中。Spring使用依赖注入（DI）来管理Bean的生命周期，当两个或多个Bean相互依赖时，可能会导致循环依赖问题。具体表现为：在创建Bean A时，需要先创建Bean B，但创建Bean B时又需要先创建Bean A，从而导致无限循环，最终引发BeanCurrentlyInCreationException异常。
Spring如何处理循环依赖？
Spring通过三级缓存机制来解决大多数单例Bean的循环依赖问题。三级缓存分别为：
一级缓存（singletonObjects）：用于存放完全初始化好的单例Bean。
二级缓存（earlySingletonObjects）：用于存放原始的、未完全初始化的单例Bean，解决某些依赖注入的提前曝光问题。
三级缓存（singletonFactories）：用于存放创建Bean的工厂对象，主要用于解决Bean的代理问题。
三级缓存机制的工作原理
创建Bean实例：当Spring容器创建一个Bean实例时，首先会在三级缓存中记录该Bean的创建工厂。
提前曝光原始Bean：如果在创建过程中遇到循环依赖，Spring会从三级缓存中取出相应的创建工厂，并提前曝光该Bean的原始实例，放入二级缓存。
依赖注入：继续完成当前Bean的依赖注入过程，此时可以通过二级缓存获取到提前曝光的原始Bean，解决循环依赖问题。
完成初始化：当Bean的依赖注入和初始化过程完成后，Bean实例会从二级缓存移到一级缓存，最终完成Bean的创建。
示例
以下是一个简单的示例，说明Spring如何处理循环依赖：
@Component
public class A {
@Autowired
private B b;
}
@Component
public class B {
@Autowired
private A a;
}
在这个示例中，A和B互相依赖。Spring在处理时会：
创建A的实例，并将其工厂放入三级缓存。
创建B的实例时，发现需要A，于是从三级缓存中获取A的工厂，并将A的原始实例放入二级缓存。
完成B的创建，并将B放入一级缓存。
继续完成A的创建，并将A放入一级缓存。
三级缓存与Bean生命周期的联系
1. 实例化阶段
当Spring容器创建一个Bean的实例时，它首先会通过反射机制调用Bean的构造方法进行实例化。在这个阶段，Bean对象还没有被完全初始化，也没有注入其依赖的属性。
2. 暴露早期Bean引用（三级缓存）
为了处理循环依赖，Spring容器会在实例化Bean之后，初始化之前，将这个早期的Bean引用放入三级缓存中。三级缓存使用ObjectFactory延迟创建和暴露Bean的早期引用，这样当其他Bean需要引用这个Bean时，可以从三级缓存中获取到早期引用。
具体过程如下：
实例化Bean对象：首先，Spring通过构造器或无参构造方法实例化Bean对象。
放入三级缓存：将实例化但尚未完全初始化的Bean对象包装成ObjectFactory，并放入三级缓存singletonFactories中。
3. 属性注入阶段
在属性注入阶段，Spring容器会尝试为Bean注入其依赖的属性。如果在注入过程中遇到循环依赖，Spring容器会按照以下步骤操作：
尝试从一级缓存获取：首先，Spring容器会尝试从一级缓存singletonObjects中获取依赖的Bean。
尝试从二级缓存获取：如果一级缓存中没有，Spring容器会尝试从二级缓存earlySingletonObjects中获取依赖的Bean。
尝试从三级缓存获取：如果二级缓存中也没有，Spring容器会尝试从三级缓存singletonFactories中获取ObjectFactory，然后调用ObjectFactory.getObject()方法获取早期暴露的Bean引用，并将其放入二级缓存中。
通过这种机制，Spring容器可以在属性注入阶段解决循环依赖问题。
4. 初始化阶段
在属性注入完成后，Spring容器会调用Bean的初始化方法（如果有），例如实现InitializingBean接口的afterPropertiesSet方法或自定义的init-method方法。
5. 完全初始化
完成初始化后，Spring容器会将完全初始化的Bean对象从二级缓存转移到一级缓存singletonObjects中。此时，Bean对象已经完全准备好，可以被容器管理和使用。
6. 销毁阶段
当Spring容器关闭时，会调用Bean的销毁方法（如果有），例如实现DisposableBean接口的destroy方法或自定义的destroy-method方法。这与三级缓存机制没有直接关系，但也是Bean生命周期的一部分。
什么时候循环依赖无法解决？
虽然Spring可以通过三级缓存机制解决大多数循环依赖问题，但以下情况可能会导致循环依赖无法解决：
Prototype作用域的Bean：Spring不支持Prototype作用域的Bean循环依赖，因为Prototype Bean不会被缓存。
构造器注入：如果两个Bean通过构造器相互依赖，Spring无法解决这种循环依赖，因为在构造器完成之前，Bean实例还未创建，无法提前曝光。
源码分析
三级缓存的实现主要在 DefaultSingletonBeanRegistry 类中。以下是三级缓存的主要内容：
一级缓存（单例池）：保存完全初始化好的单例 Bean 实例。
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
二级缓存（早期单例曝光缓存）：保存实例化但尚未初始化完成的单例 Bean 实例，主要用于解决循环依赖。
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
三级缓存（单例工厂缓存）：保存创建单例 Bean 实例的工厂。通过工厂方法，可以在需要时创建 Bean 实例，这也是三级缓存的核心。
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
以下是 DefaultSingletonBeanRegistry 类中的相关代码片段：
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
// 一级缓存：单例对象的缓存池
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
// 二级缓存：提前曝光的单例对象，解决循环依赖
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
// 三级缓存：单例工厂缓存
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
// 从缓存中获取单例对象
@Nullable
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// 从一级缓存获取
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
// 从二级缓存获取
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
// 从三级缓存获取
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return singletonObject;
}
// 注册单例对象
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
synchronized (this.singletonObjects) {
if (!this.singletonObjects.containsKey(beanName)) {
this.singletonFactories.put(beanName, singletonFactory);
this.earlySingletonObjects.remove(beanName);
}
}
}
}
在 Spring 的 Bean 创建过程中，这些缓存的作用如下：
实例化阶段：创建 Bean 实例，并将其存储在三级缓存 singletonFactories 中。
属性注入阶段：从三级缓存获取 Bean 实例，并完成属性注入。
初始化阶段：完成初始化方法的调用后，将 Bean 实例从三级缓存移到一级缓存 singletonObjects 中。
2. 处理父子容器
-
如果当前容器根据名字找不到这个 bean，此时若父容器存在，则执行父容器的 getBean 流程
-
父子容器的 bean 名称可以重复
2.1. 父子容器
首先，其实父子这种设计很常见，松哥记得在之前的 Spring Security 的系列文章中，Spring Security 中的 AuthenticationManager 其实也是类似的设计，估计那里就是借鉴了 Spring 中的父子容器设计。
当使用了父子容器之后，如果去父容器中查找 Bean，那么就单纯的在父容器中查找 Bean；
如果是去子容器中查找 Bean，那么就会先在子容器中查找，找到了就返回，没找到则继续去父容器中查找，直到找到为止（把父容器都找完了还是没有的话，那就只能抛异常出来了）。
2.2 为什么需要父子容器
2.2.1 问题呈现
为什么需要父子容器？老老实实使用一个容器不行吗？
既然 Spring 容器中有父子容器，那么这个玩意就必然有其使用场景。
松哥举一个简单的例子。
假设我有一个多模块项目，其中有商家模块和客户模块，商家模块和客户模块中都有角色管理 RoleService，项目结构如下图：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
现在 consumer 和 merchant 中都有一个 RoleService 类，然后在各自的配置文件中，都将该类注册到 Spring 容器中。
org.javaboy.consumer.RoleService：
| 1 2 3 4 5 |
|
org.javaboy.merchant.RoleService：
| 1 2 3 4 5 |
|
consumer_beans.xml 如下：
| 1 2 3 4 5 6 |
|
merchant_beans.xml 如下：
| 1 2 3 4 5 6 |
|
大家注意，这两个 Bean 同名。
现在，在 admin 模块中，同时依赖 consumer 和 merchant，同时加载这两个配置文件，那么能不能同时向 Spring 容器中注册两个来自不同模块的同名 Bean 呢？
代码如下：
| 1 2 3 4 5 |
|
这个执行之后会抛出如下问题：
小伙伴们看到，这个是找不到 org.javaboy.consumer.RoleService 服务，但是另外一个 RoleService 其实是找到了，因为默认情况下后面定义的同名 Bean 把前面的覆盖了，所以有一个 Bean 就找不到了。
如果不允许 Bean 的覆盖，那么可以进行如下配置：
| 1 2 3 4 |
|
此时一启动就直接报错了：
意思也说的比较明确了，Bean 的定义冲突了，所以定义失败。
那么有没有办法能够优雅的解决上面这个问题呢？答案就是父子容器！
2.3 父子容器
对于上面的问题，我们可以将 consumer 和 merchant 配置成父子关系或者兄弟关系，就能很好的解决这个问题了。
2.3.1 兄弟关系
先来看兄弟关系，代码如下：
| 1 2 3 4 5 6 7 8 9 10 11 |
|
小伙伴们看一下，这种针对 consumer 和 merchant 分别创建了容器，这种容器关系就是兄弟容器，这两个兄弟有一个共同的 parent 就是 ctx，现在可以在各个容器中获取到自己的 Bean 了。
需要注意的是，上面这种结构中，子容器可以获取到 parent 的 Bean，但是无法获取到兄弟容器的 Bean，即如果 consumer 中引用了 merchant 中的 Bean，那么上面这个配置就有问题了。
2.3.2 父子关系
现在假设用 consumer 做 parent 容器，merchant 做 child 容器，那么配置如下：
| 1 2 3 4 5 6 7 8 9 10 |
|
首先创建两个容器，分别是 parent 和 child，然后为 child 容器设置 parent，设置完成后记得要刷新 child 容器。
现在我们就可以从 parent 容器中去获取 parent 容器中原本就存在的 Bean，也可以从 child 容器中去获取 child 容器原本的 Bean 或者是 parent 的 Bean 都可以。
这就是父子容器。
父容器和子容器本质上是相互隔离的两个不同的容器，所以允许同名的 Bean 存在。当子容器调用 getBean 方法去获取一个 Bean 的时候，如果当前容器没找到，就会去父容器查找，一直往上找，找到为止。
核心就是 BeanFactory，这个松哥之前文章已经和小伙伴们介绍过了（BeanFactoryPostProcessor 和 BeanPostProcessor 有什么区别？），BeanFactory 有一个子类 HierarchicalBeanFactory，看名字就是带有层级关系的 BeanFactory：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
只要是 HierarchicalBeanFactory 的子类就能配置父子关系。父子关系图如下：
2.4 特殊情况
需要注意的是，并不是所有的获取 Bean 的方法都支持父子关系查找，有的方法只能在当前容器中查找，并不会去父容器中查找：
| 1 2 3 4 5 6 7 8 |
|
如上，根据类型去查找 Bean 名称的时候，我们所用的是 getBeanNamesForType 方法，这个方法是由 ListableBeanFactory 接口提供的，而该接口和 HierarchicalBeanFactory 接口并无继承关系，所以 getBeanNamesForType 方法并不支持去父容器中查找 Bean，它只在当前容器中查找 Bean。
但是！如果你确实有需求，希望能够根据类型查找 Bean 名称，并且还能够自动去父容器中查找，那么可以使用 Spring 给我们提供的工具类，如下：
| 1 2 3 4 5 6 7 8 |
|
不过这个查找，对于父子容器中同名的 Bean 是查找不出来名字的。
2.5 Spring 和 SpringMVC
上面的内容理解了，Spring 和 SpringMVC 之间的关系就好理解了，Spring 是父容器，SpringMVC 则是子容器。
在 SpringMVC 中，初始化 DispatcherServlet 的时候，会创建出 SpringMVC 容器，并且为 SpringMVC 容器设置 parent，相关代码如下：
FrameworkServlet#initWebApplicationContext：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
这里的 rootContext 就是父容器，wac 就是子容器，无论哪种方式得到的子容器，都会尝试给其设置一个父容器。
如果我们在一个 Web 项目中，不单独配置 Spring 容器，直接配置 SpringMVC 容器，然后将所有的 Bean 全部都扫描到 SpringMVC 容器中，这样做是没有问题的，项目是可以正常运行的。但是一般项目中我们还是会把这两个容器分开，分开有如下几个好处：
- 方便管理，SpringMVC 主要处理控制层相关的 Bean，如 Controller、视图解析器、参数处理器等等，而 Spring 层则主要控制业务层相关的 Bean，如 Service、Mapper、数据源、事务、权限等等相关的 Bean。
- 对于新手而言，两个容器分开配置，可以更好的理解 Controller、Service 以及 Dao 层的关系，也可以避免写出来在 Service 层注入 Controller 这种荒唐代码。
另外再额外说一句，有的小伙伴可能会问，如果全部 Bean 都扫描到 Spring 容器中不用 SpringMVC 容器行不行？这其实也可以！但是需要一些额外的配置，这个松哥下篇文章再来和小伙伴们细述。
2.3. 小结
好啦，Spring 容器中的父子容器现在大家应该明白了吧？可以给非 ListableBeanFactory 容器设置父容器，父容器不可以访问子容器的 Bean，但是子容器可以访问父容器的 Bean。
3. 处理 dependsOn
-
如果当前 bean 有通过 dependsOn 指定了非显式依赖的 bean，这一步会提前创建这些 dependsOn 的 bean
-
所谓非显式依赖，就是指两个 bean 之间不存在直接依赖关系，但需要控制它们的创建先后顺序
4. 选择 scope 策略
-
对于 singleton scope，首先到单例池去获取 bean，如果有则直接返回，没有再进入创建流程
-
对于 prototype scope，每次都会进入创建流程
-
对于自定义 scope，例如 request，首先到 request 域获取 bean，如果有则直接返回，没有再进入创建流程
4.1 SCOPE详解
初探scope的用法？
我们创建一个例子：
在第一个html文件中：
<hello></hello>
<hello></hello>
<hello></hello>
<hello></hello>
js代码：
var myModule = angular.module('myModule',[]);
myModule.directive('hello',function(){
return {
scope : {},
restrict : 'AE',
template : '<div><input type="text" ng-model="userName" />{{userName}}</div>',
replace : true
}
})
以上代码，当不存在scope:{}的时候，在其中一个input输入，其他都发生变化，当存在的时候，输入一个，其他不发生变化。
scope的绑定策略有三种方法？
@ ：把当前属性作为字符串传递，你还可以绑定来自外层scope的值，在属性值中插入双括号即可，此方法是单项绑定；
= ：与父scope中的属性进行双向绑定
& ：传递来自父scope的函数，稍后再调用.
使用’@’的例子如下：
02scope@html内容：
<div ng-controller="myCtrl">
<drink flavor="{{ctrlFlavor}}"></drink>
</div>
02scope@.js内容：
var myModule = angular.module('myModule',[]);
myModule.controller('myCtrl',['$scope',function($scope){
$scope.ctrlFlavor = '百事可乐';
$scope.ctrlFlavor2 = '可口可乐';
}]);
myModule.directive('drink',function(){
return {
restrict : 'AE',
scope : {
flavor: '@flavor' //传递的是字符串,把当前属性作为字符串传递,效果和下面的link属性的效果一样。
},
template : '<div>{{flavor}}</div>',
// link : function(scope,element,attrs){
// console.log(attrs)
// scope.flavor = attrs.flavor;
// },
controller : function($scope){
console.log($scope.flavor); //百事可乐
}
}
});
使用=的例子如下：
需要注意的是,=和@的区别是：html中<drink flavor2="ctrlFlavor"></drink>中的flavor2="ctrlFlavor"必须为双引号，不能为{{ctrlFlavor}},而且 = 可以传递父scope的对象，而 @ 只能为数据
03scope=.html内容：
<div ng-controller="myCtrl">
Ctrl : <br>
<input type="text" ng-model="ctrlFlavor"> <br>
Directive : <br>
<drink flavor2="ctrlFlavor"></drink>
</div>
03scope=.js内容：
var myModule = angular.module('myModule',[]);
myModule.controller('myCtrl',['$scope',function($scope){
$scope.ctrlFlavor = '百事可乐';
}]);
myModule.directive('drink',function(){
return {
restrict : 'AE',
scope : {
flavor2 : '=' //与父scope中的属性进行双向绑定
},
template : '<input type="text" ng-model="flavor2"/>',
}
});
使用&的例子如下：
04scope&.html内容如下所示：
<div ng-controller="myCtrl">
<greeting greet="sayHello(name)"></greeting>
<greeting greet="sayHello(name)"></greeting>
<greeting greet="sayHello(name)"></greeting>
</div>
04scope&.js内容：
我们知道，template中的表达式使我们自定义的内部作用域即 '<input type="text" ng-model="userName" /> '+'<button class="btn btn-default" ng-click="greet({name:userName})",而<greeting greet="sayHello(name)"></greeting>就是自定义指令的外部作用域，两者之间的桥梁就是scope所定义的关系：greet : '&',相当于把 外部作用域的sayHello函数通过greet赋值给了ng-click中的函数。
var myModule = angular.module('myModule',[]).myModule.controller('myCtrl',['$scope',function($scope){
$scope.sayHello = function(name){
console.log("hello" + name);
}
}]);
myModule.directive('greeting',function(){
return {
restrict : 'AE',
scope : {
greet : '&'
},
template : '<input type="text" ng-model="userName" /> '+
'<button class="btn btn-default" ng-click="greet({name:userName})" >Greet</button></br><br/>',
link : function(scope,element,attrs){
element.on('input',function(){
console.log(attrs.greet)
})
}
}
});5.创建 bean
5.1 创建 bean - 创建 bean 实例
| 要点 | 总结 |
|---|---|
| 有自定义 TargetSource 的情况 | 由 AnnotationAwareAspectJAutoProxyCreator 创建代理返回 |
| Supplier 方式创建 bean 实例 | 为 Spring 5.0 新增功能，方便编程方式创建 bean 实例 |
| FactoryMethod 方式 创建 bean 实例 | ① 分成静态工厂与实例工厂；② 工厂方法若有参数，需要对工厂方法参数进行解析，利用 resolveDependency；③ 如果有多个工厂方法候选者，还要进一步按权重筛选 |
| AutowiredAnnotationBeanPostProcessor | ① 优先选择带 @Autowired 注解的构造；② 若有唯一的带参构造，也会入选 |
| mbd.getPreferredConstructors | 选择所有公共构造，这些构造之间按权重筛选 |
| 采用默认构造 | 如果上面的后处理器和 BeanDefiniation 都没找到构造，采用默认构造，即使是私有的 |
5.2 创建 bean - 依赖注入
| 要点 | 总结 |
|---|---|
| AutowiredAnnotationBeanPostProcessor | 识别 @Autowired 及 @Value 标注的成员，封装为 InjectionMetadata 进行依赖注入 |
| CommonAnnotationBeanPostProcessor | 识别 @Resource 标注的成员，封装为 InjectionMetadata 进行依赖注入 |
| resolveDependency | 用来查找要装配的值，可以识别：① Optional；② ObjectFactory 及 ObjectProvider；③ @Lazy 注解；④ @Value 注解（${ }, #{ }, 类型转换）；⑤ 集合类型（Collection，Map，数组等）；⑥ 泛型和 @Qualifier（用来区分类型歧义）；⑦ primary 及名字匹配（用来区分类型歧义） |
| AUTOWIRE_BY_NAME | 根据成员名字找 bean 对象，修改 mbd 的 propertyValues，不会考虑简单类型的成员 |
| AUTOWIRE_BY_TYPE | 根据成员类型执行 resolveDependency 找到依赖注入的值，修改 mbd 的 propertyValues |
| applyPropertyValues | 根据 mbd 的 propertyValues 进行依赖注入（即xml中 <property name ref|value/>） |
5.3 创建 bean - 初始化
| 要点 | 总结 |
|---|---|
| 内置 Aware 接口的装配 | 包括 BeanNameAware，BeanFactoryAware 等 |
| 扩展 Aware 接口的装配 | 由 ApplicationContextAwareProcessor 解析，执行时机在 postProcessBeforeInitialization |
| @PostConstruct | 由 CommonAnnotationBeanPostProcessor 解析，执行时机在 postProcessBeforeInitialization |
| InitializingBean | 通过接口回调执行初始化 |
| initMethod | 根据 BeanDefinition 得到的初始化方法执行初始化，即 <bean init-method> 或 @Bean(initMethod) |
| 创建 aop 代理 | 由 AnnotationAwareAspectJAutoProxyCreator 创建，执行时机在 postProcessAfterInitialization |
5.4 创建 bean - 注册可销毁 bean
在这一步判断并登记可销毁 bean
-
判断依据
-
如果实现了 DisposableBean 或 AutoCloseable 接口，则为可销毁 bean
-
如果自定义了 destroyMethod，则为可销毁 bean
-
如果采用 @Bean 没有指定 destroyMethod，则采用自动推断方式获取销毁方法名（close，shutdown）
-
如果有 @PreDestroy 标注的方法
-
-
存储位置
-
singleton scope 的可销毁 bean 会存储于 beanFactory 的成员当中
-
自定义 scope 的可销毁 bean 会存储于对应的域对象当中
-
prototype scope 不会存储，需要自己找到此对象销毁
-
-
存储时都会封装为 DisposableBeanAdapter 类型对销毁方法的调用进行适配
6. 类型转换处理
-
如果 getBean 的 requiredType 参数与实际得到的对象类型不同，会尝试进行类型转换
7. 销毁 bean
-
销毁时机
-
singleton bean 的销毁在 ApplicationContext.close 时，此时会找到所有 DisposableBean 的名字，逐一销毁
-
自定义 scope bean 的销毁在作用域对象生命周期结束时
-
prototype bean 的销毁可以通过自己手动调用 AutowireCapableBeanFactory.destroyBean 方法执行销毁
-
-
同一 bean 中不同形式销毁方法的调用次序
-
优先后处理器销毁，即 @PreDestroy
-
其次 DisposableBean 接口销毁
-
最后 destroyMethod 销毁（包括自定义名称，推断名称，AutoCloseable 接口 多选一）
-
参考原文链接：https://blog.csdn.net/kaka_buka/article/details/139785462
参考原文链接：Spring中的父子容器原理解析_java_脚本之家
参考原文链接：https://blog.csdn.net/flyingpig2016/article/details/75308211
扫一扫
1320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
