SpringBoot启动后的初始化数据加载原理解析与实战

系统初始化操作是一个非常常见的需求。通常，应用在启动后需要执行一些重要的初始化任务，例如加载全局配置、初始化数据库表、预热缓存、启动后台任务等。而如何选择合适的技术方案，在不同的场景下保证初始化任务的高效执行，尤其在多实例的分布式部署中，如何确保任务只执行一次，成为我们在项目实战中需要深入思考和优化的关键问题。

本文将结合 spring boot 框架，从基础的启动机制、核心技术原理到分布式环境下的复杂场景，带领大家逐步深入理解如何通过不同方式进行启动后的初始化任务执行。最终，我们会通过一个项目实战例子，演示如何确保初始化任务在分布式部署环境中只执行一次，解决多实例下的任务重复执行问题。

初始化任务的基本需求

这些任务有一个共同的特性：它们通常只需要在应用启动时执行一次。因此，选择一个合适的机制来执行这些初始化操作，并且在分布式环境中确保任务不会被重复执行，是至关重要的。包括但不限于：

• 全局配置的加载：如从数据库、配置文件或远程服务加载全局的应用参数。
• 数据库表初始化：例如检查并创建缺失的数据库表、插入初始数据等。
• 缓存预热：应用启动后立即加载部分常用数据到缓存中，减少首次访问的延迟。
• 后台任务启动：启动如消息队列监听、定时任务调度等长期运行的后台服务。
• 系统健康检查：确保关键依赖服务（如数据库、消息队列、第三方服务）在启动时正常工作。

启动后初始化加载的几种方式

spring boot 提供了多种机制来处理应用启动后的初始化任务。这些机制涵盖了单机部署和分布式部署的需求，并且具有不同的执行时机和适用场景。

postconstruct 注解

@postconstruct 是一种非常简洁且常用的方式，它用于标注在 spring 管理的 bean 完成依赖注入后自动调用的方法。这种方式特别适合单个 bean 的初始化操作。spring 在完成依赖注入后，自动调用带有 @postconstruct 注解的方法，确保初始化逻辑在 bean 初始化完成时执行。

适用于需要在某个特定 bean 初始化完成后执行的任务。例如，某个服务类需要在加载时读取配置文件或执行特定的初始化操作。

@component
public class myservice {
    @postconstruct
    public void init() {
        // 初始化任务，只执行一次
        system.out.println("bean 初始化后执行");
    }
}

优点：

• 简单直观：它是 java ee 标准的一部分，使用非常简单。只需要在一个方法上加上 @postconstruct 注解，spring 会在 bean 初始化后自动调用该方法。
• 自动调用：可以确保在 spring 容器完成 bean 的依赖注入后，自动执行初始化操作，不需要显式调用。

缺点：

• 只能处理单个 bean 的初始化任务：@postconstruct 注解的方法只能作用于某个具体 bean，在这个 bean 完成初始化时执行。如果有多个 bean 需要初始化任务，@postconstruct 无法跨 bean 控制执行逻辑。

commandlinerunner / applicationrunner

commandlinerunner 和 applicationrunner 是 spring boot 中用于在应用启动完成后执行初始化任务的接口。两者的区别在于传递的参数形式，commandlinerunner 提供原始的 string[] 参数，而 applicationrunner 封装了启动参数的上下文信息。

commandlinerunner：这个接口提供的是原始的 string[] 启动参数，这些参数通常是应用启动时传递给 java 程序的命令行参数。如果你只关心应用启动时的命令行参数并且需要直接操作它们，可以使用 commandlinerunner。

applicationrunner：这个接口封装了启动时的参数，通过 applicationarguments 类提供对命令行参数的更高层次的访问。如果你需要更多功能（例如获取非标准格式的命令行参数，处理带有标志的参数等），可以使用 applicationrunner。

优点

• 适用于全局任务：无论是 commandlinerunner 还是 applicationrunner，都能在所有 bean 完成初始化之后执行，确保应用的启动逻辑是全局性的。
• 自动执行：一旦实现了这些接口的类被注册为 spring bean，spring 会自动调用它们的 run() 方法，任务执行是自动的，无需显式调用。

缺点

• 多个实现类的顺序控制：如果项目中有多个 commandlinerunner 或 applicationrunner 实现类，默认情况下它们的执行顺序是不确定的。为了保证执行顺序，可以使用 @order 注解明确指定执行的优先级。
• 只能执行一次：这类方法在 spring boot 应用启动时执行，并且默认只执行一次。如果你需要某些任务在应用的生命周期内多次执行，这种方式不适用。

使用 commandlinerunner

@component
public class mystartuprunner implements commandlinerunner {
    @override
    public void run(string... args) {
        // 这是应用启动后要执行的任务
        system.out.println("应用启动后执行初始化任务");
    }
}

使用 applicationrunner

@component
public class myappstartuprunner implements applicationrunner {
    @override
    public void run(applicationarguments args) throws exception {
        // 获取命令行参数
        system.out.println("应用启动后执行初始化任务，获取启动参数：" + args.getoptionnames());
    }
}

运行后我们会发现，@component 的执行顺序确实早于 applicationrunner 和 commandlinerunner。

为什么是这个顺序

**@component注解的 bean：**任何标注为 @component（或 @service、@repository、@controller 等）的类会在 spring boot 应用启动时被自动扫描并实例化。这些 bean 会在 spring 容器启动的初期阶段被创建和初始化，在应用启动过程中最早被加载和执行。

applicationrunner 和 commandlinerunner： 这两个接口的实现类是 spring boot 特有的启动钩子，它们在所有@component bean 被创建和初始化之后执行，但在 spring boot 完成应用启动（即应用的上下文已准备好）后执行。applicationrunner 会比 commandlinerunner 早执行，因为它封装了启动参数上下文的更多信息，所以它们的 run() 方法会在 spring boot 完成上下文刷新和 bean 初始化之后执行。

执行顺序控制

如果你的项目中有多个实现类，且它们都需要在应用启动时执行，使用 @order 注解可以明确控制执行顺序。例如：

@component
@order(1)  // 设置优先级，数字越小优先级越高
public class firststartuptask implements commandlinerunner {
    @override
    public void run(string... args) {
        system.out.println("第一个启动任务");
    }
}

@component
@order(2)
public class secondstartuptask implements commandlinerunner {
    @override
    public void run(string... args) {
        system.out.println("第二个启动任务");
    }
}

这样，firststartuptask 会在 secondstartuptask 之前执行。

spring boot 生命周期事件

spring boot 提供了事件驱动的编程模型，可以帮助开发者在应用生命周期的不同阶段执行特定的任务。通过监听 spring 生命周期事件，开发者可以在精确的时机执行初始化任务。这种方式适合需要确保任务执行时机的场景，例如，某些任务必须等到应用完全启动、数据库连接已经建立、服务已经准备好之后才能执行。spring boot 中有很多生命周期事件，例如：

**applicationreadyevent：**当应用完全启动并准备好处理请求时触发。此事件表示 spring 应用上下文已经完全初始化，应用已准备好接收外部请求。适用于在应用启动完成后立即执行的初始化任务，例如启动后台服务、初始化缓存等。

contextrefreshedevent：当 spring 上下文被初始化或刷新时触发。这通常发生在 spring boot 启动过程中，用于标志 spring 容器准备好并且所有 bean 已初始化完毕。 - 适合在应用启动时进行一些预热操作，如加载配置信息、初始化数据库连接池等。

applicationstartedevent：在 spring boot 应用启动时触发，发生在 spring 上下文加载之前，可以用于执行一些早期的初始化任务。

applicationenvironmentpreparedevent：在 spring boot 启动过程中，当应用的 environment 配置完成时触发。这时还未初始化 spring 容器，适用于一些基于环境配置的初始化。

applicationfailedevent：如果 spring boot 启动失败，这个事件会被触发。可以用来处理应用启动失败后的清理或日志记录。

监听 spring 生命周期事件

spring boot 提供了 applicationlistener 接口和 @eventlistener 注解来监听这些生命周期事件。我们可以通过这两种方式，在特定的时机执行初始化任务。

1：使用 applicationlistener 监听 applicationreadyevent

通过实现 applicationlistener 接口，可以监听指定的事件，例如监听 applicationreadyevent 来确保在应用完全启动后执行任务。

@component
public class applicationlistenerexample implements applicationlistener<applicationreadyevent> {
    @override
    public void onapplicationevent(applicationreadyevent event) {
        // 应用启动完成后执行的任务
        system.out.println("应用启动完成后执行任务");
    }
}

• 事件：applicationreadyevent 是 spring boot 应用启动完成后发布的事件。
• 触发时机：在所有 bean 被初始化之后，并且 spring 上下文已经完全加载并准备好时，applicationreadyevent 会被触发。

2：使用 @eventlistener 注解监听事件

spring 5 引入了 @eventlistener 注解，它提供了更简洁的方式来监听事件，不需要显式实现 applicationlistener 接口。

@component
public class eventlistenerexample {
    @eventlistener(applicationreadyevent.class)
    public void handleapplicationready() {
        // 应用启动完成后执行的任务
        system.out.println("使用 @eventlistener 在应用启动后执行任务");
    }
}

• 事件：@eventlistener(applicationreadyevent.class) 表示监听 applicationreadyevent 事件。
• 触发时机：@eventlistener 注解的方法会在 applicationreadyevent 触发时执行，适用于应用完全启动后的任务。

事件驱动机制的优缺点

优点：

• 精确控制执行时机：通过监听特定的生命周期事件，开发者可以精确地控制初始化任务的执行时机，确保任务只在应用处于某种状态时执行。例如，applicationreadyevent 事件保证任务只在应用完全启动后执行。
• 解耦应用逻辑：使用事件监听机制，开发者不需要直接在应用启动过程中显式调用初始化任务。事件驱动可以帮助将应用的启动逻辑与任务执行逻辑解耦，使得代码更清晰、更易维护。
• 处理复杂的初始化逻辑：如果初始化逻辑比较复杂，或者有多个任务需要按特定顺序执行，事件机制可以提供灵活的控制。例如，contextrefreshedevent 可以确保一些初始化任务在 spring 上下文初始化完成后执行。

缺点：

• 依赖事件触发：事件机制的缺点是任务的执行依赖于事件的触发，这要求开发者对 spring 事件机制有所了解。如果应用启动过程中没有触发预期的事件，初始化任务可能会错过执行时机。
• 调试难度较大：如果任务执行依赖于特定的事件触发，在调试时可能需要特别关注事件的触发顺序和事件的监听逻辑，否则可能会导致任务无法按预期执行。
• 学习成本：对于没有使用过 spring 事件机制的开发者来说，需要花费一些时间学习和理解事件发布与监听的原理，尤其是在多事件场景下，理解事件的传播与监听顺序。

使用 @bean(initmethod) 定义自定义初始化方法

在 spring 中，@bean(initmethod) 提供了一种自定义 bean 初始化方法的方式。通过这种机制，开发者可以为特定的 bean 指定一个初始化方法，该方法会在 spring 容器完成该 bean 的依赖注入和实例化后自动执行。通常，这种方法用于处理一些复杂的初始化操作，例如初始化数据库连接、加载外部配置、启动后台任务等。

适用于需要复杂初始化的 bean：当 bean 的初始化需要执行复杂的操作（例如调用外部 api、执行文件加载、数据库连接初始化等）时，可以通过 initmethod 指定一个初始化方法，而不需要在 bean 类中使用 @postconstruct 注解或 commandlinerunner 等方式。

外部配置控制初始化逻辑：@bean(initmethod = "init") 允许将 bean 的初始化方法与外部配置绑定，使得开发者能够更灵活地控制 bean 的初始化过程。

@configuration
public class appconfig {
    @bean(initmethod = "init")
    public myservice myservice() {
        return new myservice();
    }
}

public class myservice {
    // 自定义初始化逻辑
    public void init() {
        system.out.println("自定义初始化方法");
    }
}

• @bean(initmethod = "init")：这里，@bean 注解为 myservice 定义了一个初始化方法 init。当 myservice bean 被创建并且依赖注入完成后，init 方法会被自动调用。
• init() 方法：myservice 类中定义了一个名为 init() 的方法，这个方法在 bean 完成初始化后会被自动调用。通常，这个方法包含了一些额外的初始化逻辑，比如外部资源的加载或初始化。

优缺点分析

优点：

• 灵活性：@bean(initmethod) 允许开发者灵活指定初始化方法的名称，适合用于需要在 bean 初始化时执行某些特定任务的场景。与 @postconstruct 或 commandlinerunner 等方法相比，@bean(initmethod) 提供了更多的控制选项，尤其在复杂的应用程序中。
• 支持复杂初始化逻辑：当 bean 的初始化过程比较复杂（例如需要加载配置、启动线程、或者处理数据库连接等），可以通过 initmethod 方法指定特定的初始化逻辑。
• 与 spring 配置文件解耦：在使用 @configuration 类中配置 bean 时，initmethod 提供了一种不依赖于 bean 类本身的初始化方式。它有助于将 bean 的配置与实现分离。

缺点：

• 可读性略差：相比 @postconstruct 或 commandlinerunner 等注解的方式，@bean(initmethod) 需要开发者在配置类中明确指定初始化方法的名称，这可能导致代码的可读性略差，尤其是在项目中有多个配置类和多个初始化方法时，开发者可能需要更加小心地管理这些方法。
• 不适合所有类型的初始化：对于一些简单的 bean 初始化任务，例如基本的配置加载或基础的数据预处理，使用 @bean(initmethod) 可能显得过于冗余。此时，使用 @postconstruct 或 commandlinerunner 等方式更为简洁和直接。
• 初始化方法依赖 spring 容器的管理：@bean(initmethod) 中指定的初始化方法必须是由 spring 容器管理的 bean。在某些情况下（例如某些纯 java 对象或手动创建的 bean），可能无法直接使用该方法进行初始化。

综合项目实战

需求说明

假设我们有一个应用，要求在启动时执行以下初始化任务：

• 从数据库或远程服务加载全局配置。
• 初始化一些数据库表（如果不存在）。
• 预热缓存。
• 启动后台任务（如定时任务）。
• 在多实例的分布式环境中，确保某些初始化任务只执行一次（如初始化某些基础数据、加载配置等）。

方案设计

我们将使用 spring boot 的不同初始化方式结合分布式锁来确保任务只执行一次。具体使用以下技术：

• @postconstruct：用于简单的初始化任务。
• commandlinerunner：用于全局任务，在应用启动后执行。
• spring 事件机制：用于精确控制任务的执行时机。
• 分布式锁（基于 redis）：确保在多实例环境中，任务只执行一次。
• 自定义 @bean(initmethod)：为需要特殊初始化逻辑的 bean 指定初始化方法。

1. 项目结构

src
└── main
    ├── java
    │   └── com
    │       └── example
    │           ├── application.java
    │           ├── config
    │           │   └── appconfig.java
    │           ├── initializer
    │           │   ├── appstartuprunner.java
    │           │   ├── cacheinitializer.java
    │           │   └── distributedlockinitializer.java
    │           └── service
    │               └── myservice.java
    └── resources
        └── application.properties

2. application.properties

# redis 配置
spring.redis.host=localhost
spring.redis.port=6379

# 数据库配置（假设使用 mysql）
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=root

3. 主应用入口类 application.java

package com.example;

import org.springframework.boot.springapplication;
import org.springframework.boot.autoconfigure.springbootapplication;

@springbootapplication
public class application {
    public static void main(string[] args) {
        springapplication.run(application.class, args);
    }
}

4. 配置类 appconfig.java

package com.example.config;

import org.springframework.context.annotation.bean;
import org.springframework.context.annotation.configuration;
import com.example.service.myservice;

@configuration
public class appconfig {

    @bean(initmethod = "init")
    public myservice myservice() {
        return new myservice();
    }
}

5. 服务类 myservice.java

package com.example.service;

public class myservice {

    public void init() {
        // 这里可以执行复杂的初始化操作，如外部api调用等
        system.out.println("执行 myservice 的自定义初始化方法");
    }
}

6. 启动初始化任务类 appstartuprunner.java

package com.example.initializer;

import org.springframework.boot.commandlinerunner;
import org.springframework.stereotype.component;

@component
public class appstartuprunner implements commandlinerunner {
    @override
    public void run(string... args) throws exception {
        // 应用启动后执行的初始化任务
        system.out.println("执行应用启动时的全局初始化任务");
    }
}

7. 缓存初始化类 cacheinitializer.java

package com.example.initializer;

import org.springframework.stereotype.component;

import javax.annotation.postconstruct;

@component
public class cacheinitializer {

    @postconstruct
    public void init() {
        // 预热缓存逻辑，例如加载常用数据到缓存
        system.out.println("执行缓存预热任务");
    }
}

8. 分布式锁初始化类 distributedlockinitializer.java

package com.example.initializer;

import org.springframework.beans.factory.annotation.autowired;
import org.springframework.data.redis.core.stringredistemplate;
import org.springframework.boot.context.event.applicationreadyevent;
import org.springframework.context.applicationlistener;
import org.springframework.stereotype.component;

@component
public class distributedlockinitializer implements applicationlistener<applicationreadyevent> {

    @autowired
    private stringredistemplate redistemplate;

    @override
    public void onapplicationevent(applicationreadyevent event) {
        // 获取分布式锁，确保初始化任务只执行一次
        boolean success = redistemplate.opsforvalue().setifabsent("init_lock", "locked");
        if (boolean.true.equals(success)) {
            // 模拟执行初始化任务（如初始化数据表、加载配置等）
            system.out.println("执行初始化任务：初始化数据库或加载基础数据");
            // 这里可以执行初始化数据库表、加载默认数据等任务
        } else {
            system.out.println("任务已经在其他实例中执行，当前实例跳过任务");
        }
    }
}

9.关键技术和设计

• @postconstruct：用于缓存预热任务，在 bean 初始化完成后立即执行。
• commandlinerunner：全局任务的执行方式，确保应用启动后执行某些初始化操作。
• 事件驱动机制（applicationreadyevent）：精确控制任务执行的时机，确保任务在应用完全启动并准备好后执行。
• 分布式锁（基于 redis）：确保初始化任务在多实例部署的环境中只执行一次。通过 stringredistemplate 实现 redis 的分布式锁，防止在多个实例中重复执行相同任务。
• @bean(initmethod)：为特定的 bean 指定自定义初始化方法，适合需要复杂初始化的场景。

10.运行效果

• 当应用启动时，commandlinerunner 会执行全局初始化任务，确保应用启动后的任务被执行。
• cacheinitializer 会在 bean 初始化完成后执行缓存预热。
• distributedlockinitializer 会通过 redis 分布式锁确保初始化任务只执行一次。若任务已经在其他实例中执行，当前实例跳过该任务。

关键要点

• 在单机环境中，@postconstruct 和 commandlinerunner 等方式已足够满足大多数初始化需求。
• 在分布式环境下，必须确保初始化任务只执行一次，推荐使用基于 redis 的分布式锁来避免重复执行。
• spring 提供的事件机制和 @bean(initmethod) 允许开发者灵活控制任务的执行时机和逻辑，满足复杂业务场景的需求。

通过灵活运用这些技术和方法，开发者可以确保应用启动时的初始化任务高效、安全地执行，避免在多实例环境中产生重复执行的情况。最终，这些方案能够帮助开发者在确保系统稳定性和性能的同时，提高系统的可维护性和扩展性。

以上就是springboot启动后的初始化数据加载原理解析与实战的详细内容，更多关于springboot初始化数据加载的资料请关注代码网其它相关文章！