# Petclinic 异步通知与每日就诊提醒：从线程池到虚拟线程的工程演进

```text
旧方案：同步发送提醒 + 默认线程池 + 无界队列
冲突：一个 10 分钟定时任务拖住后续任务，线程膨胀压垮数据库
后果：提醒延迟、连接耗尽、服务雪崩
```

Petclinic 现在每天要提醒宠主带宠物复诊，还要在预约变更后异步发通知。

我是老李，负责把官方教学项目改造成能扛住真实流量的生产级应用。

团队第一版用 `@Scheduled` 直接查库发邮件，结果某天一个慢查询跑了 10 分钟，后面所有提醒全部延迟。

为什么一个执行 10 分钟的定时任务可能拖住后面的任务？

为什么无限增加线程又可能把下游数据库压死？

如果选错线程池或拒绝策略，提醒会丢、数据库会崩，我们该怎么选？

# 01、故事

```text
周一 09:00 → 宠物医院运营部 → 发送每日就诊提醒 → 慢查询拖垮整批任务
```

周一早上九点，运营同事在群里催：今天的复诊提醒还没发出去。

任务是每天上午给所有当天有预约的宠主发提醒，同时异步通知预约变更。

我打开日志，发现定时任务线程卡在一条统计查询上，已经跑了 10 分钟。

后面的提醒任务全部排队，运营群里消息越来越多，数据库连接池也开始告警。

> 晨会群里催声急，
> 慢查一跑全排队。
> 线程池里无空闲，
> 提醒还在数据库。

# 02、问题

```text
需求变化：同步发送 → 每日定时 + 异步通知
冲突：单线程调度 + 共享执行器 + 无界队列
后果：慢任务拖尾、线程膨胀、下游连接耗尽
```

原方案是请求里同步发邮件，现在要改成每天定时批量提醒，还要在预约变更后异步发通知。

失效原因是定时任务和异步通知共用默认执行器，一个慢任务占住线程，后续任务只能排队。

更糟的是，为了缓解排队，有人把线程池调大，结果并发查库把数据库连接池打满。

可验证的验收标准是：单条慢任务不能阻塞其他提醒，数据库并发连接数不超过 20，提醒延迟不超过 30 秒。

> 慢查占线十钟，
> 后队排成长龙。
> 加线程解一时，
> 下游先被打崩。

# 03、原理

```text
调度线程 → 任务队列 → 工作线程池 → 阻塞 I/O → 下游资源
```

Spring Boot 的 `@Scheduled` 默认由单线程 `TaskScheduler` 执行，一个慢任务会阻塞后续所有调度。

`@Async` 默认使用 `SimpleAsyncTaskExecutor`，它不复用线程，每个任务新建线程，高并发下线程数会失控。

线程池的核心参数是核心线程数、最大线程数、队列容量和拒绝策略。

反直觉的是：队列越大，越容易掩盖慢任务，最终导致请求超时和线程堆积。

JDK 21 的虚拟线程由 JVM 调度，阻塞 I/O 时线程会释放载体线程，适合大量阻塞场景。

但虚拟线程不会让 CPU 密集任务自动变快，因为 CPU 核心数没变。

> 单线程调度如独木，
> 慢任务一过全堵住。
> 虚拟线程解阻塞，
> CPU 密集仍有限。

# 04、架构

```text
预约事件 → 异步通知服务 → 专用线程池 → 邮件/短信
定时触发 → 就诊提醒服务 → 批量查询 → 分批发送
```

我们把异步通知和定时提醒拆成两个独立执行器，避免互相干扰。

异步通知用虚拟线程执行器，适合大量阻塞 I/O；定时提醒用固定大小线程池，控制数据库并发。

边界是：定时任务只做查询和发送，不做复杂计算；异步通知不直接查大表，只发已准备好的消息。

收益是慢任务隔离、下游并发可控、线程资源弹性伸缩。

代价是配置复杂度上升，需要监控每个执行器的队列和拒绝次数。

适用条件是阻塞 I/O 占比高、任务量波动大、下游有明确并发上限。

> 两条执行路，
> 各管各的务。
> 慢查不拖尾，
> 并发有定数。

# 05、第一版实战

```text
JDK 21 → Spring Boot 4 → 默认执行器 → @Scheduled + @Async → 验证失败
```

我们使用 JDK 21 和 Spring Boot 4，先按最简方式实现。

在 `PetclinicApplication` 上开启 `@EnableAsync` 和 `@EnableScheduling`。

```java
@SpringBootApplication
@EnableAsync
@EnableScheduling
public class PetclinicApplication {
    public static void main(String[] args) {
        SpringApplication.run(PetclinicApplication.class, args);
    }
}
```

创建 `VisitReminderService`，定时查询当天预约并发送提醒。

```java
@Service
public class VisitReminderService {
    private final VisitRepository visitRepository;
    private final MailService mailService;

    public VisitReminderService(VisitRepository visitRepository, MailService mailService) {
        this.visitRepository = visitRepository;
        this.mailService = mailService;
    }

    @Scheduled(cron = "0 0 9 * * *")
    public void sendDailyReminders() {
        List<Visit> visits = visitRepository.findByDate(LocalDate.now());
        visits.forEach(v -> mailService.sendReminder(v));
    }
}
```

创建 `AppointmentNotificationService`，异步发送预约变更通知。

```java
@Service
public class AppointmentNotificationService {
    @Async
    public void sendChangeNotification(AppointmentEvent event) {
        mailService.send(event);
    }
}
```

启动应用后，手动触发一次慢查询模拟。

```bash
curl -X POST http://localhost:8080/visits/reminders/simulate-slow
```

示例输出显示定时任务线程被占用，后续任务排队。

```text
2025-01-06 09:00:00.123  INFO  scheduling-1 : sendDailyReminders started
2025-01-06 09:10:00.456  INFO  scheduling-1 : sendDailyReminders finished
2025-01-06 09:10:00.457  INFO  scheduling-1 : next reminder started after 10 minutes delay
```

成功标准未达成：慢任务阻塞了后续提醒，延迟超过 30 秒。

> 默认执行器，
> 单线走到底。
> 慢查一占线，
> 后队全延期。

# 06、排查

```text
现象：提醒延迟 → 怀疑单线程调度 → 查线程名 → 确认 scheduling-1 被占
现象：线程膨胀 → 怀疑 SimpleAsyncTaskExecutor → 查线程数 → 确认每任务新建线程
```

第一个问题是提醒延迟。

怀疑是单线程调度被慢任务占用，检查线程名。

```bash
jstack <pid> | grep -A 5 "scheduling"
```

示例输出显示 `scheduling-1` 线程一直处于 RUNNABLE，执行慢查询。

```text
"scheduling-1" #23 prio=5 os_prio=0 tid=0x00007f9a5c001000 nid=0x1a2b runnable
    at org.hibernate.Session.query
    at VisitRepository.findByDate
```

根因是 `@Scheduled` 默认单线程，慢任务占住唯一调度线程。

第二个问题是异步通知线程膨胀。

怀疑是 `SimpleAsyncTaskExecutor` 不复用线程，检查线程数。

```bash
jcmd <pid> Thread.print | grep -c "SimpleAsyncTaskExecutor"
```

示例输出显示线程数随请求线性增长。

```text
SimpleAsyncTaskExecutor-1
SimpleAsyncTaskExecutor-2
...
SimpleAsyncTaskExecutor-500
```

根因是 `@Async` 默认执行器为每个任务新建线程，高并发下线程数失控。

**错误尝试：** 我们曾把 `spring.task.execution.pool.max-size` 调到 200，结果数据库连接池被并发查询打满。

> 查线程名知单线，
> 数线程数见膨胀。
> 调大池子更糟糕，
> 下游先被打穿。

# 07、优化

```text
V1：默认执行器 + 单线程调度 + 无界队列
证据：scheduling-1 被占 10 分钟，SimpleAsyncTaskExecutor 线程数 500+
V2：专用调度线程池 + 虚拟线程异步执行器 + 有界队列
```

我们为定时任务配置专用调度线程池，避免单线程阻塞。

```yaml
spring:
  task:
    scheduling:
      pool:
        size: 4
      thread-name-prefix: petclinic-scheduling-
```

为异步通知配置虚拟线程执行器，并设置有界队列和拒绝策略。

```java
@Configuration
public class AsyncConfig {
    @Bean(name = "notificationExecutor")
    public AsyncTaskExecutor notificationExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setVirtualThreads(true);
        executor.setQueueCapacity(200);
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.setThreadNamePrefix("notification-vt-");
        executor.initialize();
        return executor;
    }
}
```

在 `@Async` 上指定执行器。

```java
@Async("notificationExecutor")
public void sendChangeNotification(AppointmentEvent event) {
    mailService.send(event);
}
```

定时任务改为分批查询，每批 50 条，控制数据库并发。

```java
@Scheduled(cron = "0 0 9 * * *")
public void sendDailyReminders() {
    Pageable page = PageRequest.of(0, 50);
    Page<Visit> visits;
    do {
        visits = visitRepository.findByDate(LocalDate.now(), page);
        visits.forEach(v -> mailService.sendReminder(v));
        page = page.next();
    } while (visits.hasNext());
}
```

> 调度池分四线，
> 异步用虚拟。
> 队列设上限，
> 拒绝不丢弃。

# 08、演进

```text
V2：专用调度池 + 虚拟线程 + 有界队列 + 分批查询
能力：慢任务隔离、线程弹性、下游并发可控
遗留：拒绝策略需监控，虚拟线程 CPU 密集场景无优势
```

用 V1 同一组请求验证：先模拟慢查询，再触发后续提醒。

```bash
curl -X POST http://localhost:8080/visits/reminders/simulate-slow
curl -X POST http://localhost:8080/visits/reminders/trigger-next
```

示例输出显示慢任务在 `petclinic-scheduling-1` 执行，后续提醒在 `petclinic-scheduling-2` 正常启动。

```text
2025-01-06 09:00:00.123  INFO  petclinic-scheduling-1 : slow reminder started
2025-01-06 09:00:01.456  INFO  petclinic-scheduling-2 : next reminder started
2025-01-06 09:00:01.789  INFO  petclinic-scheduling-2 : next reminder finished
```

异步通知线程数不再随请求线性增长，虚拟线程复用载体线程。

```text
notification-vt-1
notification-vt-2
...
notification-vt-20
```

收益是慢任务隔离、线程弹性伸缩、数据库并发控制在 20 以内。

代价是配置复杂度上升，需要监控队列深度和拒绝次数。

遗留问题是 `CallerRunsPolicy` 在队列满时会让调用线程执行任务，可能拖慢主流程。

> 慢查不再拖尾，
> 线程弹性伸缩。
> 并发有了上限，
> 监控还需补全。

# 09、洞见

```text
从现象到判断：慢任务拖尾 → 单线程调度；线程膨胀 → 默认执行器；下游压垮 → 无界并发
```

## 反直觉判断：队列越大越危险
```text
无界队列 → 任务堆积 → 请求超时 → 线程堆积
```

很多人以为队列大能缓冲流量，实际上无界队列会掩盖慢任务，导致请求超时和内存压力。

有界队列配合拒绝策略，才能让系统在过载时快速失败或降级。

## 反直觉判断：虚拟线程不加速 CPU 密集任务
```text
虚拟线程 → 阻塞 I/O 释放载体 → 吞吐提升
虚拟线程 → CPU 密集占用载体 → 吞吐不变
```

虚拟线程的价值在于阻塞 I/O 时释放载体线程，让少量载体线程支撑大量并发。

但 CPU 密集任务会一直占用载体线程，虚拟线程切换反而增加开销。

## 定时任务要分批
```text
全量查询 → 长事务 → 锁表 → 连接占用
分批查询 → 短事务 → 锁释放 → 并发可控
```

定时任务一次查全量数据，容易产生长事务和锁竞争。

分批查询能缩短事务时间，控制数据库并发，避免影响在线业务。

> 队列大藏隐患，
> 虚拟线有边界。
> 分批查控并发，
> 监控才能心安。

# 10、系统落地

```text
入口：预约变更事件、每日定时触发
服务：AppointmentNotificationService、VisitReminderService
本模块：专用调度池 + 虚拟线程执行器 + 有界队列 + 分批查询
存储：MySQL 预约表、邮件发送记录
未实现：分布式调度、消息队列、死信重试
```

原来 Petclinic 只有同步发送邮件，没有定时任务和异步通知。

本篇增加了每日就诊提醒、预约变更异步通知、专用线程池和虚拟线程执行器。

现在能隔离慢任务、控制数据库并发、弹性伸缩阻塞 I/O 线程。

下一篇缺分布式调度和消息队列，单机调度在集群下会重复执行。

官方文档见 Spring Boot 官方文档首页和 GitHub 仓库。

> 从同步到异步，
> 从单线到多线。
> 从无界到有界，
> 从压垮到可控。

# 11、小结

```text
三问三答：慢任务拖尾 → 单线程调度；线程膨胀 → 默认执行器；下游压垮 → 无界并发
```

为什么一个执行 10 分钟的定时任务可能拖住后面的任务？

因为 `@Scheduled` 默认单线程调度，慢任务占住唯一线程，后续任务排队。

为什么无限增加线程又可能把下游数据库压死？

因为线程数增加会放大并发查询，数据库连接池和锁竞争先达到瓶颈。

选错拒绝策略会怎样？

丢弃策略会丢提醒，调用者执行策略会拖慢主流程，需要按业务选择并监控。

当前状态是定时提醒和异步通知已隔离，数据库并发可控，虚拟线程支撑阻塞 I/O。

> 单线调度是根因，
> 无界并发是帮凶。
> 有界队列加监控，
> 虚拟线程解阻塞。

# 12、作业

```text
理解 → 实战 → 排障 → 架构判断
```

## 理解题：为什么虚拟线程不能加速 CPU 密集任务？

虚拟线程由 JVM 调度到少量载体线程上，CPU 密集任务会一直占用载体线程，无法释放。

虚拟线程切换反而增加调度开销，吞吐不会提升，甚至可能下降。

## 实战题：为 Petclinic 配置一个虚拟线程执行器，队列容量 100，拒绝策略为 AbortPolicy，并验证队列满时抛异常。

```java
@Bean(name = "vtExecutor")
public AsyncTaskExecutor vtExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setVirtualThreads(true);
    executor.setQueueCapacity(100);
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
    executor.initialize();
    return executor;
}
```

队列满时提交任务会抛 `TaskRejectedException`，可在日志中验证。

## 排障题：定时任务延迟，但线程池大小已调到 10，如何定位？

先查调度线程名和状态，确认是否被慢任务占用。

```bash
jstack <pid> | grep -A 10 "petclinic-scheduling"
```

再查数据库慢查询日志，确认慢任务根因。

最后查队列深度和拒绝次数，确认是否队列堆积。

## 架构判断题：单机定时任务在集群下会重复执行，是否应该立即引入分布式调度？

不一定。如果重复执行不产生副作用，可以先用单机调度加幂等控制。

如果重复执行会导致重复扣款或重复发送，需要引入分布式调度或分布式锁。

> 理解虚拟边界，
> 实战配置执行。
> 排障查根因，
> 架构看场景。

# 13、升华

```text
工程结论：线程池是资源管理工具，不是性能银弹
```

线程池的核心是隔离和限流，不是无限放大并发。

虚拟线程解决阻塞 I/O 的资源模型问题，但不改变 CPU 密集任务的物理限制。

定时任务要分批、有界、可监控，才能避免拖尾和下游压垮。

下一篇我们将引入分布式调度和消息队列，解决集群下的重复执行和任务可靠性。

> 线程池里藏乾坤，
> 有界队列守城门。
> 虚拟线程解阻塞，
> 分批查库保安稳。

**系列项目：** Petclinic 宠物医院管理系统

**已完成：** 环境搭建、启动机制、依赖与自动配置、配置体系、Web 层、安全、数据访问、事务、远程调用、数据库迁移、缓存、并发、日志、测试、Testcontainers、Docker Compose、Actuator、可观测、自定义自动配置、容器构建

**本篇：** 每日就诊提醒与异步通知，专用调度池、虚拟线程执行器、有界队列、分批查询

**下一篇：** 分布式调度与消息队列，解决集群重复执行和任务可靠性

团队第一版用 @Scheduled 直接查库发邮件，结果某天一个慢查询跑了 10 分钟，后面所有提醒全部延迟。

《SpringBoot4进阶实战》第15招 异步定时和虚拟线程

用真实阻塞 I/O 对比传统线程池与虚拟线程，解决定时任务拖尾与下游压垮问题。

架构师

后端

编程语言

开发工具

从线程池到虚拟线程：Petclinic通过专用调度池隔离慢任务，虚拟线程执行器支撑阻塞I/O，有界队列配合分批查询控制数据库并发，解决提醒延迟与线程膨胀问题。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《SpringBoot4进阶实战》第15招 异步定时和虚拟线程-腾讯云开发者社区-腾讯云

《SpringBoot4进阶实战》第15招异步定时和虚拟线程

《SpringBoot4进阶实战》第15招异步定时和虚拟线程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第15招 异步定时和虚拟线程

《SpringBoot4进阶实战》第15招 异步定时和虚拟线程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第15招异步定时和虚拟线程

《SpringBoot4进阶实战》第15招异步定时和虚拟线程