莱芜网站优化排名手机什么网站可以设计楼房

张

张建站

2026/4/7 16:15:11

10分钟阅读

莱芜网站优化排名,手机什么网站可以设计楼房,淮北论坛招聘最新信息,项目符号SpringBoot启动任务全攻略#xff1a;ApplicationRunner与CommandLineRunner的5个实战场景每次启动一个SpringBoot应用#xff0c;就像启动一台精密的仪器。在仪表盘亮起、核心引擎轰鸣之前#xff0c;总有一些准备工作需要静默完成#xff1a;检查油液、预热系统、加载预…SpringBoot启动任务全攻略ApplicationRunner与CommandLineRunner的5个实战场景每次启动一个SpringBoot应用就像启动一台精密的仪器。在仪表盘亮起、核心引擎轰鸣之前总有一些准备工作需要静默完成检查油液、预热系统、加载预设参数。对于开发者而言这些“启动前准备”就是那些必须在应用完全就绪、开始对外提供服务之前执行的关键任务。无论是从远程配置中心拉取最新的参数还是为缓存系统填充第一批“热数据”亦或是校验数据库连接的健壮性这些操作都关乎着应用启动后的稳定与性能。如果你曾为“代码写在哪里才能在SpringBoot启动时执行”而困扰或者面对CommandLineRunner和ApplicationRunner这两个看似相似的接口不知如何选择那么这篇文章正是为你准备的。我们将绕过枯燥的API文档复述直接深入五个最具代表性的实战场景从配置文件加载、数据库初始化到缓存预热、服务注册与依赖检查手把手展示如何优雅且可靠地利用SpringBoot的启动任务机制。无论你是正在构建微服务架构中的关键组件还是希望优化单体应用的启动体验这里的经验都能让你避开陷阱直抵最佳实践。1. 启动任务基石理解Runner机制与核心差异在深入场景之前我们有必要先厘清SpringBoot为我们提供的这两把“启动钥匙”究竟有何不同。很多开发者初次接触时会有疑惑CommandLineRunner和ApplicationRunner看起来都能在启动后执行代码我该用哪个简单来说它们都是SpringBoot生命周期中的一个特定扩展点允许你在SpringApplication.run()方法执行完毕、应用上下文ApplicationContext刷新完成之后但在应用真正开始接收外部请求例如Tomcat启动完成之前插入自定义的逻辑。这个时机非常关键它意味着所有Bean都已实例化并完成了依赖注入你的任务可以安全地使用任何由Spring管理的组件。两者的核心区别在于它们如何接收和处理应用启动时传入的命令行参数。CommandLineRunner: 提供最原始的访问方式。它的run(String... args)方法直接接收一个字符串数组args这个数组就是public static void main(String[] args)中的那个args。所有参数无论格式如何都被平铺在这个数组里。Component Order(1) public class SimpleCommandLineRunner implements CommandLineRunner { Override public void run(String... args) throws Exception { log.info(应用启动收到原始参数: {}, Arrays.toString(args)); // 参数示例: [--server.port8081, profiledev, file.txt] } }ApplicationRunner: 提供了更结构化、更“Spring风格”的参数访问。它的run(ApplicationArguments args)方法接收一个ApplicationArguments对象。这个对象将参数智能地解析为选项参数Option Arguments: 以--开头通常形如--keyvalue或--key无值。可以通过args.getOptionNames()获取所有选项名再通过args.getOptionValues(“key”)获取对应的值列表ListString。非选项参数Non-option Arguments: 即那些不是以--开头的普通参数。Component Order(2) public class AdvancedApplicationRunner implements ApplicationRunner { Override public void run(ApplicationArguments args) throws Exception { log.info(选项参数名称: {}, args.getOptionNames()); // 例如: [server.port, spring.profiles.active] if (args.containsOption(server.port)) { ListString portValues args.getOptionValues(server.port); log.info(server.port 的值为: {}, portValues.get(0)); } log.info(非选项参数: {}, args.getNonOptionArgs()); // 例如: [profiledev, file.txt] } }提示ApplicationArguments还能方便地判断某个选项是否存在containsOption这对于需要根据启动参数决定执行不同分支逻辑的场景非常有用。如何选择如果你的启动任务完全不需要关心命令行参数或者只需要最原始的、未解析的参数数组那么CommandLineRunner的简洁性更具吸引力。反之如果你的任务逻辑需要基于结构化的启动参数特别是那些--开头的Spring Boot标准参数来做决策ApplicationRunner无疑是更优雅、更强大的选择。在后面的实战场景中我们将看到这两种选择的具体体现。关于执行顺序无论是CommandLineRunner还是ApplicationRunner的实现类都可以通过Order注解或实现Ordered接口来定义执行优先级数值越小优先级越高。Spring会收集所有Runner并按优先级顺序执行。2. 实战场景一动态配置加载与校验在现代应用架构中配置信息很少再硬编码在application.yml里。它们可能来自Apollo、Nacos等配置中心或者需要从特定的文件路径、环境变量中动态读取。应用启动的第一时间确保这些关键配置就位并有效是保障后续所有业务逻辑正常运行的基石。场景描述应用启动时需要从远程配置中心拉取数据库连接池、第三方API密钥等敏感或动态配置并将其注入到Spring环境中。同时需要对一些必需配置项进行校验如果缺失或格式错误则应立即终止启动避免带着“内伤”运行。实现策略这里我们选择ApplicationRunner因为配置中心的地址、命名空间等信息很可能通过--config.server.url这样的选项参数在启动命令中指定。Component Order(10) // 设置较高优先级让配置加载最早执行 Slf4j public class DynamicConfigLoaderRunner implements ApplicationRunner { Autowired private ConfigService configService; // 假设是配置中心客户端Bean Autowired private Environment environment; Override public void run(ApplicationArguments args) throws Exception { log.info(开始执行动态配置加载任务...); // 1. 从启动参数或环境变量获取配置元信息 String appId environment.getProperty(spring.application.name, default-app); String namespace args.containsOption(config.namespace) ? args.getOptionValues(config.namespace).get(0) : application; // 2. 从配置中心拉取配置 Properties remoteConfigs configService.getConfig(appId, namespace); if (remoteConfigs.isEmpty()) { log.warn(未从配置中心获取到任何配置将使用本地默认配置。); } else { // 3. 将配置动态添加到Spring Environment中需通过MutablePropertySources ConfigurableEnvironment configEnv (ConfigurableEnvironment) environment; MutablePropertySources propertySources configEnv.getPropertySources(); PropertiesPropertySource remotePropertySource new PropertiesPropertySource(remoteConfig, remoteConfigs); propertySources.addFirst(remotePropertySource); // 添加到最前拥有最高优先级 log.info(成功加载并注入 {} 条远程配置。, remoteConfigs.size()); } // 4. 关键配置校验 validateRequiredConfigs(); } private void validateRequiredConfigs() { String[] requiredKeys {datasource.url, redis.host, api.secret}; ListString missingKeys new ArrayList(); for (String key : requiredKeys) { if (!environment.containsProperty(key) || StringUtils.isEmpty(environment.getProperty(key))) { missingKeys.add(key); } } if (!missingKeys.isEmpty()) { log.error(应用启动失败以下必需配置项缺失或为空: {}, missingKeys); // 抛出异常终止Spring Boot应用启动 throw new IllegalStateException(缺失必需配置: String.join(, , missingKeys)); } log.info(所有必需配置校验通过。); } }这个Runner确保了在任何一个业务Bean尝试使用datasource.url之前该配置已经准备就绪且有效。Order(10)保证了它在其他可能依赖这些配置的启动任务之前执行。3. 实战场景二数据库初始化与基线数据准备并非所有数据库迁移都适合用Flyway或Liquibase这类工具管理。有时我们需要在应用启动时执行一些轻量级的初始化SQL或者为某些查找表如国家代码、系统角色插入基线数据。特别是在开发、测试环境或者容器化部署的初始化阶段这种需求很常见。场景描述应用启动后检查特定表是否存在或是否为空如果为空则执行初始化SQL脚本或通过JPA Repository插入预设的基线数据。实现策略由于不依赖复杂的启动参数我们可以使用更简洁的CommandLineRunner。重点在于确保数据库连接池已初始化并且事务管理可用。Component Order(20) // 在配置加载之后执行 Slf4j Transactional // 确保数据操作在事务内进行 public class DatabaseInitializationRunner implements CommandLineRunner { Autowired private JdbcTemplate jdbcTemplate; // 用于执行原生SQL检查 Autowired private SystemParamRepository systemParamRepository; // JPA Repository Override public void run(String... args) throws Exception { log.info(开始数据库初始化检查...); // 场景1检查并创建基础表如果不存在 initializeTableIfNotExists(); // 场景2为系统参数表准备基线数据 initializeBaselineData(); } private void initializeTableIfNotExists() { String checkTableSql SELECT COUNT(*) FROM information_schema.tables WHERE table_schema DATABASE() AND table_name sys_config; Integer count jdbcTemplate.queryForObject(checkTableSql, Integer.class); if (count null || count 0) { log.warn(表 sys_config 不存在开始创建...); String createTableSql CREATE TABLE sys_config ( id BIGINT AUTO_INCREMENT PRIMARY KEY, config_key VARCHAR(255) NOT NULL UNIQUE, config_value TEXT, remark VARCHAR(500), created_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; ; jdbcTemplate.execute(createTableSql); log.info(表 sys_config 创建成功。); } } private void initializeBaselineData() { // 检查系统默认角色是否存在 if (systemParamRepository.findByConfigKey(system.default.role).isEmpty()) { SystemParam defaultRole new SystemParam(); defaultRole.setConfigKey(system.default.role); defaultRole.setConfigValue(GUEST); defaultRole.setRemark(新用户默认角色); systemParamRepository.save(defaultRole); log.info(已插入系统默认角色基线数据。); } // 可以继续初始化其他基线数据... ListSystemParam baselineParams Arrays.asList( new SystemParam(app.version, 1.0.0, 应用版本), new SystemParam(cache.ttl.global, 3600, 全局缓存TTL秒) ); for (SystemParam param : baselineParams) { systemParamRepository.findByConfigKey(param.getConfigKey()) .orElseGet(() - systemParamRepository.save(param)); } } }注意在生产环境中表结构变更应严格使用专业的数据库迁移工具。这里的初始化逻辑更适用于那些工具不便于管理的、小的静态数据表或者作为迁移工具的一个补充。务必确保Transactional生效使初始化操作具有原子性。4. 实战场景三分布式缓存预热与热点数据加载对于重度依赖缓存如Redis的应用冷启动后缓存命中率为零首批用户请求会直接穿透到数据库可能导致响应延迟飙升甚至拖垮数据库。缓存预热就是在应用启动后、流量涌入前主动将预计会被高频访问的数据加载到缓存中。场景描述识别出热点数据如首页商品列表、城市字典、热门文章等在启动时批量查询并存入缓存设置合理的过期时间。实现策略这个任务通常不依赖启动参数但执行可能较耗时。我们使用CommandLineRunner并考虑异步执行以避免阻塞主线程如果预热不是后续服务启动的绝对前提。这里展示同步预热。Component Order(30) // 在数据库初始化之后执行 Slf4j public class CacheWarmUpRunner implements CommandLineRunner { Autowired private RedisTemplateString, Object redisTemplate; Autowired private ProductService productService; // 业务服务 Autowired private CityService cityService; Override public void run(String... args) throws Exception { log.info(开始缓存预热任务...); long startTime System.currentTimeMillis(); // 1. 预热首页热门商品 warmUpHotProducts(); // 2. 预热城市级联数据通常读多写少非常适合预热 warmUpCityData(); // 3. 预热其他静态字典数据 warmUpDictionaries(); long duration System.currentTimeMillis() - startTime; log.info(缓存预热任务完成总耗时: {} ms, duration); } private void warmUpHotProducts() { try { ListProductDTO hotProducts productService.getHotProducts(50); // 获取前50个热门商品 String cacheKey cache:product:hot_list; // 使用Redis的List或String结构存储这里示例用Value序列化 // 实际可能用更合适的结构如Sorted Set存储带分数的商品 redisTemplate.opsForValue().set(cacheKey, hotProducts, 10, TimeUnit.MINUTES); // 10分钟过期 log.info(已预热热门商品数据数量: {}, hotProducts.size()); } catch (Exception e) { log.error(预热热门商品缓存失败但不阻断启动流程, e); } } private void warmUpCityData() { // 假设城市数据以树形结构存储我们预热完整的省市区数据 ListCityVO fullCityTree cityService.getFullCityTree(); String cacheKey cache:system:city_tree; // 城市数据变更不频繁可以设置较长的过期时间或不过期通过后台更新缓存 redisTemplate.opsForValue().set(cacheKey, fullCityTree, 1, TimeUnit.HOURS); log.info(已预热城市树形数据。); } private void warmUpDictionaries() { // 例如订单状态、支付方式等枚举字典 MapString, ListDictVO allDicts new HashMap(); allDicts.put(order_status, getOrderStatusDict()); allDicts.put(payment_type, getPaymentTypeDict()); redisTemplate.opsForHash().putAll(cache:system:dicts, allDicts); redisTemplate.expire(cache:system:dicts, 2, TimeUnit.HOURS); log.info(已预热系统字典数据包含 {} 个分类。, allDicts.size()); } // ... 获取字典数据的具体方法省略 }缓存预热的关键在于识别真正的热点数据避免无差别地加载大量可能用不到的数据反而浪费内存和网络带宽。预热操作应具备容错性单个缓存项加载失败不应导致整个启动任务失败。5. 实战场景四服务注册与健康状态上报在微服务架构中服务实例启动后需要向服务注册中心如Nacos、Eureka进行注册并可能向监控系统上报一个初始的健康状态或元数据。虽然Spring Cloud组件通常会自动处理注册但有时我们需要在注册前后执行一些自定义逻辑。场景描述在服务向注册中心注册之后执行一些依赖检查如验证下游关键服务是否可达并将检查结果作为元数据上报。或者在特定条件下如依赖服务不可用决定是否允许服务注册成功。实现策略这需要更精细的生命周期控制。我们可以利用ApplicationRunner或CommandLineRunner但要注意Spring Cloud的ServiceRegistry自动注册可能发生在Runner执行之前或之后这取决于Bean的初始化顺序。更可靠的做法是监听WebServerInitializedEvent表示内嵌Web服务器已启动等事件。但为了演示Runner的用法我们假设在Runner中执行一些注册后的补充操作。Component Order(40) // 在核心资源DB Cache初始化之后流量进入之前执行 Slf4j public class ServiceRegistrationPostProcessor implements ApplicationRunner { Autowired private DiscoveryClient discoveryClient; // Spring Cloud 抽象 Autowired private RestTemplate restTemplate; Value(${spring.application.name}) private String appName; Override public void run(ApplicationArguments args) throws Exception { log.info(执行服务注册后置处理...); // 1. 验证自身关键依赖如数据库、核心中间件是否真正就绪 if (!isCoreDependencyHealthy()) { log.error(核心依赖健康检查未通过服务可能无法正常工作。); // 此处可以触发告警但通常不终止JVM因为注册可能已完成。 } // 2. 向监控系统上报启动事件或自定义元数据 reportStartupToMonitor(); // 3. (可选) 在特定环境下自动触发一个首次就绪检查 if (args.containsOption(enable.self.ready.check)) { performSelfReadinessProbe(); } } private boolean isCoreDependencyHealthy() { // 这里可以进行一些轻量级的连通性测试而非在HealthIndicator中做的深度检查 try { // 示例检查一个核心API是否可访问 ResponseEntityString response restTemplate.getForEntity(http://internal-core-service/health/ping, String.class); return response.getStatusCode().is2xxSuccessful() pong.equalsIgnoreCase(response.getBody()); } catch (Exception e) { log.warn(核心依赖健康检查失败: {}, e.getMessage()); return false; } } private void reportStartupToMonitor() { // 模拟向监控系统发送启动事件 MapString, Object event new HashMap(); event.put(service, appName); event.put(timestamp, Instant.now().toString()); event.put(instanceId, discoveryClient.getServices()); // 简单示例 event.put(metadata, Map.of(startupPhase, post-registration)); log.info(上报启动事件至监控系统: {}, event); // 实际调用监控系统API: monitorClient.reportEvent(event); } private void performSelfReadinessProbe() { log.info(执行自我就绪检查...); // 模拟调用自身的一个就绪端点 String selfUrl http://localhost:${server.port}/actuator/health/readiness; // 使用RestTemplate或WebClient调用自身验证是否已完全就绪 // 如果失败可以记录更详细的日志或采取其他行动 } }这个场景展示了Runner可以作为服务启动流程中的一个“钩子”用于执行那些需要在所有Bean就绪后、但业务流量到来前完成的最终检查和状态上报任务。它补充了自动注册机制增加了自定义控制层。6. 实战场景五异步任务引擎的初始化与队列清理许多应用使用异步处理来提高响应速度例如使用Async、线程池、或消息队列RabbitMQ、Kafka。在应用重启时可能需要初始化线程池、清理上次运行残留的临时状态或者重新订阅消息队列。场景描述启动时初始化一个自定义的、复杂的线程池清理Redis中遗留的、属于上次运行实例的分布式锁键或者确保消息队列的消费者组处于正确的偏移量位置。实现策略这类任务通常涉及资源清理和状态重置适合在应用“崭新”启动时一次性完成。我们使用CommandLineRunner。Component Order(50) // 放在最后执行确保其他业务Bean都已初始化 Slf4j public class AsyncSystemInitializerRunner implements CommandLineRunner { Autowired private RedisTemplateString, String redisTemplate; Autowired private TaskScheduler taskScheduler; // Spring管理的调度器 Value(${spring.application.name}:${server.port}) private String appInstanceId; Override public void run(String... args) throws Exception { log.info(初始化异步任务系统...); // 1. 清理旧的分布式锁防止上次实例异常退出导致锁未释放 cleanStaleDistributedLocks(); // 2. 初始化自定义后台任务线程池如果Spring配置不够灵活 initializeCustomThreadPool(); // 3. 启动一个内务管理定时任务例如每10分钟打印线程池状态 scheduleHousekeepingTask(); } private void cleanStaleDistributedLocks() { String lockPattern lock:*: appInstanceId.split(:)[0] *; // 匹配本应用持有的锁 SetString oldLockKeys redisTemplate.keys(lockPattern); if (oldLockKeys ! null !oldLockKeys.isEmpty()) { log.info(发现可能陈旧的锁键准备清理: {}, oldLockKeys); // **注意这里直接删除有风险更安全的做法是检查锁的值/过期时间。 // 理想情况应使用Redisson等库的看门狗机制或设置合理的过期时间让锁自动失效。 // 此处仅为演示启动时清理的思路。** redisTemplate.delete(oldLockKeys); log.info(已清理 {} 个潜在的陈旧锁键。, oldLockKeys.size()); } } private void initializeCustomThreadPool() { // 假设我们需要一个专门用于CPU密集型计算的线程池与Spring默认的区分开 ThreadPoolExecutor cpuIntensivePool new ThreadPoolExecutor( 4, // 核心线程数约等于CPU核心数 8, // 最大线程数 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), new ThreadFactoryBuilder().setNameFormat(cpu-intensive-pool-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() // 饱和策略 ); // 将线程池暴露为Bean或存入静态工具类供特定服务使用 ThreadPoolManager.registerPool(cpuIntensive, cpuIntensivePool); log.info(CPU密集型线程池初始化完成: core{}, max{}, 4, 8); } private void scheduleHousekeepingTask() { taskScheduler.scheduleAtFixedRate(() - { ThreadPoolExecutor pool ThreadPoolManager.getPool(cpuIntensive); if (pool ! null) { log.debug(线程池状态 - 活跃线程: {}, 队列大小: {}, 完成任务: {}, pool.getActiveCount(), pool.getQueue().size(), pool.getCompletedTaskCount()); } }, Duration.ofMinutes(10)); // 每10分钟执行一次 log.info(内务管理定时任务已调度。); } }这个Runner扮演了“系统管理员”的角色负责在启动时搭建好异步处理的舞台并打扫干净上次演出留下的“痕迹”。它强调了启动任务不仅关乎“建设”也关乎“清理”和“准备”确保应用以一个干净、稳定的状态迎接流量。经过这五个场景的拆解你会发现ApplicationRunner和CommandLineRunner远不止是执行一段启动代码那么简单。它们是连接SpringBoot应用生命周期与业务初始化需求的桥梁。选择哪一个取决于你对启动参数的需求而如何用好它们则考验着你对于应用启动阶段各种依赖和顺序的理解。在实际项目中我常常会为不同的初始化任务定义多个Runner并通过Order清晰地规划出一条启动流水线这让启动过程变得清晰、可控且易于维护。下次当你需要在SpringBoot启动时做点什么不妨先想想它属于上面哪个场景或者能否拆解成一条由多个Runner构成的初始化链条。