我注意到我的原型范围 Spring bean 的@PreDestroy钩子没有被执行。
从那以后，我在这里读到这实际上是设计使然。 Spring 容器会破坏单例豆，但不会破坏原型豆。 我不清楚为什么。 如果 Spring 容器将创建我的原型 bean 并执行其@PostConstruct钩，为什么当容器关闭时它不会破坏我的 bean？ 一旦我的 Spring 容器关闭，继续使用其中的任何豆子是否有意义？ 我看不到您想要在完成其豆子之前关闭容器的情况。 在容器关闭后，是否有可能继续使用原型春豆？
上面描述了我的主要问题的令人费解的背景，即：如果 Spring 容器没有破坏原型 bean，这是否意味着可能发生内存泄漏？ 还是原型豆会在某个时候被垃圾收集？
Spring 文档指出：
客户端代码必须清理原型范围的对象并发布 原型豆持有的昂贵资源。要获得 Spring 容器释放原型范围 bean 持有的资源， 尝试使用自定义 Bean 后处理器，该处理器包含对 需要清理的豆子。
那是什么意思？ 文本向我暗示，作为程序员，我负责明确(手动)销毁我的原型 bean。 这是对的吗？ 如果是这样，我该怎么做？
为了他人的利益，我将在下面介绍我从调查中收集到的内容：
只要原型 Bean 本身不保存对另一个资源(如数据库连接或会话对象)的引用，一旦删除了对该对象的所有引用或对象超出范围，它就会被垃圾回收。 因此，通常不需要显式销毁原型 bean。
但是，在如上所述可能发生内存泄漏的情况下，可以通过创建单例 Bean 后处理器来销毁原型 bean，其销毁方法显式调用原型 bean 的销毁钩子。 因为后处理器本身是单例范围的，所以它的销毁钩子将被Spring 调用：
-
创建一个 Bean 后处理器来处理所有原型 Bean 的销毁。 这是必要的，因为 Spring 不会破坏原型 bean，因此代码中的任何@PreDestroy钩子都不会被容器调用。
-
实现以下接口：
1.BeanFactoryAware
此接口提供了一个接收 Beanfactory 对象的回调方法。 这个 BeanFactory 对象在后处理器类中用于通过其 BeanFactory.isPrototype(String beanName) 方法标识所有原型 bean。
2.一次性豆
此接口提供了一个由 Spring 容器调用的 Destroy() 回调方法。 我们将从此方法中调用所有原型 bean 的 Destroy() 方法。
3.BeanPostProcessor
实现此接口提供了对后处理回调的访问，从中，我们准备一个内部列表<>由 Spring 容器实例化的所有原型对象。 稍后我们将遍历此列表<>销毁每个原型 bean。
3.最后在每个原型 bean 中实现 DisposableBean 接口，提供此合约所需的 Destroy() 方法。
为了说明这个逻辑，我在下面提供了一些摘自本文的代码：
/**
* Bean PostProcessor that handles destruction of prototype beans
*/
@Component
public class DestroyPrototypeBeansPostProcessor implements BeanPostProcessor, BeanFactoryAware, DisposableBean {
private BeanFactory beanFactory;
private final List<Object> prototypeBeans = new LinkedList<>();
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (beanFactory.isPrototype(beanName)) {
synchronized (prototypeBeans) {
prototypeBeans.add(bean);
}
}
return bean;
}
@Override
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.beanFactory = beanFactory;
}
@Override
public void destroy() throws Exception {
synchronized (prototypeBeans) {
for (Object bean : prototypeBeans) {
if (bean instanceof DisposableBean) {
DisposableBean disposable = (DisposableBean)bean;
try {
disposable.destroy();
} catch (Exception e) {
e.printStackTrace();
}
}
}
prototypeBeans.clear();
}
}
}
你的回答很棒。我还想分享一些关于替代解决方案的说明，该解决方案允许原型成员通过使用内豆由Spring IoC容器生命周期本机管理。
我最近写了一个关于内豆的单独问题的答案。内 Bean 是通过将 Bean 属性值指定为BeanDefinition对象来创建的。Bean 定义属性值会自动解析为它们定义的 Bean 的(inner)实例(作为托管单例 Bean)。
以下 XML 上下文配置元素可用于为每个将要管理的引用创建不同的自动连线ForkJoinPoolbean(@PreDestroy将在上下文关闭时调用)：
<!-- Prototype-scoped bean for creating distinct FJPs within the application -->
<bean id="forkJoinPool" class="org.springframework.beans.factory.support.GenericBeanDefinition" scope="prototype">
<property name="beanClass" value="org.springframework.scheduling.concurrent.ForkJoinPoolFactoryBean" />
</bean>
但是，此行为取决于将引用分配为 Bean 定义的属性值。这意味着默认情况下，@Autowired- 和构造函数注入不起作用，因为这些自动连线方法会立即解析值，而不是在AbstractAutowireCapableBeanFactory#applyPropertyValues中使用属性值解析。按类型自动连线也不起作用，因为类型解析不会通过BeanDefinitions 的 bean 传播以查找生成的类型。
仅当满足以下两个条件之一时，此方法才有效：
- 依赖的 bean也在XML 中定义
- 或者，如果自动连线模式设置为
AutowireCapableBeanFactory#AUTOWIRE_BY_NAME
<!-- Setting bean references through XML -->
<beans ...>
<bean id="myOtherBean" class="com.example.demo.ForkJoinPoolContainer">
<property name="forkJoinPool" ref="forkJoinPool" />
</bean>
</beans>
<!-- Or setting the default autowire mode -->
<beans default-autowire="byName" ...>
...
</beans>
可能会进行两个额外的更改来启用构造函数注入和@Autowired注入。
构造函数注入：
Bean 工厂为构造函数注入分配一个
AutowireCandidateResolver。默认值(ContextAnnotationAutowireCandidateResolver)可以被覆盖(DefaultListableBeanFactory#setAutowireCandidateResolver)以应用候选解析器，该解析器寻找BeanDefinition类型的合格bean进行注入。@Autowired注射：AutowiredAnnotationBeanPostProcessorBean 后处理器直接设置 Bean 值，而不解析BeanDefinition内 Bean。可以覆盖此后处理器，或者可以创建单独的 Bean 后处理器来处理托管原型 Bean 的自定义注释(例如，@AutowiredManagedPrototype)。