Нужно ли уничтожать компоненты прототипа Spring вручную?

Для пользы других я представлю ниже то, что я собрал в результате своих исследований:

Пока компонент-прототип не содержит ссылку на другой ресурс, такой как соединение с базой данных или объект сеанса, он будет собирать мусор, как только все ссылки на объект будут удалены или объект выйдет за пределы области видимости. Поэтому обычно нет необходимости явно уничтожать компонент-прототип.

Однако в случае, когда может произойти утечка памяти, как описано выше, компоненты-прототипы могут быть уничтожены путем создания постпроцессора одноэлементного компонента, метод уничтожения которого явно вызывает перехватчики уничтожения ваших компонентов-прототипов. Поскольку постпроцессор сам является одноэлементным, его ловушка уничтожения будут вызывается Spring:

1. Создайте постпроцессор bean для обработки уничтожения всех ваших прототипов bean-компонентов. Это необходимо, потому что Spring не уничтожает прототипы bean-компонентов, и поэтому любые хуки @PreDestroy в вашем коде никогда не будут вызваны контейнером.

2. Реализуйте следующие интерфейсы:

   1.BeanFactoryAware
   Этот интерфейс предоставляет метод обратного вызова, который получает объект Beanfactory. Этот объект BeanFactory используется в классе постпроцессора для идентификации всех компонентов-прототипов с помощью его метода BeanFactory.isPrototype (String beanName).
   
   2. Одноразовые
   Этот интерфейс предоставляет метод обратного вызова Destroy (), вызываемый контейнером Spring. Мы будем вызывать методы Destroy () всех наших прототипов bean-компонентов из этого метода.
   
   3. BeanPostProcessor
   Реализация этого интерфейса обеспечивает доступ к обратным вызовам пост-обработки, из которых мы готовим внутренний List <> всех объектов-прототипов, созданных контейнером Spring. Позже мы переберем этот List <>, чтобы уничтожить каждый из наших прототипов bean-компонентов.

3. Наконец, реализуйте интерфейс DisposableBean в каждом из ваших прототипов bean-компонентов, предоставив метод 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-компоненты создаются путем присвоения значений свойств bean-компонентам как объекты BeanDefinition. Значения свойств определения компонента автоматически разрешаются в экземпляры (inner) (как управляемые одноэлементные компоненты) того компонента, который они определяют.

Следующий элемент конфигурации контекста XML может использоваться для создания отдельных автоматически подключаемых bean-компонентов ForkJoinPool для каждой управляемой ссылки (@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>

Однако такое поведение зависит от того, назначена ли ссылка как стоимость имущества определения компонента. Это означает, что @Autowired и внедрение конструктора не работают с этим по умолчанию, поскольку эти методы автоматического подключения разрешают значение немедленно, а не используют разрешение значения свойства в AbstractAutowireCapableBeanFactory#applyPropertyValues. Автоматическое связывание по типу также не будет работать, поскольку разрешение типа не будет распространяться через bean-компоненты, являющиеся BeanDefinition, для поиска произведенного типа.

Этот метод будет работать, только если выполняется одно из двух условий:

• Зависимые bean-компоненты - это также, определенные в XML.
• Или же, если режим autowire установлен на 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.

• Конструктор-инъекция:

  Фабрика компонентов назначает AutowireCandidateResolver для внедрения конструктора. Значение по умолчанию (ContextAnnotationAutowireCandidateResolver) можно переопределить (DefaultListableBeanFactory#setAutowireCandidateResolver), чтобы применить распознаватель кандидатов, который ищет подходящие компоненты типа BeanDefinition для внедрения.

• @Autowired-инъекция:

  Постпроцессор bean-компонентов AutowiredAnnotationBeanPostProcessor напрямую устанавливает значения bean-компонентов без разрешения внутренних компонентов BeanDefinition. Этот постпроцессор можно переопределить, или можно создать отдельный постпроцессор bean для обработки пользовательской аннотации для управляемых компонентов-прототипов (например, @AutowiredManagedPrototype).