当我们想在 Spring 容器启动或者关闭的时候，做一些初始化操作或者对象销毁操作，我们可以怎么做？
注意我这里说的是容器启动或者关闭的时候，不是某一个 Bean 初始化或者销毁的时候～
1. Lifecycle 对于上面提到的问题，如果小伙伴们稍微研究过 Spring，应该是了解其里边有一个 Lifecycle 接口，通过这个接口，我们可以在 Spring 容器启动或者关闭的时候，做一些自己需要的事情。
我们先来看下 Lifecycle 接口：
1 2 3 4 5 public interface Lifecycle void start () void stop () boolean isRunning () }
这个接口一共就三个方法：
start：启动组件，该方法在执行之前，先调用 isRunning 方法判断组件是否已经启动了，如果已经启动了，就不重复启动了。
stop：停止组件，该方法在执行之前，先调用 isRunning 方法判断组件是否已经停止运行了，如果已经停止运行了，就不再重复停止了。
isRunning：这个是返回组件是否已经处于运行状态了，对于容器来说，只有当容器中的所有适用组件 都处于运行状态时，这个方法返回 true，否则返回 false。
如果我们想自定义一个 Lifecycle，方式如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 @Component public class MyLifeCycle implements Lifecycle private volatile boolean running; @Override public void start () running = true ; System.out.println("start" ); } @Override public void stop () running = false ; System.out.println("stop" ); } @Override public boolean isRunning () return running; } }
需要自定义一个 running 变量，该变量用来描述当前组件是否处于运行/停止状态，因为系统在调用 start 和 stop 方法的时候，都会先调用 isRunning 方法，用以确认是否需要真的调用 start/stop 方法。
接下来创建配置类，扫描上述组件：
1 2 3 4 @Configuration @ComponentScan public class JavaConfig }
最后我们启动容器：
1 2 3 4 5 6 7 public class Demo public static void main (String[] args) AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(JavaConfig.class); ctx.start(); ctx.stop(); } }
启动之后，我们就可以看到控制台打印出来的信息：
可以看到，在容器启动和停止的时候，相应的方法会被触发。
不过 Lifecycle 有一个问题，就是必须显式的调用 start 或者 stop 方法才会触发 Lifecycle 中的方法。当然，如果你没有调用 stop 方法，而是调用了 close 方法，那么在 close 方法内部也会触发 stop 方法。
如果我们想要 start 方法被自动触发呢？那就得一个更加智能的 Lifecycle 了— SmartLifecycle。
2. SmartLifecycle 相比于 LifeCycle，SmartLifecycle 中多了几个方法：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 public interface SmartLifecycle extends Lifecycle , Phased int DEFAULT_PHASE = Integer.MAX_VALUE; default boolean isAutoStartup () return true ; } default void stop (Runnable callback) stop(); callback.run(); } @Override default int getPhase () return DEFAULT_PHASE; } }
大家看一下，这里首先多了一个 isAutoStartup 方法，这个方法就表示是否自动执行 startup 方法，这个方法返回 true，则 startup 方法会被自动触发，这个方法要是返回 false，则 startup 方法就不会被自动触发（那么效果就等同于 LifeCycle 了）。
这里多了一个重载的 stop 方法，这个重载的 stop 方法会传入一个线程对象，然后在 stop 中触发，这个 callback 回调是为了告诉容器，我们销毁组件的工作已经完成了。如果使用了 SmartLifecycle，那么 Lifecycle 中的 stop 方法就不会被直接触发了，除非我们在 SmartLifecycle#stop 中手动去触发 Lifecycle#stop 方法。
另外这里还有一个 getPhase 方法，这个当存在多个 SmartLifecycle 实例的时候，我们需要为其执行顺序排序，getPhase 方法就是返回执行顺序，数字越小，优先级越高，默认优先级最小。
我们来写一个 SmartLifecycle 的案例来试下：
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 32 33 34 35 36 @Component public class MyLifeCycle implements SmartLifecycle private volatile boolean running; @Override public void start () running = true ; System.out.println("start" ); } @Override public void stop () running = false ; System.out.println("stop" ); } @Override public boolean isRunning () return running; } @Override public boolean isAutoStartup () return SmartLifecycle.super .isAutoStartup(); } @Override public void stop (Runnable callback) stop(); callback.run(); } @Override public int getPhase () return 0 ; } }
3. 原理分析 那么 Lifecycle 到底是如何被触发的呢？我们来分析一下源码。
由于系统中可能存在多个 Lifecycle，因此这多个 Lifecycle 需要一个统一的管理，这个管理者就是 LifecycleProcessor，这也是一个接口，这个接口中只有两个方法：
1 2 3 4 public interface LifecycleProcessor extends Lifecycle void onRefresh () void onClose () }
onRefresh：这个是在上下文刷新的时候被触发，例如在容器启动的时候这个方法被触发。
onClose：这个是在上下文关闭的时候被触发，例如在容器停止运行的时候这个方法被触发。
LifecycleProcessor 只有一个实现类 DefaultLifecycleProcessor，所以很好分析，这个 DefaultLifecycleProcessor 中，重写了上面的 onRefresh 和 onClose 两个方法：
1 2 3 4 5 6 7 8 9 10 @Override public void onRefresh () startBeans(true ); this .running = true ; } @Override public void onClose () stopBeans(); this .running = false ; }
3.1 start 小伙伴们看到，在容器启动的时候，这里会去调用 startBeans 方法，在这个方法中就会触发 Lifecycle#start 方法：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 private void startBeans (boolean autoStartupOnly) Map<String, Lifecycle> lifecycleBeans = getLifecycleBeans(); Map<Integer, LifecycleGroup> phases = new TreeMap<>(); lifecycleBeans.forEach((beanName, bean) -> { if (!autoStartupOnly || (bean instanceof SmartLifecycle smartLifecycle && smartLifecycle.isAutoStartup())) { int phase = getPhase(bean); phases.computeIfAbsent( phase, p -> new LifecycleGroup(phase, this .timeoutPerShutdownPhase, lifecycleBeans, autoStartupOnly) ).add(beanName, bean); } }); if (!phases.isEmpty()) { phases.values().forEach(LifecycleGroup::start); } }
在这个方法中，首先调用 getLifecycleBeans 方法，这个方法的作用是去 Spring 容器中查找所有 Lifecycle 类型的 Bean，并把查找结果封装到一个 Map 集合中返回。
接下来就去遍历这个 Map，遍历的时候由于 autoStartupOnly 变量传进来的时候是 true，取反之后就是 false 了，所以就会去判断这个 Bean 是否为 SmartLifecycle 类型，如果是该类型并且 isAutoStartup 方法返回 true，就表示要自动执行 start 方法。
如果确定是 SmartLifecycle 类型的 Bean，那么就调用 getPhase 方法获取其 phase，这个表示执行的优先级，然后将之存入到 phases 集合中，存储的时候，phase 是 key，value 则是一个 LifecycleGroup，phases 是一个 TreeMap，小伙伴们知道，TreeMap 是有序的，也就是存入进去的数据，会自动按照 phase 进行排序。LifecycleGroup 是将 phase 相同的 SmartLifecycle 分组之后的对象。
经过上面的分析，相信大家已经明白了为什么直接实现 Lifecycle 接口，就一定需要手动调用 start 方法（因为上面 if 中的条件不满足）。
最后就是遍历 phases，调用每一个 LifecycleGroup 中的 start 方法。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 public void start () if (this .members.isEmpty()) { return ; } Collections.sort(this .members); for (LifecycleGroupMember member : this .members) { doStart(this .lifecycleBeans, member.name, this .autoStartupOnly); } } private void doStart (Map<String, ? extends Lifecycle> lifecycleBeans, String beanName, boolean autoStartupOnly) Lifecycle bean = lifecycleBeans.remove(beanName); if (bean != null && bean != this ) { String[] dependenciesForBean = getBeanFactory().getDependenciesForBean(beanName); for (String dependency : dependenciesForBean) { doStart(lifecycleBeans, dependency, autoStartupOnly); } if (!bean.isRunning() && (!autoStartupOnly || !(bean instanceof SmartLifecycle smartLifecycle) || smartLifecycle.isAutoStartup())) { bean.start(); } } }
在 doStart 方法中，从集合中取出来 Lifecycle，然后查找一下该 Lifecycle 是否有依赖的 Bean，如果有，就继续递归调用 doStart 方法。否则，在 isRunning 返回 false（即该组件还没有运行），且 bean 不是 SmartLifecycle 类型（那就只能是 Lifecycle 类型）或者 bean 是 SmartLifecycle 类型且 isAutoStartup 方法为 true 的情况下，调用 bean 的 start 方法。
小伙伴们注意，上面的分析是从 onRefresh 方法开始的，该方法中调用 startBeans 的时候，传入的参数是 true，也就是上面这个判断里边 autoStartupOnly 为 true，取反之后这个条件就不满足了，如果是我们手动调用 start 方法的话，这个参数默认传入的是 false，取反之后上面这个条件就满足了，也就是无论是手动还是自动，最终都是在这个地方触发 start 方法的。
3.2 stop 再来看 stop 方法的逻辑。从 onClose 方法开始，也是先调用 stopBeans 方法：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 private void stopBeans () Map<String, Lifecycle> lifecycleBeans = getLifecycleBeans(); Map<Integer, LifecycleGroup> phases = new HashMap<>(); lifecycleBeans.forEach((beanName, bean) -> { int shutdownPhase = getPhase(bean); LifecycleGroup group = phases.get(shutdownPhase); if (group == null ) { group = new LifecycleGroup(shutdownPhase, this .timeoutPerShutdownPhase, lifecycleBeans, false ); phases.put(shutdownPhase, group); } group.add(beanName, bean); }); if (!phases.isEmpty()) { List<Integer> keys = new ArrayList<>(phases.keySet()); keys.sort(Collections.reverseOrder()); for (Integer key : keys) { phases.get(key).stop(); } } }
这块的逻辑跟 start 差不多，就是排序的方案有一些差别。这里用了 HashMap，没有用 TreeMap，然后在具体调用的时候，再去给 key 排序的。
这里调用到的也是 LifecycleGroup 的 stop 方法，我们来看下：
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 public void stop () if (this .members.isEmpty()) { return ; } this .members.sort(Collections.reverseOrder()); CountDownLatch latch = new CountDownLatch(this .smartMemberCount); Set<String> countDownBeanNames = Collections.synchronizedSet(new LinkedHashSet<>()); Set<String> lifecycleBeanNames = new HashSet<>(this .lifecycleBeans.keySet()); for (LifecycleGroupMember member : this .members) { if (lifecycleBeanNames.contains(member.name)) { doStop(this .lifecycleBeans, member.name, latch, countDownBeanNames); } else if (member.bean instanceof SmartLifecycle) { latch.countDown(); } } try { latch.await(this .timeout, TimeUnit.MILLISECONDS); if (latch.getCount() > 0 && !countDownBeanNames.isEmpty() && logger.isInfoEnabled()) { logger.info("Failed to shut down " + countDownBeanNames.size() + " bean" + (countDownBeanNames.size() > 1 ? "s" : "" ) + " with phase value " + this .phase + " within timeout of " + this .timeout + "ms: " + countDownBeanNames); } } catch (InterruptedException ex) { Thread.currentThread().interrupt(); } }
大家看一下，这里的 doStop 方法，最终就会触发到 Lifecycle 的 stop，这个里边的代码简单，我们就不去细看了。需要提醒大家的时候，这里使用到了这样一个计数器，初始值就是 members 的数量，每当调用一个 member 的 stop 方法之后，这个计数器减一，这样，到下面调用 await 的时候，就刚刚好不用等。
await 方法的等待时间是 this.timeout，这个属性默认值是 30s，也就是如果 stop 方法在子线程中执行，那么执行时间不能超过 30s，否则就会抛出异常。
如果我们想要自定义这个超时时间，可以自己在 Spring 容器中提供如下 Bean：
1 2 3 4 5 6 7 8 9 10 11 @Configuration @ComponentScan public class JavaConfig @Bean DefaultLifecycleProcessor lifecycleProcessor () { DefaultLifecycleProcessor processor = new DefaultLifecycleProcessor(); processor.setTimeoutPerShutdownPhase(2000 ); return processor; } }
上面这个案例中设置了超时时间为 2s。
好啦，这就是关于 Lifecycle 的整体触发流程。
接下来我们来看下自动触发和手动触发分别是在哪里触发的。
3.3 自动触发 先来看自动触发。
经过前面的讲解，现在小伙伴们都知道，Spring 容器初始化的时候，会调用到 refresh 方法，这个刷新要做的事情比较多，其中最后一件事情是调用 finishRefresh 方法，如下：
1 2 3 4 5 6 7 8 9 10 protected void finishRefresh () clearResourceCaches(); initLifecycleProcessor(); getLifecycleProcessor().onRefresh(); publishEvent(new ContextRefreshedEvent(this )); }
这里有两个方法跟本文相关，一个是 initLifecycleProcessor，这个是初始化 LifecycleProcessor，就是去 Spring 容器中查找 LifecycleProcessor，找到就用，没找到就创建新的。
然后就是 getLifecycleProcessor().onRefresh(); 方法，这个就是触发了 DefaultLifecycleProcessor#onRefresh 方法，而关于该方法的逻辑，松哥在前面已经介绍过了。
来看下 initLifecycleProcessor 方法是如何做初始化操作的：
1 2 3 4 5 6 7 8 9 10 11 12 13 protected void initLifecycleProcessor () ConfigurableListableBeanFactory beanFactory = getBeanFactory(); if (beanFactory.containsLocalBean(LIFECYCLE_PROCESSOR_BEAN_NAME)) { this .lifecycleProcessor = beanFactory.getBean(LIFECYCLE_PROCESSOR_BEAN_NAME, LifecycleProcessor.class); } else { DefaultLifecycleProcessor defaultProcessor = new DefaultLifecycleProcessor(); defaultProcessor.setBeanFactory(beanFactory); this .lifecycleProcessor = defaultProcessor; beanFactory.registerSingleton(LIFECYCLE_PROCESSOR_BEAN_NAME, this .lifecycleProcessor); } }
大家注意，LIFECYCLE_PROCESSOR_BEAN_NAME 常量的值是 lifecycleProcessor，为什么要强调这个，如果我们是自定义 DefaultLifecycleProcessor，那么 beanName 必须是 lifecycleProcessor，否则系统会以为我们没有自定义 DefaultLifecycleProcessor。
那么这里的逻辑就是如果用户自定义了 DefaultLifecycleProcessor，那么就使用用户自定义的 DefaultLifecycleProcessor，否则就创建一个新的 DefaultLifecycleProcessor，并注册到 Spring 容器中。
这就是自动触发的逻辑。
3.4 手动触发 手动触发需要我们自己调用 start 方法，start 方法如下：
1 2 3 4 5 @Override public void start () getLifecycleProcessor().start(); publishEvent(new ContextStartedEvent(this )); }
相当于直接调用了 DefaultLifecycleProcessor 的 start 方法：
1 2 3 4 5 @Override public void start () startBeans(false ); this .running = true ; }
这个跟 DefaultLifecycleProcessor 的 onRefresh 方法内容基本一致，唯一的区别在于调用 startBeans 的时候，传入的参数为 false，这个参数带来的变化，这个松哥在前面的内容中已经分析过了，这里就不再啰嗦啦。
4. 小结 好啦，这就是松哥和大家分享的 Spring Lifecycle 和 SmartLifecycle 的区别。老实说，我们自己开发需要自定义这两个的场景其实并不多，但是在 Spring Boot 中，SmartLifecycle 的应用还是比较多的，有了今天这个内容作基础，将来小伙伴们分析 Spring Boot 的时候就会容易很多了。
