Go back

异步化改造邮件发送——从同步阻塞2秒到异步立即返回

异步化改造邮件发送：从同步阻塞 2 秒到异步立即返回

一句话结论（30s）

异步化改造的本质是把外部 IO 阻塞从主线程剥离——因为注册接口 97.5% 的耗时都在等待 SMTP 邮件发送，只有让邮件”晚点发”而不是”等着发”，才能把用户体验从 2 秒降到 50ms，但代价是必须补齐线程池配置、事务边界和持久化保障。

核心原理（2min）

底层深入（5-10min）

一个让人抓狂的用户反馈

“你们的注册页面怎么这么慢？点了注册按钮后等了 3 秒才跳转。”

排查日志后发现：

@Service
public class UserService {
    @Transactional
    public void register(UserDTO dto) {
        // 1. 校验 + 写入数据库：50ms
        userDao.insert(user);
        // 2. 发送注册邮件：2000ms（连接 SMTP 服务器 + 发送）
        emailService.sendWelcomeEmail(user.getEmail());
        // 3. 返回结果
    }
}

用户看到的”注册”响应时间 = 50ms（数据库） + 2000ms（邮件） = 2050ms。其中 97.5% 的时间在等待邮件发送——这不是业务逻辑慢，是外部 IO 阻塞了主流程。

思考穿插：为什么说”97.5% 的时间在等邮件”这件事，决定了优化的方向？因为瓶颈根本不在业务逻辑（数据库才 50ms），而在外部 IO 的等待——既然阻塞的是”等待”本身，那么优化思路就不是”让邮件发得更快”，而是”让主线程别等它”，这就把问题从”调优 SMTP”转成了”剥离阻塞”。

异步化：让邮件”晚点发送”而不是”等着发送”

核心思路：主线程写完数据库立刻返回给用户，邮件的发送交给另一个线程去慢慢完成。

@Service
public class UserService {
    @Transactional
    public void register(UserDTO dto) {
        userDao.insert(user);                        // 50ms
        emailService.sendWelcomeEmailAsync(user.getEmail()); // 这里瞬间返回
        // 总耗时：50ms → 用户体验提升 40 倍
    }
}

@Service
public class EmailService {
    @Async
    public void sendWelcomeEmailAsync(String email) {
        // 这个方法的执行被 Spring 委托给线程池中的工作线程
        mailSender.send(createWelcomeEmail(email));  // 2000ms，但在另一个线程
    }
}

用户点击注册 → 50ms 后页面跳转 → 2 秒后邮箱收到邮件。用户感知不到那 2 秒——因为在跳转页面完成时邮件已经在”后台”发送了。

@Async 的完整配置

@Async 注解不是加上就能用的，需要三步：

第一步：启用异步支持

@Configuration
@EnableAsync
public class AsyncConfig {
    // 配置在这里
}

@EnableAsync 会创建一个 AsyncAnnotationBeanPostProcessor，扫描所有 @Async 注解的方法，生成代理对象。没有这个注解，@Async 等于没写。

第二步：配置线程池（核心！）

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);              // 核心线程数
        executor.setMaxPoolSize(10);              // 最大线程数
        executor.setQueueCapacity(100);           // 队列容量
        executor.setRejectedExecutionHandler(
            new ThreadPoolExecutor.CallerRunsPolicy()); // 队列满时主线程执行
        executor.setThreadNamePrefix("async-email-");
        executor.initialize();
        return executor;
    }

    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return (ex, method, params) ->
            log.error("异步方法 {} 执行异常", method.getName(), ex);
    }
}

关键配置解读：

第三步：方法必须是 public + 外部调用

// ❌ 错误：同一个类内部调用 → 不经过代理 → @Async 失效
@Service
public class UserService {
    public void register() {
        this.sendEmail();  // this 调用，不走代理
    }

    @Async
    public void sendEmail() { ... }
}

// ✅ 正确：注入代理对象，跨类调用
@Service
public class EmailService {
    @Async
    public void sendEmail() { ... }
}

@Service
public class UserService {
    @Autowired
    private EmailService emailService;  // 注入的是代理对象

    public void register() {
        emailService.sendEmail();       // 代理调用 → @Async 生效
    }
}

Spring 的 AOP 基于代理。this.sendEmail() 不经过代理 → 切面逻辑不执行 → @Async 不生效。@Async 方法必须放在独立的 Bean 中，通过 Spring 注入的代理对象调用。

思考穿插：为什么 this.sendEmail() 会让 @Async 静默失效，而不是报错？因为 AOP 是”代理增强”，this 是原始对象、根本没过代理，切面代码压根没机会执行——所以它不会报错，只会在你没察觉时悄悄变成同步调用。这也是为什么这类 bug 特别难查：代码看着没问题，行为却完全相反。

虚拟线程执行器：Java 21+ 的更优选择

传统线程池有一个根本问题：发邮件时线程在等待 SMTP 服务器的网络 IO 回复（阻塞），但线程池的线程数是有限的。如果 10 个线程全部在等网络回复，第 11 封邮件就只能排队。

虚拟线程（Virtual Thread）解决了这个问题：虚拟线程阻塞时不占用平台线程——它阻塞了，JVM 就把平台线程释放给其他虚拟线程使用。

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {
    @Override
    public Executor getAsyncExecutor() {
        // Java 21+ 虚拟线程执行器——每个任务一个虚拟线程，无限并发
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}

虚拟线程不需要线程池——创建成本极低（几百字节），阻塞时自动让出底层平台线程。10000 封邮件同时发送？用虚拟线程只需要少量的平台线程（约等于 CPU 核心数）。

Spring Boot 3.2+ 甚至可以直接配置：

spring:
  threads:
    virtual:
      enabled: true  # 全局启用虚拟线程

然后 @Async 默认使用虚拟线程执行器。

风险防范：别让异步变成”丢邮件”

风险一：任务丢失

应用重启时，线程池中排队的任务直接丢失。对于邮件这种”丢了就是事故”的场景，需要持久化。

// 方案：先写数据库（持久化），再异步发送
@Transactional
public void register(UserDTO dto) {
    userDao.insert(user);
    // 持久化邮件任务（不是直接发邮件）
    emailTaskDao.insert(new EmailTask(user.getEmail(), "WELCOME"));
}

// 定时任务扫描未发送的邮件任务
@Scheduled(fixedDelay = 5000)
public void sendPendingEmails() {
    List<EmailTask> tasks = emailTaskDao.findPending();
    for (EmailTask task : tasks) {
        try {
            mailSender.send(createEmail(task));
            emailTaskDao.markSent(task.getId());
        } catch (Exception e) {
            emailTaskDao.incrementRetry(task.getId());
        }
    }
}

这样即使应用重启，邮件任务在数据库中不会丢失。定时任务启动后继续发送。只有持久化了的异步任务才是可靠的异步任务。

风险二：异常被吞

@Async 方法中抛出的异常，如果没配置 AsyncUncaughtExceptionHandler，默认被线程池吞掉——日志里什么都看不到，邮件没发出却无从排查。

@Async
public void sendEmail(String email) {
    try {
        mailSender.send(...);
    } catch (Exception e) {
        log.error("邮件发送失败: {}", email, e);
        // 记录失败，后续重试
        failedEmailDao.insert(new FailedEmail(email, e.getMessage()));
    }
}

@Async 方法内部必须 try-catch 所有异常，不要依赖框架的异常处理。

风险三：事务边界

@Transactional
public void register(UserDTO dto) {
    userDao.insert(user);
    emailService.sendEmailAsync(user.getEmail()); // @Async
}
// 事务提交 ← 此时邮件可能已经发了，也可能还没发

如果 sendEmailAsync 执行时事务还没提交 → 异步线程读到旧数据（或读不到数据）→ 邮件内容错误。解决：

@Transactional
public void register(UserDTO dto) {
    userDao.insert(user);
    // 在事务提交后发布事件（而非事务中）
    eventPublisher.publishEvent(new UserRegisteredEvent(user));
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Async
public void handleUserRegistered(UserRegisteredEvent event) {
    // 事务已提交，可以安全读取用户数据
    emailService.sendWelcomeEmail(event.getUser().getEmail());
}

总结

异步化改造不是加个 @Async 就完事了。完整的改造需要五步：

  1. 方法抽离：把慢操作放到独立 Bean 的 public 方法中，加 @Async
  2. 线程池配好：核心数、队列容量、拒绝策略、异常处理器
  3. 事务隔离：事务提交后再触发异步（@TransactionalEventListener）
  4. 持久化保障：关键任务写数据库 + 定时扫描，防止丢失
  5. 监控告警：异步失败率 > 1% → 告警

思考穿插：为什么一个”加个 @Async”的改动，最后要铺开成五步？因为异步把”即时失败”变成了”延迟失败”——同步发邮件失败，用户当场就报错；异步发邮件失败，用户早已跳转、你根本不知道。收益是快，代价是你必须自己补上可靠性（持久化、重试、监控），否则异步只会把”慢”变成”丢”。

异步化把用户体验从 2 秒降到 50ms——但这 50ms 的代价是架构复杂度的大幅上升。每一个 @Async 都意味着”你要管理一个新的线程生命周期”，想清楚再异步。

章末提问

异步化是高频面试点，对方会顺着”为什么异步、怎么保证不丢”往下追。以下是三个典型追问：

  1. “@Async 为什么不生效了？你排查的思路是什么？” 结论先行：「先查是不是 this 调用没走代理——AOP 基于代理，同类的内部调用绕过了代理对象，切面不执行，@Async 静默失效。」因为 对方在验证你”踩过坑”的真伪——能立刻说出”this 调用绕过代理”这个根因，说明你真正排查过，而不是只背了注解用法。

  2. “异步化之后，邮件任务在应用重启时丢了怎么办？” 结论先行：「先写数据库持久化邮件任务，再由定时任务扫描发送，失败重试——只有持久化了的异步任务才是可靠的。」因为 对方在考你有没有意识到”异步 = 延迟失败”，能答出”持久化 + 定时扫描 + 重试”，证明你理解了异步化背后的可靠性代价。

  3. “为什么建议用 @TransactionalEventListener(AFTER_COMMIT) 而不是直接在事务里 @Async 发？” 结论先行：「因为事务还没提交就异步发送，异步线程可能读到未提交的旧数据甚至读不到，导致邮件内容错误；AFTER_COMMIT 保证事务落地后再触发。」因为 这题在考事务边界与异步的交互——能讲清”提交前读不到/读到脏数据”这个时序问题，说明你理解得足够深。

Share this post on:
Share this post via WhatsAppShare this post on FacebookShare this post on XShare this post via TelegramShare this post on PinterestShare this post via email
Previous Post
缓存预热策略——启动时就把热数据装进Redis
Next Post
圈复杂度——McCabe公式与重构的数学依据