Spring Boot 4 启动流程基于 SpringApplication.run() 入口，涵盖环境准备、容器创建、刷新及自动配置。核心涉及 spring.factories 扩展加载、AOT 提前编译优化、类加载器双亲委派机制及内嵌服务器启动。文章解析了从推断应用类型到发布就绪事件的生命周期，对比了新旧版本差异，并提供了 JDK 选型建议。
本文根据 Spring Boot 3/4 的源代码，针对 Spring Boot 核心启动流程进行了总结梳理。
Spring Boot 3/4 的启动核心在于自动化配置与事件驱动。它通过 SpringApplication.run() 入口，利用 spring.factories、AutoConfiguration、SPI、AOT 等加载扩展点。流程历经环境准备、容器刷新（含自动配置与条件化装配）、内嵌 Web 服务器启动，最后通过 Runner 回调完成就绪，全程由事件发布 - 监听机制串联。
即执行 SpringApplication 的构造函数。
WebApplicationType.deduceFromClasspath() 推断
Reactive 相关包，推断为 响应式应用Servlet 相关包，推断为普通应用SpringFactoriesLoader 机制，读取 META-INF/spring.factories 文件
ApplicationContextInitializer（上下文初始化器）ApplicationListener（事件监听器）SpringApplication 的 deduceMainApplicationClass
这是 Spring Boot 实现自动配置扩展的关键机制 AnnotationConfigServletWebServerApplicationContextstatic WebApplicationType deduceFromClasspath() {
if (ClassUtils.isPresent(WEBFLUX_INDICATOR_CLASS, null) && !ClassUtils.isPresent(WEBMVC_INDICATOR_CLASS, null) && !ClassUtils.isPresent(JERSEY_INDICATOR_CLASS, null)) {
return WebApplicationType.REACTIVE;
}
for (String className : SERVLET_INDICATOR_CLASSES) {
if (!ClassUtils.isPresent(className, null)) {
return WebApplicationType.NONE;
}
}
return WebApplicationType.SERVLET;
}
调用 SpringApplication.run(YourApp.class, args) 时，真正的启动流程开始了。这个过程主要包含以下几个核心步骤。
Startup 来记录启动耗时Environment 对象（如 StandardServletEnvironment）。
application.properties 或 application.yml 配置文件。@Value 等注解读取。ApplicationContext 实例【WEB 是 AnnotationConfigServletWebServerApplicationContext】。Environment 关联到容器中，执行 ApplicationContextInitializer 的初始化逻辑。@ComponentScan 扫描路径，将带有 @Component、@Service、@Controller 等注解的类解析为 BeanDefinition，注册到 BeanFactory 中。@EnableAutoConfiguration 导入 AutoConfigurationImportSelector。spring.factories 加载大量的 xxxAutoConfiguration 类。@ConditionalOnXXX 注解，根据类路径下的依赖（比如是否有 Redis 的 jar 包）来决定是否要创建对应的 Bean（比如 RedisTemplate）。这就是'开箱即用'的原理CommandLineRunner 和 ApplicationRunner 接口的 Bean 的 run 方法。这通常用于在应用启动后执行一些特定的逻辑（如预热缓存、打印启动完成日志等）。ApplicationReadyEvent 事件，标志着应用已经准备好接收外部请求了。| 阶段 | 关键动作 | 核心组件/概念 |
|---|---|---|
| 1. 推断与加载 | 推断应用类型，加载初始化器和监听器 | SpringFactoriesLoader, WebApplicationType |
| 2. 环境准备 | 加载配置文件、环境变量，创建 Environment | ConfigurableEnvironment, PropertySources |
| 3. 容器创建 | 根据类型创建 ApplicationContext | ApplicationContext |
| 4. 刷新容器 | 核心：准备上下文、注册 Bean、启动 Web 服务器 | refreshContext(), onRefresh() |
| 5. 自动配置 | 扫描组件、加载 spring.factories 中的自动配置类 | @EnableAutoConfiguration, @Conditional |
| 6. 启动完成 | 执行 Runner，发布就绪事件 | CommandLineRunner, ApplicationReadyEvent |
在 Spring Boot 的启动过程中，'加载工厂配置'（即加载 META-INF/spring.factories）是一个非常基础且高频的操作。为了保证启动性能和运行时效率，Spring 框架在这一过程中设计了非常精妙的缓存机制。
加载工厂配置主要由 SpringFactoriesLoader 这个类负责。它的主要工作是从类路径（classpath）下的所有 jar 包中，搜寻 META-INF/spring.factories 文件，并将其解析为 Map<String, List<String>> 的结构。
spring.factories 借鉴了 SPI 的'思想'（即'约定优于配置'，通过配置文件让框架自动发现扩展实现），但在实现手段上完全重写，以适应 Spring Boot 的快速启动和条件化配置需求。
Spring Boot 通过 ClassLoader 级别的静态缓存 和 JDK 资源定位缓存，确保了 spring.factories 这种关键配置文件在应用生命周期内只被读取和解析一次，极大地提升了启动速度。
对资源加载过程的完全镜像缓存，标志着 Spring 框架在模块化和云原生支持上迈出了关键一步，为了适应云原生和动态化而进化的结果，更好的支持 Java Platform Module System (JPMS) 和 GraalVM Native Image。
Map<ClassLoader, Map<resourceLocation, Factories>> 缓存,Map<FactoryInterface, List<factoryImplClassName>>spring.factories 文件内的原始键值对| 特性 | Java SPI (JDK 原生) | Spring Factories (Spring Boot) |
|---|---|---|
| 配置文件路径 | META-INF/services/ | META-INF/spring.factories |
| 配置文件格式 | 纯文本，每行一个实现类全限定名 | Properties 格式 (Key=Value)，支持多 Key |
| 加载工具类 | java.util.ServiceLoader | org.springframework.core.io.support.SpringFactoriesLoader |
| 加载机制 | 懒加载 (Lazy Loading)，利用 Iterator | 饿汉加载 (Eager Loading)，启动时全量加载 |
| 缓存机制 | 无 (每次获取都是新的迭代器) | 有 (基于 ClassLoader 的静态缓存) |
| 实例化时机 | 获取时实例化 (On-Demand) | 启动时或获取时批量实例化 |
| 条件化支持 | 无 (只要配置了就会加载) | 有 (配合 @Conditional 注解) |
Spring Boot 3.x 以上版本利用 Java（Java 9+）的特性来优化底层性能。
StackWalker 高效遍历调用栈，RETAIN_CLASS_REFERENCE 选项使得直接获取 Class 对象成为可能@Component、@Service 等注解了private Class<?> deduceMainApplicationClass() {
try {
StackTraceElement[] stackTrace = (new RuntimeException()).getStackTrace();
for (StackTraceElement stackTraceElement : stackTrace) {
if ("main".equals(stackTraceElement.getMethodName())) {
return Class.forName(stackTraceElement.getClassName());
}
}
} catch (ClassNotFoundException e) {
}
return null;
}
private @Nullable Class<?> deduceMainApplicationClass() {
return StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).walk(this::findMainClass).orElse(null);
}
private Optional<Class<?>> findMainClass(Stream<StackFrame> stack) {
return stack.filter((frame) -> Objects.equals(frame.getMethodName(), "main")).findFirst().map(StackWalker.StackFrame::getDeclaringClass);
}
| 特性 | 旧方式 (new RuntimeException()) | 新方式 (StackWalker) |
|---|---|---|
| 原理 | 创建一个异常对象，利用其填充的堆栈信息 | 使用 JVM 原生的堆栈遍历 API |
| 性能 | 较差。需要生成完整的堆栈数组，涉及大量的字符串操作和对象创建，对 GC 有压力。 | 优秀。支持惰性加载，不需要一次性拷贝整个堆栈，内存友好，速度快。 |
| 功能 | 只能获取堆栈信息的快照。 | 可以按需获取类引用（配合 RETAIN_CLASS_REFERENCE）。 |
| 适用性 | 适用于所有 Java 版本。 | 仅适用于 Java 9+。 |
AutoConfiguration 如何加载？针对 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 加载发生在 Spring Boot 启动流程的 准备环境之后、刷新容器之前。
SpringApplication.run()@SpringBootApplication 注解时，由于它组合了 @EnableAutoConfiguration，进而触发了自动配置机制加载逻辑的核心执行者。它的调用链路如下：
**@EnableAutoConfiguration** 注解上标注了 @Import(AutoConfigurationImportSelector.class)。@Import 注解时，会调用 AutoConfigurationImportSelector 的 内部 类 AutoConfigurationGroup 的 process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector) 方法。process() 方法，负责去查找并读取 AutoConfiguration.imports 文件。这种方式比 spring.factories 更快，因为它不需要解析键值对（Key-Value），只需要按行读取类名，且避免了 spring.factories 的全量反射扫描。
AutoConfigurationEntry autoConfigurationEntry = autoConfigurationImportSelector.getAutoConfigurationEntry(annotationMetadata);
protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {
if (!isEnabled(annotationMetadata)) {
return EMPTY_ENTRY;
}
AnnotationAttributes attributes = getAttributes(annotationMetadata);
List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
configurations = removeDuplicates(configurations);
Set<String> exclusions = getExclusions(annotationMetadata, attributes);
checkExcludedClasses(configurations, exclusions);
configurations.removeAll(exclusions);
configurations = getConfigurationClassFilter().filter(configurations);
fireAutoConfigurationImportEvents(configurations, exclusions);
return new AutoConfigurationEntry(configurations, exclusions);
}
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, @Nullable AnnotationAttributes attributes) {
ImportCandidates importCandidates = ImportCandidates.load(this.autoConfigurationAnnotation, getBeanClassLoader());
List<String> configurations = importCandidates.getCandidates();
Assert.state(!CollectionUtils.isEmpty(configurations), "No auto configuration classes found in " + "META-INF/spring/" + this.autoConfigurationAnnotation.getName() + ".imports. If you " + "are using a custom packaging, make sure that file is correct.");
return configurations;
}
META-INF/spring.factories 加载对比| 特性 | META-INF/spring.factories | META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports |
|---|---|---|
| 核心用途 | SPI 扩展机制：用于加载框架扩展点（Initializer, Listener）和旧版自动配置。 | 自动配置专用：仅用于加载 @EnableAutoConfiguration 对应的配置类。 |
| 加载时机 | 早：SpringApplication 构造器阶段。 | 晚：SpringApplication.run() 刷新容器阶段（解析 @Import 时）。 |
| 加载驱动 | SpringFactoriesLoader：主动扫描类路径下的所有该文件并合并。 | ImportCandidates / AutoConfigurationImportSelector：被动响应 @EnableAutoConfiguration 的导入需求。 |
| 触发条件 | 只要创建 SpringApplication 实例就会加载。 | 必须在配置类上标注 @EnableAutoConfiguration（或 @SpringBootApplication）才会加载。 |
| 底层原理 | 基于 ClassLoader.getResources() 的全量扫描。 | 基于 @Import 注解的条件化导入。 |
Spring Boot 利用标准 SPI 主要是为了打破'双亲委派'加载机制，解决 '父 ClassLoader 加载的类需要调用子 ClassLoader 加载的实现' 这一难题。
/META-INF/services/java.sql.Driver 文件org.slf4j.spi.SLF4JServiceProvider 配置Spring Boot 使用标准 SPI (META-INF/services) 主要是为了兼容底层 Java 规范（如 JDBC、Servlet）或第三方标准如 BlockHound 框架以及解决类加载器的隔离问题；而使用 spring.factories 是为了实现 Spring 应用层面的自动化配置。
双亲委派机制的核心解决方案：规定类加载器加载类时，优先委派给父类加载器，只有父类加载器无法加载时，才由当前类加载器自行加载。其核心价值体现在三点：
层级顺序：启动类加载器 BootstrapClassLoader → 扩展类加载器 ExtClassLoader → 应用程序类加载器 AppClassLoader → 自定义类加载器（自上而下，父加载器在上）
在标准的双亲委派机制下，类加载器的层级是单向的：子加载器可以访问父加载器加载的类，但父加载器无法访问子加载器加载的类。
需隔离多个 Web 应用的类（避免冲突），同时共享公共依赖（如 Spring），采用自定义加载器（如 WebAppClassLoader）绕过双亲委派。
Java Naming and Directory Interface 启动类加载器需加载用户实现的接口（如 JNDI 服务）。
Thread.setContextClassLoader()）让父加载器请求子加载器完成加载rt.jar 加载）需动态加载数据库驱动（如 mysql-connector.jar），依赖线程上下文类加载器打破委派链解决的问题：
rt.jar）中定义了 java.sql.Driver 接口，这个接口由启动类加载器（Bootstrap ClassLoader）加载。com.mysql.cj.jdbc.Driver）是由第三方提供的（放在应用的 classpath 中），只能由应用程序类加载器（App ClassLoader）加载。线程上下文 ClassLoader 是 java.lang.Thread 类的一个实例变量（contextClassLoader），如果没有手动设置，线程会继承其父线程的上下文类加载器，在应用程序运行的初始线程（main 线程）中，这个值默认就是应用程序类加载器（App ClassLoader）。
使用上下文类加载器的流程（以 JDBC 为例）：
AppClassLoader。DriverManager（由 BootstrapClassLoader 加载）需要加载驱动。DriverManager 不再用自己的加载器去加载，而是通过 Thread.currentThread().getContextClassLoader() 拿到了 AppClassLoader。DriverManager 使用拿到的 AppClassLoader 去加载 com.mysql...Driver。默认类加载器仅能加载本地文件系统中的.class 文件，若需要加载加密的.class 文件（防止反编译），需自定义类加载器，并重写 loadClass 方法打破双亲委派。
ClassLoader 类，并重写 loadClass 方法（打破委派）或 findClass 方法（遵循委派，仅扩展加载路径）defineClass 方法是关键：将解密后的字节数组转换为 JVM 可识别的 Class 对象，该方法由父类 ClassLoader 提供，不可重写import java.io.ByteArrayOutputStream;
import java.io.FileInputStream;
import java.io.IOException;
// 自定义类加载器：加载加密的.class 文件（示例中加密逻辑简化为'异或解密'）
public class EncryptClassLoader extends ClassLoader {
// 加密/解密密钥（实际开发中需复杂密钥）
private static final byte KEY = 0x99;
// 加密类文件的存储路径
private final String encryptClassPath;
// 构造器：指定加密类路径，父加载器为应用程序类加载器
public EncryptClassLoader(String encryptClassPath) {
super(ClassLoader.getSystemClassLoader());
this.encryptClassPath = encryptClassPath;
}
// 核心方法：加载类（打破双亲委派，优先加载加密类）
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// 1. 检查缓存是否已加载
Class<?> c = findLoadedClass(name);
if (c != null) {
return c;
}
// 2. 打破双亲委派：优先加载自定义路径下的加密类（仅处理 com.example 包下的类）
if (name.startsWith("io.renren")) {
try {
// 加载加密的.class 文件并解密
byte[] classData = loadEncryptClassData(name);
// 定义类（将字节数组转换为 Class 对象）
c = defineClass(name, classData, 0, classData.length);
if (resolve) {
resolveClass(c);
}
return c;
} catch (IOException e) {
// 自定义路径加载失败，再委派给父类加载器
return super.loadClass(name, resolve);
}
}
// 3. 非自定义包的类，遵循双亲委派
return super.loadClass(name, resolve);
}
}
// 加载加密的.class 文件并解密
private byte[] loadEncryptClassData(String className) throws IOException {
// 转换类名到文件路径（com.example.User → com/example/User.class）
String filePath = encryptClassPath + "/" + className.replace(".", "/") + ".class";
try (FileInputStream fis = new FileInputStream(filePath); ByteArrayOutputStream bos = new ByteArrayOutputStream()) {
int b;
while ((b = fis.read()) != -1) {
// 解密：异或运算（加密时也用同样逻辑）
bos.write(b ^ KEY);
}
return bos.toByteArray();
}
}
}
public class CustomClassLoaderTest {
public static void main(String[] args) throws Exception {
// 加密类文件存储路径（本地目录）
String encryptClassPath = "D:/encryptClasses";
// 创建自定义类加载器
EncryptClassLoader encryptClassLoader = new EncryptClassLoader(encryptClassPath);
// 加载加密的 io.renren.User 类
Class<?> userClass = encryptClassLoader.loadClass("io.renren.User");
// 反射创建实例并调用方法
Object user = userClass.newInstance();
userClass.getMethod("sayHello").invoke(user);
// 输出：Hello from encrypted class!
// 验证：应用程序类加载器无法加载加密类（需解密）
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
systemClassLoader.loadClass("io.renren.User"); // 抛 ClassNotFoundException
}
}
Ahead-of-Time，提前编译: Spring Boot 3.0 版本发布后引入的最核心、最具变革性的特性之一。它主要是为了解决传统 Java 应用启动慢和内存占用高的痛点，特别是在云原生和 Serverless 场景下。
核心目标是：让 Spring Boot 应用不再依赖传统的 JVM 运行时解释执行，而是提前把'不确定的'动态逻辑转化为'确定的'静态逻辑。
核心技术组件如下：
传统的 Spring Boot 应用（JIT 模式）启动时，JVM 需要做大量的工作：
@Component, @Service 等注解。@Transactional, @Cacheable 等创建动态代理。application.yml，绑定配置属性。这个过程非常消耗 CPU 和内存，且启动时间长。
Spring Boot AOT 则是在编译阶段（Build Time）就完成了上述大部分工作：
@ComponentScan 扫描包，而是生成一个 BeanFactoryInitializationAotProcessor，在启动时直接注册所有已知的 Bean 定义@ConfigurationProperties 的绑定逻辑生成为直接的 setter 调用，避免运行时使用反射进行属性填充| 维度 | 传统 JIT 模式 (HotSpot) | AOT 模式 (Native Image) |
|---|---|---|
| 启动速度 | 慢（秒级甚至分钟级） | 极快（毫秒级），冷启动通常在 100ms 以内 |
| 内存占用 | 高（需要堆内存存储类元数据、JIT 编译代码） | 极低（降低 40%-60%），不需要 JIT 编译器 |
| 运行时性能 | 预热后性能极高（JIT 优化） | 启动即巅峰（没有预热时间），但极致峰值性能略低于预热后的 JIT |
| 部署包 | JAR 包（包含字节码） | 可执行文件（EXE/Linux 二进制文件，不依赖 JRE） |
在 refreshContext 阶段的 onRefresh() 方法中，Spring Boot 会去寻找 ServletWebServerFactory（如 TomcatServletWebServerFactory）并调用其 getWebServer() 方法，从而启动 Tomcat 并将 Servlet 上下文关联进去。
启动过程如下：
构造 SpringApplication 对象 -> 执行 run() 方法 -> 准备环境 -> 创建容器 -> 刷新容器（执行各种 PostProcessor 和 Listener） -> 发布就绪事件
protected void onRefresh() {
super.onRefresh();
try {
this.createWebServer();
} catch (Throwable ex) {
throw new ApplicationContextException("Unable to start web server", ex);
}
}
public WebServer getWebServer(ServletContextInitializer... initializers) {
Tomcat tomcat = this.createTomcat();
this.prepareContext(tomcat.getHost(), initializers);
return this.getTomcatWebServer(tomcat);
}
Spring Boot 的设计理念之一就是'约定优于配置'，同时提供了非常灵活的扩展机制。ApplicationContextInitializer、ApplicationListener、CommandLineRunner）就像是 Spring Boot 启动流水线上的三个关键检修站，让你可以在不同的阶段介入并执行自定义逻辑。
扩展点的执行顺序是固定的： ApplicationContextInitializer (初始化上下文) → ApplicationListener (监听刷新/环境事件) → CommandLineRunner (最后执行业务)
| 扩展点 | 触发时机 (时间轴) | 核心作用 | 典型应用场景 |
|---|---|---|---|
| ApplicationContextInitializer | 最早 (容器刷新前) | 修改环境或上下文 | 动态添加配置属性、注册 BeanFactoryPostProcessor |
| ApplicationListener | 贯穿全程 (监听事件) | 监听生命周期事件 | 环境准备后读取配置、容器刷新后执行逻辑 |
| CommandLineRunner | 最后 (应用就绪前) | 执行具体的业务代码 | 数据初始化、缓存预热、健康检查 |
这是 Spring 中最强大也最复杂的扩展点之一。它允许你在 Bean 初始化的前后执行自定义逻辑。
postProcessBeforeInitialization: 在 Bean 的 @PostConstruct 或 InitializingBean 之前执行。postProcessAfterInitialization: 在 Bean 初始化之后执行（AOP 代理通常在这里生成）。BeanFactoryPostProcessor 处理的就是 Bean 的'图纸'（即 BeanDefinition）。
BeanDefinition 的配置元数据。当开启懒加载后，Bean 在容器启动时不会被实例化。只有当该 Bean 第一次被注入或被请求时，Spring 才会去创建它。
@Lazy 注解spring:
main:
lazy-initialization: true
| 维度 | 优势 | 劣势/注意 |
|---|---|---|
| 启动时间 | ⬇️ 显著缩短。只加载必要组件，适合大型项目本地调试。 | 无 |
| 运行时性能 | ⚠️ 首次请求变慢。第一次 HTTP 请求处理时间会变长，因为需要触发 Bean 初始化。 | 后续请求不受影响。 |
| 问题排查 | ⚠️ 延迟暴露错误。Bean 创建过程中的错误（如配置错误）不会在启动时抛出，而是在第一次使用时才暴露。 | 不利于'早发现、早解决'，生产环境需谨慎。 |
| 排除机制 | 支持排除。如果开启了全局懒加载，但希望某些核心 Bean 启动时加载，可以使用 @Lazy(false) 或实现 LazyInitializationExcludeFilter。 | 需要额外配置。 |
在软件开发中，开发（dev）、测试（test）和生产（prod）环境的配置（如数据库地址、Redis 密码）通常是不同的。Profile 就是用来实现这种环境隔离的机制，让你无需修改代码即可切换环境。
application.yml：主配置文件（通用配置）。application-dev.yml：开发环境专属配置。application-prod.yml：生产环境专属配置。java -jar myapp.jar --spring.profiles.active=prod-Dspring.profiles.active=devSPRING_PROFILES_ACTIVE=prodapplication.yml 中写死（不推荐用于生产，适合本地开发）。@Profile
Spring Boot 的 IOC（Inversion of Control，控制反转） 容器是整个框架的核心基石。简单来说，它就是一个超级工厂，负责创建、配置和管理你项目中所有 Java 对象（在 Spring 里叫 Bean）。
在 Spring Boot 中，IOC 容器主要由两个核心接口实现:
BeanFactory：基础容器，提供基本的 IOC 功能**ApplicationContext**：BeanFactory 的子接口，功能更强大，也是 Spring Boot 默认使用的容器核心任务只有两步：
代码可看：ConfigurationClassPostProcessor、ConfigurationClassParser、ClassPathBeanDefinitionScanner、ClassPathScanningCandidateComponentProvider、DefaultListableBeanFactory。
Spring Boot 会自动扫描主启动类 @SpringBootApplication 注解上的 @ComponentScan。
@Component、@Service、@Controller、@Repository 或 @Configuration 等注解，就会把这个类的信息提取出来。BeanDefinition（Bean 的定义信息/说明书），注册到一个类似 Map 的结构中等待处理。容器根据 BeanDefinition 开始干活：
newInstance 或 CGLIB）调用类的构造方法，创建出原始的对象（半成品）。@Autowired 或 @Resource 注解的属性。如果有，容器会去池子里找对应的 Bean，通过 setter 方法或字段注入进去。最关键的'加工'环节。对象虽然创建好了，但还没完全准备好对外提供服务。
ApplicationContextAware），容器会把对应的资源（如容器本身）注入进去。postProcessBeforeInitialization：在初始化前执行（比如执行 @PostConstruct 注解的方法）。postProcessAfterInitialization：在初始化后执行。AOP 代理通常在这里产生（比如给你的 Service 加上事务管理）。在实际开发中，经常出现 A Service 依赖 B Service，而 B Service 又依赖 A Service 的情况（循环依赖）。 Spring 使用了三级缓存机制来解决这个问题（仅限于单例 Bean 的 setter 注入）：
singletonObjects）。earlySingletonObjects），此时属性还没填充。singletonFactories）。三级缓存对应 DefaultSingletonBeanRegistry 类中的三个 Map。
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);
private final Map<String, ObjectFactory<?>> singletonFactories = new ConcurrentHashMap<>(16);
解决流程：
Spring 团队在官方文档和博客中明确推荐 Liberica JDK 用于 Spring Native 项目。 Liberica JDK (NIK)。它是 Spring 官方推荐的'最佳拍档'，能帮你省去大量排查构建错误的时间，是目前体验最好的组合。
Liberica 是 Spring 生态的优选方案，在 AOT 和 Native 场景下有加成；Temurin 是'全能选手'，免费且稳定，适合绝大多数场景；标准 OpenJDK 则更多是作为底层技术的基石存在。
| 特性 | Liberica JDK | Eclipse Temurin | 标准 OpenJDK (上游) |
|---|---|---|---|
| Spring Native / AOT (原生镜像) | ⭐⭐⭐⭐⭐ (最强) 官方推荐，深度集成 | ⭐⭐⭐ (中等) 支持良好，但需手动配置 | ⭐⭐ (一般) 通常不直接支持，需转用 GraalVM |
| JVM 模式下的 AOT (启动加速) | ⭐⭐⭐⭐⭐ (优秀) 容器优化好，启动快 | ⭐⭐⭐⭐ (良好) 标准兼容，稳定 | ⭐⭐⭐ (标准) 取决于具体发行商优化 |
| GraalVM 兼容性 | 原生支持 (Liberica NIK) | 需额外安装 GraalVM | 不包含，需切换工具链 |
| 主要优势 | Spring 团队官方推荐，构建 Native 镜像最省心 | 免费、社区中立、广泛兼容、企业级稳定 | 纯粹的参考实现，无额外封装 |
| 适用场景 | Spring Native 开发、Serverless、追求极致启动速度 | 传统微服务、企业级应用、云原生部署 | 学习研究、对发行版无特殊要求 |
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online