在高并发业务场景中，后端开发者最不愿遇到的场景莫过于：新服务上线、扩容实例启动后，一旦承接峰值流量，瞬间出现CPU飙升、内存溢出、接口超时，甚至直接宕机崩溃。很多团队误以为“服务能正常启动就可以承接流量”，却忽略了服务预热这一关键环节——未预热的Spring Boot服务，就像刚启动的汽车直接高速行驶，极易出现故障。

本文基于大厂高并发落地经验，从专业角度拆解Spring Boot服务预热的核心逻辑、常见场景，结合具体实战步骤，提供3种主流预热方案，覆盖单体服务、微服务集群等不同场景，全程干货无冗余，既能帮新手快速掌握预热核心，也能为资深开发者提供优化思路，真正实现“新服务平稳承接大流量，零崩溃上线”。

为什么Spring Boot服务必须做预热？
1.1 未预热服务承接大流量的核心痛点
Spring Boot服务启动后，并非立即具备承接高并发流量的能力，未预热直接承接大流量，会出现四大致命问题，也是导致服务崩溃的核心原因：

其一，JVM初始化未完成。服务启动后，JVM的类加载、JIT编译（即时编译）尚未完成，此时大量请求涌入，会导致JIT编译压力剧增，CPU占用率瞬间拉满，进而引发接口超时；其二，连接池未初始化。数据库连接池、Redis连接池、HTTP连接池等，默认启动时仅初始化少量连接，大流量下会出现“连接耗尽”，导致服务无法正常调用依赖组件；其三，缓存未加载。服务启动后，热点数据未加载到本地缓存或分布式缓存，所有请求直接穿透到数据库，导致数据库压力暴增，进而引发服务级联故障；其四，业务初始化未完成。部分服务启动时会执行初始化操作（如加载配置、初始化定时任务、加载字典数据），未完成时承接流量，会出现业务逻辑异常、数据错乱等问题。

根据大厂运维数据统计，未做预热的Spring Boot服务，在峰值流量下崩溃概率高达83%，而做好预热的服务，崩溃概率可降低至1%以下，且接口响应时间平均优化40%以上。尤其在电商大促、短视频峰值、活动秒杀等场景，服务预热更是不可或缺的前置操作。

1.2 服务预热的核心定义与底层逻辑
很多开发者对服务预热存在认知误区，认为“服务启动后等待几分钟就是预热”，实则不然。服务预热的核心定义是：在服务正式承接生产流量前，通过模拟流量、梯度放量等方式，让服务完成JVM初始化、连接池初始化、缓存加载、业务初始化等操作，逐步提升服务的承载能力，确保其能平稳应对峰值流量的过程。

Spring Boot服务预热的底层逻辑，本质是“循序渐进地给服务施加压力”，让服务在可控范围内完成各项初始化，同时让JVM、连接池、缓存等组件适应流量压力，具体可分为三个阶段：

初始化阶段：服务启动后，优先完成类加载、JIT编译、连接池初始化、缓存加载等核心操作，此时服务仅能处理少量请求，不承接生产流量；
梯度加压阶段：通过模拟流量或灰度放量，逐步增加请求量，让JVM根据请求特征优化JIT编译、连接池动态扩容、缓存命中率提升，逐步提升服务承载能力；
稳定阶段：当服务的CPU、内存、接口响应时间、错误率等指标趋于稳定，且各项初始化操作全部完成，说明预热完成，可正式承接生产流量。

需要注意的是，服务预热并非“一次性操作”，而是贯穿服务生命周期的环节——新服务上线、服务扩容、服务重启、版本更新后，都需要重新进行预热，否则仍有崩溃风险。

1.3 服务预热的适用场景
并非所有Spring Boot服务都需要做复杂的预热操作，结合业务场景和服务规模，以下4种场景必须做预热，否则极易出现崩溃：

高并发场景：接口QPS峰值超过1000，或每秒请求数超过500的服务，如电商订单服务、短视频接口服务、秒杀服务等；
资源密集型服务：需要大量CPU、内存资源的服务，如大数据处理服务、AI推理服务、复杂计算服务，这类服务JVM初始化耗时久，未预热直接承接流量易导致资源耗尽；
微服务集群扩容：当微服务集群因流量峰值扩容新实例时，新实例启动后需预热，避免流量瞬间全部导向新实例，导致新实例崩溃；
服务重启/版本更新后：服务重启或版本更新后，JVM、连接池、缓存等都会重新初始化，即使是低并发服务，也需简单预热，避免启动后立即承接请求出现异常。

而对于低并发、无复杂依赖、无缓存的简单服务（如后台管理系统接口），可简化预热流程，仅需启动后等待1-2分钟，确保初始化完成即可。

1.4 服务预热的核心原则
做好Spring Boot服务预热，需遵循三大核心原则，避免出现“预热无效”或“预热过度”的问题：

原则1：循序渐进，拒绝一次性放量。预热的核心是“梯度加压”，不可将生产流量一次性导向未预热的服务，需从少量流量开始，逐步增加，确保服务有足够的时间完成初始化；

原则2：贴合生产，模拟真实流量。预热时使用的模拟流量，需与生产流量的请求类型、参数分布、QPS峰值趋势一致，否则预热效果会大打折扣，无法应对真实生产流量；

原则3：指标监控，动态调整。预热过程中，需实时监控服务的CPU、内存、接口响应时间、错误率、连接池使用率等指标，根据指标变化调整预热节奏，若出现指标异常，立即停止预热，排查问题后再继续。

1.5 常见预热方案对比
目前Spring Boot服务预热主要有3种主流方案，各有优劣，需结合业务场景、团队技术栈选型，以下是详细对比，帮你快速选择适合自己的方案：

方案一：自定义预热（代码级实现）。核心是通过代码编写预热逻辑，加载缓存、初始化连接池、模拟请求，适用于单体服务、小型微服务集群，优点是灵活可控、无需依赖第三方工具，缺点是开发成本高，需手动维护预热逻辑；
方案二：网关梯度放量（微服务首选）。通过Spring Cloud Gateway、Nginx等网关，将生产流量按比例逐步导向新服务，适用于微服务集群，优点是无需修改服务代码、操作简单，缺点是依赖网关，需配置网关规则；
方案三：第三方工具预热（高并发场景首选）。使用JMeter、Gatling等压力测试工具，模拟生产流量对服务进行梯度加压预热，适用于高并发、大型微服务集群，优点是模拟流量真实、可精准控制压力，缺点是需掌握工具使用方法，配置成本较高。

结合大厂落地经验，推荐选型策略：小型服务选自定义预热，微服务集群选网关梯度放量，高并发核心服务选“网关梯度放量+第三方工具预热”结合，确保预热效果。

具体实战：Spring Boot服务预热3种主流方案
本部分聚焦实战，省略冗余步骤，仅展示核心操作，所有代码和配置可直接复制复用，覆盖自定义预热、网关梯度放量、第三方工具预热3种方案，适配不同业务场景，全程基于Spring Boot 3.2.x（主流稳定版）实现。

2.1 方案一：自定义预热
核心思路：通过Spring Boot的CommandLineRunner或ApplicationRunner接口，在服务启动后执行预热逻辑，包括加载缓存、初始化连接池、模拟请求，实现无依赖、轻量级预热，适用于单体服务或小型微服务。

2.1.1 核心依赖
无需引入额外依赖，仅需使用Spring Boot原生的spring-context依赖（默认已引入），若需模拟HTTP请求，可引入spring-web依赖（Web服务默认已引入）。

2.1.2 具体实现步骤

缓存预热：启动后加载热点数据到本地缓存（如Caffeine），避免请求穿透到数据库；
连接池预热：主动初始化数据库、Redis连接池，确保连接池处于就绪状态；
模拟请求预热：发送少量模拟请求，触发JIT编译，让服务适应请求压力。

import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.LoadingCache;
import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.client.RestTemplate;

import javax.annotation.Resource;
import javax.sql.DataSource;
import java.sql.Connection;
import java.util.concurrent.TimeUnit;

@SpringBootApplication
public class WarmupDemoApplication {

@Resource
private DataSource dataSource; // 数据库连接池
@Resource
private StringRedisTemplate redisTemplate; // Redis连接池
@Resource
private RestTemplate restTemplate; // 模拟HTTP请求

public static void main(String[] args) {
    SpringApplication.run(WarmupDemoApplication.class, args);
}

// 1. 配置本地缓存（Caffeine，热点数据缓存）
@Bean
public LoadingCache<String, String> hotDataCache() {
    return Caffeine.newBuilder()
            .maximumSize(1000) // 缓存最大数量
            .expireAfterWrite(30, TimeUnit.MINUTES) // 过期时间
            .build(key -> loadHotDataFromDb(key)); // 缓存加载逻辑
}

// 从数据库加载热点数据（模拟）
private String loadHotDataFromDb(String key) {
    // 实际场景中从数据库查询热点数据，此处模拟
    if ("hot_product".equals(key)) {
        return "id:1001,name:爆款商品,price:99.00,stock:10000";
    }
    return "";
}

// 2. 自定义预热逻辑（服务启动后执行）
@Bean
public ApplicationRunner warmupRunner(LoadingCache<String, String> hotDataCache) {
    return args -> {
        System.out.println("开始执行服务预热...");

        // 步骤1：缓存预热（加载热点数据）
        warmupCache(hotDataCache);

        // 步骤2：连接池预热（初始化数据库、Redis连接）
        warmupConnectionPool();

        // 步骤3：模拟请求预热（发送10次模拟请求，触发JIT编译）
        warmupSimulateRequest();

        System.out.println("服务预热完成，可承接流量！");
    };
}

// 缓存预热：主动加载热点数据到缓存
private void warmupCache(LoadingCache<String, String> hotDataCache) {
    try {
        // 加载多个热点数据（根据实际业务调整）
        hotDataCache.get("hot_product");
        hotDataCache.get("hot_user");
        hotDataCache.get("hot_order");
        System.out.println("缓存预热完成");
    } catch (Exception e) {
        System.err.println("缓存预热失败：" + e.getMessage());
        throw new RuntimeException("缓存预热失败，服务启动终止");
    }
}

// 连接池预热：初始化数据库、Redis连接
private void warmupConnectionPool() {
    // 数据库连接池预热：获取10个连接，确保连接池初始化完成
    for (int i = 0; i < 10; i++) {
        try (Connection connection = dataSource.getConnection()) {
            if (connection.isValid(1000)) {
                System.out.println("数据库连接池预热，第" + (i+1) + "个连接初始化成功");
            }
        } catch (Exception e) {
            System.err.println("数据库连接池预热失败：" + e.getMessage());
            throw new RuntimeException("数据库连接池预热失败，服务启动终止");
        }
    }

    // Redis连接池预热：执行简单命令，确保连接可用
    try {
        redisTemplate.opsForValue().set("warmup:flag", "success", 10, TimeUnit.MINUTES);
        String flag = redisTemplate.opsForValue().get("warmup:flag");
        if ("success".equals(flag)) {
            System.out.println("Redis连接池预热完成");
        }
    } catch (Exception e) {
        System.err.println("Redis连接池预热失败：" + e.getMessage());
        throw new RuntimeException("Redis连接池预热失败，服务启动终止");
    }
}

// 模拟请求预热：发送模拟请求，触发JIT编译
private void warmupSimulateRequest() {
    // 模拟10次请求（实际场景中可模拟生产常用接口）
    String baseUrl = "http://localhost:8080";
    for (int i = 0; i < 10; i++) {
        try {
            // 模拟查询商品接口
            String productInfo = restTemplate.getForObject(baseUrl + "/product/info?productId=1001", String.class);
            // 模拟创建订单接口（仅测试，不写入真实数据）
            String orderResult = restTemplate.getForObject(baseUrl + "/order/create?productId=1001&userId=10001", String.class);
            System.out.println("模拟请求预热，第" + (i+1) + "次请求成功");
        } catch (Exception e) {
            System.err.println("模拟请求预热失败：" + e.getMessage());
            // 模拟请求失败不终止服务，仅打印日志
        }
    }
}

// 模拟业务接口（实际业务接口无需修改，此处仅用于预热测试）
@Bean
public RestTemplate restTemplate() {
    return new RestTemplate();
}

}
2.1.3 配置优化
为了让预热效果更好，需优化Spring Boot配置文件（application.yml），调整JVM参数、连接池参数，避免预热过程中出现资源瓶颈：

应用配置

spring:

数据库连接池配置（优化连接池初始化参数）

datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/test_db?useUnicode=true&characterEncoding=utf8&serverTimezone=GMT%2B8
username: root
password: 123456
hikari:
minimum-idle: 10 # 最小空闲连接（预热时初始化）
maximum-pool-size: 50 # 最大连接数
connection-timeout: 3000 # 连接超时时间
initialization-fail-timeout: 0 # 初始化失败不终止服务

Redis配置

redis:
host: localhost
port: 6379
password:
lettuce:
pool:
min-idle: 5 # 最小空闲连接
max-active: 20 # 最大活跃连接
max-idle: 10 # 最大空闲连接

JVM参数优化（启动时配置，适配预热）

-Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails

作用：设置堆内存大小，使用G1垃圾收集器，减少GC停顿，提升预热效率

2.1.4 验证预热效果

启动Spring Boot服务，查看日志，若打印“服务预热完成，可承接流量！”，说明预热逻辑执行成功；
查看缓存：通过debug模式，确认hotDataCache中已加载热点数据；
查看连接池：通过数据库客户端（如Navicat）查看连接数，确认已初始化10个空闲连接；
测试接口：启动后立即调用接口，查看响应时间，若响应时间稳定在100ms以内，说明预热有效。

2.2 方案二：网关梯度放量
核心思路：微服务集群中，新服务实例启动后，通过Spring Cloud Gateway配置路由权重，将生产流量按比例逐步导向新实例，实现无代码侵入的梯度预热，适用于Spring Cloud微服务集群（如Spring Cloud Alibaba、Spring Cloud Netflix）。

本实战基于Spring Cloud Gateway 4.1.x（适配Spring Boot 3.2.x），结合Nacos服务注册发现，实现梯度放量预热。

2.2.1 核心依赖

org.springframework.cloud
spring-cloud-starter-gateway

com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery

org.springframework.cloud
spring-cloud-gateway-mvc

2.2.2 具体实现步骤
步骤1：配置Nacos服务注册发现，确保新服务实例能正常注册到Nacos；

步骤2：配置Spring Cloud Gateway路由权重，实现梯度放量；

步骤3：预热完成后，调整权重为100%，让新实例承接全部流量。

（1）Nacos服务注册配置
在新启动的Spring Boot微服务（如order-service）中，配置Nacos注册信息，确保能被Gateway发现：

spring:
application:
name: order-service # 服务名称（与Gateway路由配置一致）
cloud:
nacos:
discovery:
server-addr: localhost:8848 # Nacos地址
group: DEFAULT_GROUP
service: ${spring.application.name}

    # 给新实例添加元数据，标记为“待预热实例”
    metadata:
      warmup: "true"

server:
port: 8081 # 新实例端口（与旧实例端口不同）
（2）Spring Cloud Gateway梯度放量配置
在Gateway服务中，配置路由权重，将流量按比例导向新实例（待预热）和旧实例（已稳定），分三个梯度进行预热：

梯度1：预热初期，新实例承接10%流量，旧实例承接90%流量；

梯度2：预热中期，新实例承接50%流量，旧实例承接50%流量；

梯度3：预热完成，新实例承接100%流量，旧实例下线（或作为备用）。

spring:
application:
name: gateway-service
cloud:
nacos:
discovery:
server-addr: localhost:8848 # Nacos地址
gateway:
discovery:
locator:
enabled: true # 开启服务发现路由
routes:

    - id: order-service-route
      uri: lb://order-service # 路由到order-service服务（Nacos注册的服务）
      predicates:
        - Path=/order/** # 匹配订单服务接口
      filters:
        # 权重路由配置（梯度1：新实例10%，旧实例90%）
        - name: Weight
          args:
            group: order-service-group
            weight: 10 # 新实例权重（待预热）
    # 旧实例路由（权重90%）
    - id: order-service-old-route
      uri: lb://order-service # 同样路由到order-service，通过元数据区分实例
      predicates:
        - Path=/order/**
        - name: Metadata
          args:
            warmup: "false" # 匹配旧实例（未标记预热）
      filters:
        - name: Weight
          args:
            group: order-service-group
            weight: 90 # 旧实例权重

（3）梯度调整与预热验证

梯度1（10%流量）：新实例启动后，富贵论坛APP配置上述权重，观察新实例的CPU、内存、接口响应时间等指标，若指标稳定（CPU<70%，响应时间<200ms，错误率<0.1%），维持10-15分钟；
梯度2（50%流量）：修改Gateway配置，将新实例权重调整为50，旧实例权重调整为50，继续观察指标，维持10-15分钟；
梯度3（100%流量）：若梯度2指标稳定，将新实例权重调整为100，旧实例权重调整为0，预热完成，新实例正式承接全部流量；
验证方法：通过Nacos控制台查看实例状态，通过Gateway日志查看流量分配比例，通过Prometheus（可选）监控服务指标。

2.3 方案三：第三方工具预热
核心思路：使用JMeter（开源、易用）模拟生产真实流量，对新启动的Spring Boot服务进行梯度加压，逐步提升请求量，完成预热，适用于高并发核心服务（如秒杀服务、支付服务），确保服务能应对峰值流量。

本实战基于JMeter 5.6，模拟QPS从100逐步提升到1000的梯度加压，完成服务预热。

2.3.1 前期准备

下载并安装JMeter 5.6（官网下载，无需安装，解压即可使用）；
启动待预热的Spring Boot服务（确保服务已正常启动，无报错）；
梳理生产核心接口（如秒杀接口、查询接口），获取请求参数、请求方式，确保模拟流量与生产一致。

2.3.2 JMeter梯度加压配置
步骤1：创建测试计划，添加线程组（用于控制并发数和加压节奏）；

步骤2：添加HTTP请求，配置待预热的接口信息；

步骤3：添加定时器，实现梯度加压；

步骤4：添加监听器，监控预热过程中的服务指标。

（1）创建线程组

打开JMeter，新建测试计划，命名为“Spring Boot服务预热测试”；
右键测试计划→添加→Threads（Users）→Thread Group，配置如下：

线程数：100（最大并发数，对应QPS 1000）；
Ramp-Up Period（秒）：600（10分钟，实现梯度加压，每秒启动1个线程）；
循环次数：100（确保加压时间足够，完成预热）；
延迟创建线程：勾选（避免一次性创建所有线程，实现梯度启动）。

（2）配置HTTP请求

右键线程组→添加→Sampler→HTTP Request，配置如下：

协议：HTTP；
服务器名称或IP：localhost（待预热服务IP）；
端口号：8080（待预热服务端口）；
请求方式：GET（或POST，根据生产接口调整）；
路径：/seckill/start?productId=1001（生产核心接口，如秒杀接口）；
参数：添加生产接口所需的参数（如productId、userId等），确保与生产一致。

（3）添加定时器
为了模拟真实生产流量的请求频率，添加Constant Throughput Timer（固定吞吐量定时器）：

右键HTTP请求→添加→Timer→Constant Throughput Timer；
配置：Target throughput（per minute）：6000（即每秒100 QPS，可根据预热梯度调整）；
梯度调整：前2分钟设置为600（10 QPS），中间3分钟设置为3000（50 QPS），最后5分钟设置为6000（100 QPS），逐步提升压力。

（4）添加监听器
添加监听器，实时查看预热过程中的接口响应时间、错误率等指标，确保服务稳定：

右键线程组→添加→Listener→View Results Tree（查看请求详情）；
右键线程组→添加→Listener→Summary Report（查看汇总指标，如响应时间、错误率）；
右键线程组→添加→Listener→Aggregate Report（查看聚合指标，如平均响应时间、95%响应时间）。

2.3.3 执行预热与验证

启动JMeter测试计划，开始梯度加压预热，全程监控监听器指标；
预热过程中，同步监控Spring Boot服务的CPU、内存、连接池使用率等指标（可使用JConsole、Prometheus等工具）；
若出现以下情况，立即停止预热，排查问题：

接口错误率超过1%；
平均响应时间超过500ms；
CPU占用率持续超过80%，或内存持续飙升；

预热完成标准：当JMeter加压到目标QPS（如1000 QPS），服务指标稳定（错误率<0.1%，平均响应时间<200ms，CPU<70%），维持10-15分钟，说明预热完成。

2.4 实战避坑指南
结合大厂高并发落地经验，总结4个预热过程中最容易踩的坑，及对应的解决方案，覆盖90%以上的问题：

坑点1：预热时模拟流量与生产不一致，导致预热无效

解决方案：预热时的请求类型、参数分布、QPS趋势，必须与生产一致，避免使用“空请求”“测试参数”，可通过生产日志提取真实请求参数，用于模拟流量；

坑点2：预热时间过短，服务未完成初始化

解决方案：根据服务复杂度调整预热时间，简单服务预热5-10分钟，复杂服务（如大数据、AI服务）预热30-60分钟，高并发核心服务预热1-2小时；

坑点3：忽略JVM参数优化，预热时出现GC频繁

解决方案：预热前优化JVM参数，设置合适的堆内存、元空间大小，使用G1垃圾收集器，减少GC停顿，避免预热过程中因GC频繁导致接口超时；

坑点4：微服务集群预热时，未隔离新实例流量

解决方案：微服务集群预热时，通过网关权重、Nacos元数据等方式，将新实例与旧实例隔离，避免新实例未预热完成就承接大量流量，同时做好熔断降级，防止新实例崩溃影响整个集群。

总结
Spring Boot服务预热，是高并发场景下避免新服务崩溃的关键手段，其核心价值在于“循序渐进地让服务完成初始化，适应流量压力”，本质是“防患于未然”，将服务崩溃风险扼杀在预热阶段。

本文从专业角度解析了服务预热的核心逻辑、适用场景和选型原则，结合实战拆解了3种主流预热方案：自定义预热（单体服务首选，灵活无依赖）、网关梯度放量（微服务集群首选，无代码侵入）、第三方工具预热（高并发场景首选，模拟真实流量），覆盖了不同业务场景的需求，同时给出了实战避坑指南，帮助开发者快速落地预热方案。

需要强调的是，服务预热并非“一劳永逸”，而是一项常态化的运维操作——新服务上线、服务扩容、重启、版本更新后，都需要重新进行预热；同时，预热过程中必须做好指标监控，根据指标变化动态调整预热节奏，避免预热无效或过度预热。

对于后端开发者而言，服务预热不仅是一种技术手段，更是一种“高并发思维”——在高并发场景中，“预防”远比“修复”更重要。做好Spring Boot服务预热，既能提升服务的稳定性和可用性，减少故障排查成本，也能提升用户体验，避免因服务崩溃导致的业务损失。

最后，结合大厂落地经验，建议团队根据自身业务场景，制定标准化的预热流程，将预热纳入服务上线、扩容的必经环节，同时结合熔断降级、限流等机制，构建“预热+容错”的双重保障体系，让Spring Boot服务在高并发场景下平稳运行，杜绝因未预热导致的崩溃问题。

Spring Boot服务预热机制，杜绝大流量下新服务崩溃

应用配置

数据库连接池配置（优化连接池初始化参数）

Redis配置

JVM参数优化（启动时配置，适配预热）

推荐JVM参数（4核8G服务器）：

-Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails

作用：设置堆内存大小，使用G1垃圾收集器，减少GC停顿，提升预热效率

热门文章

最新文章

相关电子书

探索云世界

热门

云计算

大数据

云原生

人工智能

数据库

开发与运维

活动广场

任务中心

训练营

直播

乘风者计划

下载

镜像站

技术资料

Spring Boot服务预热机制，杜绝大流量下新服务崩溃

应用配置

数据库连接池配置（优化连接池初始化参数）

Redis配置

JVM参数优化（启动时配置，适配预热）

推荐JVM参数（4核8G服务器）：

-Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails

作用：设置堆内存大小，使用G1垃圾收集器，减少GC停顿，提升预热效率

热门文章

最新文章

相关电子书