Spring 之 Lifecycle 及 SmartLifecycle

最近在看Eureka源码，本想快速解决这场没有硝烟的战役，不曾想阻塞性问题一个接一个。为正确理解这个框架，我不得不耐着性子，慢慢梳理这些让人困惑的点。譬如本章要梳理的Lifecycle和SmartLifecycle。它们均为接口，其中后者继承于前者，他们的类图如下所示：

关于Lifecycle，网络平台给出的解释是这样的：它是Spring框架中的一个基础接口，用于简化管理有状态的组件（譬如连接池、定时任务等）的初始化、启动、停止等生命周期过程。它定义了以下核心方法：

start()：启动组件。这通常涉及初始化必要的资源，使组件处于可操作状态。
stop()：停止组件。执行必要的清理工作，释放资源，使组件处于不可操作状态。
isRunning()：该方法用于检查组件当前是否正在运行。返回true表示组件已启动且正在运行，返回false则表示未启动或已停止。

与SmartLifecycle相比，Lifecycle接口较为简单，不涉及启动顺序控制、自动启动配置或生命周期回调等功能。它是更基础的生命周期管理接口，适用于那些不需要复杂生命周期管理逻辑的组件。

下面就一起看一下Spring的这个组件是如何使用的，其实非常简单，就是实现这个接口且实现其中定义的接口方法，比如下面这个自定义实现类：

package org.com.chinasoft.lifecycle;

import org.springframework.context.Lifecycle;
import org.springframework.context.annotation.Configuration;

@Configuration
public class MyLifecycle implements Lifecycle {
    /**
     * A 组件的运行状态
     */
    private volatile boolean running = false;
    /**
     * 容器启动后调用
     */
    @Override
    public void start() {
        System.out.println("lifecycle 容器启动完成,启动A组件...");
        running = true;
    }
    /**
     * 容器停止时调用
     */
    @Override
    public void stop() {
        System.out.println("lifecycle 收到关闭容器的信号,关闭A组件...");
        running = false;
    }
    /**
     * 检查此组件是否正在运行。
     * 1. 只有该方法返回false时，start方法才会被执行。
     * 2. 只有该方法返回true时，stop(Runnable callback)或stop()方法才会被执行。
     */
    @Override
    public boolean isRunning() {
        System.out.println("lifecycle 检查A组件的运行状态：" + running);
        return running;
    }
}

那这个类是如何使用的呢？通过显式调用ConfigurableApplicationContext上的start()/stop()方法实现的。具体可以看一下下面这个类：

package org.com.chinasoft;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.kafka.KafkaAutoConfiguration;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ConfigurableApplicationContext;

@SpringBootApplication(exclude = KafkaAutoConfiguration.class)
public class EurekaServiceApplication {

    public static void main(String[] args) {
        ConfigurableApplicationContext ctx = SpringApplication.run(EurekaServiceApplication.class, args);
        ctx.start();
        ctx.stop();
    }

}

为什么可以这样呢？这是由于ConfigurableApplicationContext接口继承了Lifecycle接口，关于这个接口的继承结构可以看一下下面这幅图：

从图中可以很清楚的看到ConfigurableApplicationContext接口继承了Lifecycle接口，由此所有实现该接口的类都拥有了Lifecycle的功能。就像案例中写的那样，为了演示Lifecycle接口的用法，我们显式的调用了ConfigurableApplicationContext对象上的start()和stop()方法。执行结果如下图所示：

这里既然提到了显式调用，那如果不显式调用是不是会不一样？（网络资料是这样讲的：如果不显式调用不会有图片中的输出）。注释上述调用代码后的执行结果如下图所示：

个人觉得这里就有点意思了，实际应用过程中，我们会显式调用这个吗？如果不会，这个调用的逻辑又在哪里呢？为了了解这个过程，还是先来看一下显式调用的执行流程（红色加粗加下划线的部分即为实际的执行流程）：

AbstractApplicationContext#start()【这个实现方法来自于其实现的Lifecycle接口】
AbstractApplicationContext#getLifecycleProcessor()【调用这个方法的主要目的是获取Lifecycleprocessor对象，这个对象的实际类型为DefaultLifecycleProcessor】
DefaultLifecycleProcessor#start()【调用该类中的start()方法。这个start()方法接着会调用DefaultLifecycleProcessor类上的startBeans()方法。这个方法首先从容器中拿到所有实现Lifecycle的bean，然后遍历这个集合，将拿到的bean对象包装到Map<Integer, LifecycleGrop>集合中（这个集合的value是一个LifecycleGroup对象），接着会不断调用LifecycleGroup对象的add()方法将Lifecycle对象的名字及对象添加到LifecycleGroup对象中实际类型为List的members集合中，注意这个集合中元素的实际类型为LifecycleGroupMember。最后遍历Map<Integer, LifecycleGrop>集合，然后调用LifecycleGroup对象上名为start()的方法，这个方法首先判断members元素是否为空，如果不为空则排序，然后遍历集合对象中的元素（LifecycleGroupMember），这个遍历会首先对要处理的元素进行检查，看其是否在LifecycleGroup对象上的lifecycleBeans集合中，如果在，则调用DefaultLifecycleProcessor类上的doStart()方法，如果一切顺利最后就调用Lifecycle实现类上的start()方法。这个处理方法的具体实现逻辑如下所示：

private void doStart(Map<String, ? extends Lifecycle> lifecycleBeans, String beanName, boolean autoStartupOnly) {
    Lifecycle bean = lifecycleBeans.remove(beanName);
    if (bean != null && !this.equals(bean)) {
       String[] dependenciesForBean = this.beanFactory.getDependenciesForBean(beanName);
       for (String dependency : dependenciesForBean) {
          doStart(lifecycleBeans, dependency, autoStartupOnly);
       }
       if (!bean.isRunning() &&
             (!autoStartupOnly || !(bean instanceof SmartLifecycle) || ((SmartLifecycle) bean).isAutoStartup())) {
          if (logger.isDebugEnabled()) {
             logger.debug("Starting bean '" + beanName + "' of type [" + bean.getClass() + "]");
          }
          try {
             bean.start();
          }
          catch (Throwable ex) {
             throw new ApplicationContextException("Failed to start bean '" + beanName + "'", ex);
          }
          if (logger.isDebugEnabled()) {
             logger.debug("Successfully started bean '" + beanName + "'");
          }
       }
    }
}

实际调用跟踪过程中发现，这个方法中Lifecycle类型的对象bean是一个代理对象。难道说所有实现该Lifecycle接口的对象都是通过动态代理的方式注入到了Spring容器中？关于这个问题暂且不表，先来看一下这个处理过程中用到的几个类：

DefaultLifecycleProcessor，这是一个实现了LifecycleProcessor接口（这个接口继承了Lifecycle接口）和BeanFactoryAware接口的类。就测试案例中的操作来说：容器中所有对Lifecycle对象的操作都是通过这个类实现的。个人理解这个类的主要作用是：处理Spring Bean的生命周期。（大模型给出的解释：该类是一个实现LifecycleProcessor和BeanFactoryAware接口的Java类。LifecycleProcessor接口定义了在Spring应用程序上下文中处理生命周期方法的策略，BeanFactoryAware接口允许类在被Spring容器实例化时获取对BeanFactory的引用。这个类的作用是处理Spring Bean的生命周期。）
LifecycleGroup，它是DefaultLifecycleProcessor类中的一个私有内部类，其拥有的属性非常清晰：int类型的phase、long类型的timeout、boolean类型的autoStartupOnly、int类型的smartMemberCount、Map<String, ? extneds Lifecycle>类型的lifecycleBeans以及List<LifecycleGroupMember>类型的members。其中members用于存放包装了Lifecycle对象的LifecycleGroupMember对象。另外这个类上还有add(String name, Lifecycle bean)方法、start()方法和stop()方法。其中第一个方法用于将Lifecycle对象添加到members集合中，这个方法在添加前会判断这个对象是否是SmartLifecycle类型，如果是则将smartMemberCount的值自增1。start()方法的作用是在真正调用Lifecycle对象的start()方法前，做一些特殊处理，比如校验（this.members.isEmpty()）、对集合进行排序（Collections.sort(this.members)）、遍历members集合（调用DefaultLifecycleProcessor类上的doStart()方法，触发Lifecycle对象上start()方法的调用）。stop()方法的处理逻辑与start()方法基本类似，有兴趣的可以看一下源码。个人理解这个类的主要作用就是对Lifecycle类型的对象做个分组，以方便管理，实现一些特殊功能。
LifecycleGroupMember，它与LifecycleGroup类似，都是DefaultLifecycleProcessor类中的一个私有内部类，这个类实现了Comparable接口，可以实现排序。这个类中有两个属性，一个为String类型的name，一个是Lifecycle类型的bean，其中只有一个compareTo()方法，这个方法是实现排序的关键。个人理解这个类的作用就是让系统中的Lifecycle对象具有排序功能。

现在让我们一起回过头来看一下这个问题：实际应用过程中，我们会显式调用这个吗？如果不会，这个调用的逻辑又在哪里呢？注意这个问题中提到的显式调用，说的是Lifecycle接口中的start()及stop()，为了寻找这两个方法的调用起点，我们可以利用一下拥有强大查找功能的集成工具idea。通过idea的查找工具，我们可以发现调用Lifecycle接口中的start()及stop()方法的地方有以下几个：

AbstractDiscoveryLifecycle的第243行this.start()：AbstractDiscoveryLifecycle类实现了DiscoveryLifecycle接口（这个接口继承了SmartLifecycle接口，其中SmartLifecycle接口又继承了Lifecycle接口）。因此这里调用的就是AbstractDiscoveryLifecycle类中的start()方法，而这个方法的源调用方即ApplicationListener接口实现类AbstractDiscoveryLifecycle中的onApplicationEvent()方法
RestartEndpoint的第203行this.context.start()：ConfigurableApplicationContext类对象是RestartEndpoint中的属性，而这个类又实现了Lifecycle接口，所以这一行调用的其实就是ConfigurableApplicationContext类父类AbstractApplicationContext中的start()方法
EurekaDiscoveryClientConfiguration的第76行this.autoRegistration.start()：这个调用最终调用的是EurekaAutoServiceRegistration类中的start()方法（这个类实现了SmartLifecycle接口）
EurekaAutoServiceRegistration的第126行start()：EurekaAutoServiceRegistration类实现了SmartLifecycle接口，所以这个start()方法中做了一些自己的逻辑
AbstractApplicationContext的第1303行getLifecycleProcessor().start()：这个就是前面梳理的哪个处理逻辑
DefaultLifecycleProcessor的第175行bean.start()：这个前面也梳理过，调用的就是Lifecycle实现类上的start()方法