Spring原型bean需要手动销毁吗？

Question

我注意到我的原型作用域的Spring bean的@PreDestroy钩子没有被执行。

我后来在这里阅读到，这实际上是设计意图。Spring容器将销毁单例bean，但不会销毁原型bean。我不清楚为什么这样设计。如果Spring容器将创建我的原型bean并执行其@PostConstruct钩子，那么当容器关闭时为什么不销毁我的bean呢？一旦我的Spring容器被关闭，是否继续使用它的任何bean都没有意义？我无法想象在完成完所有bean操作之前为什么要关闭容器。在原型Spring bean所属的容器关闭后，是否可能继续使用该bean？

以上描述了我主要问题的困惑背景：如果Spring容器不销毁原型bean，那么内存泄漏可能会发生吗？或者原型bean会在某个时刻被垃圾收集器回收？

Spring文档中提到：

客户端代码必须清理原型作用域对象并释放原型bean正在持有的昂贵资源。为了让Spring容器释放原型作用域bean所持有的资源，

尝试使用自定义的bean后处理器，该后处理器持有需要清理的bean的引用。

这是什么意思？这段文字让我觉得作为程序员，我需要显式（手动）销毁我的原型bean。这是正确的吗？如果是这样，我该如何做到呢？

- IqbalHamid

---

只要您不需要释放原型 Bean 使用的资源，就无需执行任何操作。例如，如果您在原型作用域 Bean 中创建了 DB 连接池，则可能需要关闭它 :) - Michal

Spring不知道原型bean的生命周期，因此它只会调用初始化程序，而不是销毁回调，因为它根本不知道（也不能知道）何时不再需要它。 - M. Deinum

谢谢你们两位。@M.Deinum，你所说的我在我的问题中已经讨论过了。关闭Spring容器应该给Spring一个很大的提示，表明我们已经完成了原型bean。一旦容器被关闭，甚至可以继续使用任何Spring bean（即使是原型bean）吗？即使可以，Spring文档中的引用也表明，除非我销毁该bean，否则将会出现内存泄漏。这就是让我感到恐慌的原因。我听到Michal建议垃圾收集器会在对象变量到达原型bean时自动清理它。 - IqbalHamid

不，它并没有。Spring怎么知道仍然有原型bean挂在那里？一些人使用具有原型bean的上下文作为短暂bean的工厂（或者拥有bean的蓝图）。理论上可能已经创建了数千个原型bean实例，这些实例已经被垃圾回收了。Spring根本不知道这一点。只有当原型bean持有对某些东西的引用以防止其被垃圾回收时，才会出现内存泄漏。 - M. Deinum

@Michal 但是如果Spring从未调用Bean的销毁钩子(@PreDestroy)，那么你如何释放该Bean所使用的资源呢？我猜手动从客户端代码调用销毁钩子可能是唯一的方法？ - IqbalHamid

谢谢@M.Deinum，您的评论很有道理。 - IqbalHamid

Answer 1

为了让其他人受益，我将从我的调查中总结以下内容：

只要原型bean本身不持有对其他资源（如数据库连接或会话对象）的引用，那么它将在所有对该对象的引用被删除或对象超出范围时立即被垃圾回收。因此，通常不需要显式销毁原型bean。

然而，在可能出现内存泄漏的情况下，可以通过创建单例bean后处理器来销毁原型bean，其销毁方法明确调用原型bean的销毁挂钩。由于后处理器本身是单例范围，因此Spring将调用其销毁挂钩：

1. 创建一个bean后处理器以处理所有原型bean的销毁。这是必需的，因为Spring不销毁原型bean，所以代码中的任何@PreDestroy挂钩都不会被容器调用。

2. 实现以下接口：

   1. BeanFactoryAware
   此接口提供回调方法，接收Beanfactory对象。后处理器类中使用此BeanFactory对象通过其BeanFactory.isPrototype(String beanName)方法识别所有原型bean。
   
   2. DisposableBean
   此接口提供了Spring容器调用的Destroy()回调方法。我们将从此方法中调用所有原型bean的Destroy()方法。
   
   3. BeanPostProcessor
   实现此接口可以从中访问后处理回调，在其中，我们准备由Spring容器实例化的所有原型对象的内部List<>。稍后，我们将循环遍历此List<>以销毁每个原型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();
        }
    }
}

- IqbalHamid

---

另外值得一提的是最好使用Deque<Object> prototypeBeans = new ArrayDeque<>();和push()，而不是add()，这样循环就可以按照相反的顺序执行。你永远不知道bean之间是否存在额外的依赖关系... - sjngm

再说一遍集成测试：如果它实例化了原型作用域的bean，请不要忘记在集成测试中添加@DirtiesContext。 - sjngm

我理解了“如何”，但是我不明白“为什么”。你的意思是，由于存在原型bean中具有db、session引用的情况，应该由客户端而不是框架来使用自定义处理器销毁它。但是为什么呢？ - susheelbhargavk

只要原型bean本身不持有对其他资源（如数据库连接或会话对象）的引用，它将在所有对该对象的引用被删除或对象超出范围时立即被垃圾回收。为什么您认为如果bean持有db连接，它就不会被回收呢？ - Dragos Ionut

在这个例子中，为什么要清除类变量？我们为什么要调用列表的clear方法？我们应该清除bean中的所有局部变量吗？这会导致内存泄漏吗？ - omerstack

Answer 2

你的回答很棒。我也想分享一些关于另一种解决方案的笔记，该解决方案允许原型成员通过使用内部bean在Spring IoC容器生命周期中进行本地管理。

最近我为一个关于内部bean的单独问题写了一个回答。内部bean是通过将bean属性值分配为BeanDefinition对象来创建的。 Bean定义属性值会自动解析为它们定义的bean的（inner）实例（作为托管单例bean）。

以下XML上下文配置元素可用于为每个引用创建不同的可自动装配的ForkJoinPool bean，这些bean将被管理（在上下文关闭时将调用@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中的属性值解析。按类型自动装配也不起作用，因为类型解析不会通过BeanDefinition找到生成的类型。

只有两个条件之一成立才能使用此方法：

- 依赖的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>

Two additional changes could likely be made to enable constructor-injection and @Autowired-injection.

• Constructor-injection:

  The bean factory assigns an AutowireCandidateResolver for constructor injection. The default value (ContextAnnotationAutowireCandidateResolver) could be overridden (DefaultListableBeanFactory#setAutowireCandidateResolver) to apply a candidate resolver which seeks eligible beans of type BeanDefinition for injection.

• @Autowired-injection:

  The AutowiredAnnotationBeanPostProcessor bean post processor directly sets bean values without resolving BeanDefinition inner beans. This post processor could be overridden, or a separate bean post processor could be created to process a custom annotation for managed prototype beans (e.g., @AutowiredManagedPrototype).

- Mike Hill