Spring Boot 冷启动答案

【问题标题】：Spring boot cold startSpring Boot 冷启动
【发布时间】：2026-01-26 12:40:01
【问题描述】：

我有一个 spring boot 应用程序，我在 openshift 集群的 docker 容器中运行。在稳定状态下，应用程序有 N 个实例（例如 N=5），请求被负载平衡到这 N 个实例。一切运行良好，响应时间短（约 5 毫秒，总吞吐量约 60k）。

每当我添加一个新实例时，响应时间都会短暂增加（最多约 70 毫秒），然后恢复正常。

有什么办法可以避免这种冷启动吗？我尝试通过在发送流量之前依次发出约 100 个 curl 调用来预热应用程序，但这没有帮助？

我需要更好的高并发预热脚本吗？有没有更好的方法来处理这个问题？

谢谢

【问题讨论】：

这听起来更像是一个 OpenShift 配置问题。
@chrylis 你能详细说明一下吗？
@Vikk，您也应该详细说明问题本身。你的应用程序是做什么的？我个人会尝试部署一个示例 Spring Boot 应用程序并使用它进行测试。如果发生同样的问题，那么它与 openshift 相关。
可能是 JVM/JIT 预热时间。我猜想延迟类加载 - 进行一堆 curl 调用是一个好的开始 - 或者调用关键代码大约 100 次的 JIT 优化是不够的（默认值：-xx:CompileThreshold=10000afaik）。或者，根据您的应用程序实际执行的操作，可能需要预热缓存
您使用的是预部署的镜像吗？每个实例的内存消耗是多少？你能增加每个节点分配的总内存并进行测试吗？

标签： java spring spring-boot openshift

【解决方案1】：

我们的微服务也遇到了类似的问题，为了预热我们添加了一个组件

ApplicationStartup implements ApplicationListener<ApplicationReadyEvent>

在应用程序启动后立即调用服务，这对我们有用。使用此解决方案，可以保证将在您启动的每个实例中的实例启动后立即加载将在您的有效负载中使用的所有类，并且您不需要外部脚本来进行调用。外部脚本也有问题，我们不能确定调用由新实例处理。

@Component
public class ApplicationStartup implements ApplicationListener<ApplicationReadyEvent> {

    @Autowired
    YourService yourService;

    @Override
    public void onApplicationEvent(final ApplicationReadyEvent event) {

        System.out.println("ApplicationReadyEvent: application is up");
        try {
            // some code to call yourservice with property driven or constant inputs 
        } catch (Exception e) {
            e.printStackTrace();
        }
    }


}

【讨论】：

我认为预热jvm的最佳时间是事件：ContextRefreshedEvent，如果你使用上面的事件。在您完成 jvm 预热之前，您的微服务可能会收到 http 请求。

【解决方案2】：

这个问题可以从两个方面来解决。第一种方法是上菜前先热身。第二种方法是一开始就少给外部的请求，这样可以预留更多的计算资源来完成JVM的一些初始化（比如类加载）。无论哪种方式，都是因为 JVM 需要预热才能启动。这是由JVM的运行原理决定的。特别是HotSpot虚拟机，其执行引擎由解释执行引擎和实时编译执行（JIT）两部分组成。对于 JIT，需要 CPU 资源来实时编译字节码。此外，类的延迟加载在第一次运行时也会需要更多时间。

JVM 预热

JVM预热主要是解决类加载和实时编译这两个问题。

对于类加载，只需提前运行覆盖代码路径即可。
对于JIT来说，C1/C2等分层编译一般在服务器端开启（JVM服务器模式）。如果你使用JDK7或以上版本，默认开启分层编译（JDK低版本需要JVM参数：-XX:+TieredCompilation），C1和C2的编译计算资源不同，C2会有更多。预热的目的可能是触发C1/C2编译，这样当官方请求进来时，代码已经预热编译通过。

对于以上两个方向，类加载本身会消耗更多时间。热身这部分会得到更大的投入产出比。

网络层预热。

从网络层面，给定一定的预热流量，可以是特定的预热流量，也可以是普通的用户请求。

这一般可以在nginx层进行流量控制。当一个新启动的节点加入上游时，可以给新节点一个非常低的权重。这样，在初始阶段只进入了少量的流量。因此，预留了足够的计算资源。做代码预热，即类加载和即时编译。如果服务只提供 RPC 服务，不提供 HTTP 服务，则 RPC 框架层可以做流量预热。例如，Dubbo 等 RPC 框架已经具备服务预热功能。同理，预热意味着启动初期的节点只给少量流量。

上述方法中提到了预热所需的计算资源。也就是CPU。如果您的服务主机有足够的计算资源，您可以为每个节点分配更多的 CPU 资源，以加快预热过程。减少预热处理时间。

如果上述网络层和硬件资源和RPC框架不能改变。我们可以在 SpringBoot 微服务中热身。上面的答案已经提到ApplicationReadyEvent，实际更好的实现是监听ContextRefreshedEvent事件。因为 HTTP 端口会在 ApplicationReadyEvent 发生时被初始化和暴露。在预热完成之前可能会有意外的请求进来。

@Component
public class StartWarmUpListener implements ApplicationListener<ContextRefreshedEvent> {
    /**
     * Handle an application event.
     *
     * @param event the event to respond to
     */
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // do something about warm-up here.....
    }
}

注意：上面的预热代码并没有预热所有代码。因为Controller层的请求有一些代码路径，直到HTTP服务器没有准备好才能真正执行。我们只能在服务层进行代码覆盖。简而言之，这可能是一种妥协。

【讨论】：

【解决方案3】：

如果您的应用程序在您向其提供请求时是健康的，但您仍然遇到响应缓慢的问题，您应该尝试启用分层编译

-XX:CompileThreshold -XX:TieredCompilation

通常，VM 使用解释器来收集有关提供给编译器的方法的分析信息。在分层方案中，除了解释器之外，客户端编译器还用于生成方法的编译版本，这些方法收集有关自身的分析信息。

由于编译代码比解释代码快得多，因此程序在分析阶段以更好的性能执行。

【讨论】：

【解决方案4】：

首先，我会尝试启用JIT compilation 并比较结果。 good article in Baeldung 将 Graal 性能与默认的 C1 和 C2 JIT 编译器进行比较——您可能希望针对您的工作负载运行一些测试。基本上，您需要在运行 Java 应用程序时设置以下选项：

-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler

另外，请确保您已使用 Spring Boot 的执行器健康检查 URL (/actuator/health) configured readiness probe in OpenShift。否则，您的容器可能会在准备好服务之前收到流量。

就绪探测器确定容器是否准备好服务要求。如果就绪探测使容器失败，则端点控制器确保容器的 IP 地址从所有服务的端点。准备就绪探针可用于向端点控制器，即使容器正在运行，它不应接收来自代理的任何流量。设置就绪检查配置 template.spec.containers.readinessprobe 节吊舱配置。

最后，让 NGINX 或其他反向代理缓存您的响应也有帮助。

【讨论】：

【解决方案5】：

在我的场景中，我模拟了 100 多个 curl 请求来初始化这些客户端池、预加载缓存或其他延迟加载。

我在WarmupHealthIndicator implements HealthIndicator 做这项工作，它实现了一个弹簧执行器健康检查端点。

最后它起作用了，在预热完成之前，来自 Nginx（或其他负载均衡器）的任何修复检查都将获得 5xx 状态代码，以及下面的正文消息。并且在状态 up 之后，应用初始化不会花费任何流量。

{
  "status": "DOWN",
  "details": {
    "warmup": {
      "status": "DOWN"
    },
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 536608768000,
        "free": 395195826176,
        "threshold": 10485760
      }
    }
  }
}

此外，NGINX Plus 有一个付费功能slow_start 可以为您的兴趣做同样的事情。

【讨论】：