当前位置: 首页 > news >正文

Java项目中使用到的技术——《异步调用》

文章目录

  • 前言
  • 什么时候需要异步调用
    • 常见同步耗时问题
    • 系统资源被白白浪费
  • 异步调用实现方式
    • @Async注解
    • 消息队列
  • 线程池配置要合理
  • @Async注解失效问题
  • 总结

前言

说起异步调用,我想起刚学习微服务那会儿做的一个电商项目。用户下单后,系统要扣库存、发短信、记日志…一大堆操作。当时图省事,全部写在一个接口里同步执行。结果用户点完下单按钮,页面要转10多秒才有反应,用户还以为系统卡死了,经常重复点击。后来排查发现,发短信的第三方接口响应特别慢,所有订单请求都堵在那里等着。那一刻才真正意识到异步调用的重要性。
现在回头看,异步调用不仅仅是技术优化,更是用户体验的保证。今天就来聊聊Spring Boot中异步调用的各种实现方式,从最简单的@Async到消息队列。

什么时候需要异步调用

常见同步耗时问题

想象一下这些场景:用户上传头像,页面转圈转了30秒;用户注册成功,等了半天才跳转,还不知道是不是真的成功了;导出个Excel报表,浏览器直接超时…其实这些问题的根源都一样:把不需要立即返回结果的操作和核心业务流程耦合在一起了。用户注册,核心是把用户信息存到数据库,至于发欢迎邮件、初始化用户数据这些,完全可以后台慢慢处理。

系统资源被白白浪费

还有一个更隐蔽的问题:资源浪费。Java的线程模型是一个请求对应一个线程,如果线程都在等I/O操作(数据库查询、文件读写),CPU其实是闲着的,但线程资源却被占用了。

异步调用实现方式

@Async注解

对于刚接触异步编程的同学,@Async绝对是最友好的选择。只需要加个注解并自定义线程池,Spring就帮你把方法丢到线程池里执行。

@Configuration
@EnableAsync
public class AsyncConfig {/**配置了一个名为"taskExecutor"的线程池核心线程数10:始终保持活跃的线程数量最大线程数20:当队列满时可以扩展到的最大线程数队列容量200:任务队列能容纳的最大任务数线程名前缀"Task-":便于日志追踪*/@Bean("taskExecutor")public TaskExecutor taskExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();executor.setCorePoolSize(10);        executor.setMaxPoolSize(20);         executor.setQueueCapacity(200);      executor.setThreadNamePrefix("Task-");executor.initialize();return executor;}
}@Service
public class UserService {@Async("taskExecutor")public void sendWelcomeEmail(String email) {try {// 模拟发邮件耗时Thread.sleep(2000);log.info("欢迎邮件发送成功: {}", email);} catch (Exception e) {log.error("邮件发送失败", e);}}@Transactionalpublic User registerUser(UserRegisterDTO dto) {// 核心注册逻辑,快速返回User user = new User();user.setEmail(dto.getEmail());user.setUsername(dto.getUsername());User savedUser = userRepository.save(user);// 异步发送欢迎邮件sendWelcomeEmail(user.getEmail());return savedUser;}
}

在代码中:registerUser() 会在调用 sendWelcomeEmail() 后立刻继续执行并返回结果,邮件发送由后台线程处理。这种方式的好处是简单直接。但有个坑要注意:@Async注解在同一个类的方法调用中是不生效的,因为Spring AOP的限制。如果需要在同一个类里调用异步方法,要么注入自己,要么把异步方法提取到单独的Service里。

消息队列

当系统拆分成多个微服务后,异步处理就不仅仅是单个应用内部的事了。这时候消息队列就派上用场了。我个人比较喜欢RabbitMQ,配置简单,功能够用。

@Configuration
@EnableRabbit
public class RabbitConfig {@Beanpublic DirectExchange userExchange() {return new DirectExchange("user.exchange");}@Beanpublic Queue userRegisteredQueue() {return QueueBuilder.durable("user.registered.queue").build();}@Beanpublic Binding userRegisteredBinding() {return BindingBuilder.bind(userRegisteredQueue()).to(userExchange()).with("user.registered");}
}// 用户服务 - 消息发送方
@Service
public class UserService {@Autowiredprivate RabbitTemplate rabbitTemplate;@Transactionalpublic User registerUser(UserRegisterDTO dto) {User user = new User();user.setEmail(dto.getEmail());user.setUsername(dto.getUsername());User savedUser = userRepository.save(user);// 发送用户注册消息UserRegisteredMessage message = new UserRegisteredMessage(savedUser.getId(), savedUser.getEmail(), savedUser.getUsername());rabbitTemplate.convertAndSend("user.exchange", "user.registered", message);log.info("用户注册消息已发送: {}", savedUser.getId());return savedUser;}
}// 通知服务 - 消息接收方
@Component
public class NotificationService {@RabbitListener(queues = "user.registered.queue")public void handleUserRegistered(UserRegisteredMessage message) {try {log.info("收到用户注册消息: {}", message.getUserId());// 发送欢迎邮件emailService.sendWelcomeEmail(message.getEmail(), message.getUsername());// 发送欢迎短信smsService.sendWelcomeSms(message.getPhone());log.info("用户注册后续处理完成: {}", message.getUserId());} catch (Exception e) {log.error("处理用户注册消息失败: {}", message.getUserId(), e);// 这里可以实现重试逻辑或者发送到死信队列throw e;}}
}

消息队列的好处是彻底解耦,用户服务不需要知道有哪些下游服务,只管发消息就行。而且天然支持重试、死信队列等容错机制。

不过消息队列也带来了复杂性:消息顺序、重复消费、消息丢失等问题都需要考虑。我的建议是,如果是单体应用,优先考虑使用@Async注解;如果已经是微服务架构,那消息队列是必选项。

线程池配置要合理

异步调用的核心是线程池,配置不当会适得其反。我见过有的项目线程池设置得太小,异步任务排队等待,还不如同步执行快;也见过设置得太大,结果把系统内存撑爆了。

@Configuration
public class AsyncExecutorConfig {// CPU密集型任务@Bean("cpuTaskExecutor")public TaskExecutor cpuTaskExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();// CPU密集型:核心线程数 = CPU核数int processors = Runtime.getRuntime().availableProcessors();executor.setCorePoolSize(processors);executor.setMaxPoolSize(processors * 2);executor.setQueueCapacity(50);executor.setThreadNamePrefix("cpu-task-");return executor;}// I/O密集型任务@Bean("ioTaskExecutor")public TaskExecutor ioTaskExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();// I/O密集型:可以设置更多线程executor.setCorePoolSize(20);executor.setMaxPoolSize(50);executor.setQueueCapacity(200);executor.setThreadNamePrefix("io-task-");executor.setKeepAliveSeconds(60);return executor;}
}

一般来说,CPU密集型任务的线程数设置为CPU核数比较合适;I/O密集型任务可以设置更多线程,具体数量需要根据实际情况调优。

@Async注解失效问题

这个坑我估计每个Spring开发者都踩过。@Async在同一个类的方法调用中是不生效的,因为Spring AOP的代理机制限制。
错误写法:

@Service
public class UserService {public void registerUser(User user) {userRepository.save(user);sendWelcomeEmail(user.getEmail());  // 这里调用不会异步执行}@Asyncpublic void sendWelcomeEmail(String email) {// 发送邮件逻辑}
}

正确写法:


// 正确写法1:提取到单独的Service
@Service
public class UserService {@Autowiredprivate NotificationService notificationService;public void registerUser(User user) {userRepository.save(user);notificationService.sendWelcomeEmail(user.getEmail());}
}@Service
public class NotificationService {@Asyncpublic void sendWelcomeEmail(String email) {// 发送邮件逻辑}
}

总结

异步调用是现代Java应用开发的必备技能,选择合适的实现方式很重要。简单的异步操作用@Async就够了,配置简单,上手快。如果是微服务架构,消息队列是必选项,解耦彻底,扩展性好。

http://www.dtcms.com/a/252053.html

相关文章:

  • K8s集群平台
  • 快手可灵 Q1 营收1.5亿,AI商业化分析:C端订阅+B端API双轮驱动​
  • Appium + .NET 测试全流程
  • 1.MySQL三层结构
  • 深度学习打卡1
  • DependencyMatcher + ML Reranking 策略设计实践
  • 软件工程瀑布模型学习指南
  • Lean 定理证明器工具链管理器 elan工作原理介绍
  • Python训练营---DAY54
  • 综述|探究深度学习在园艺研究中的应用
  • 【CUDA GPU 支持安装全攻略】PyTorch 深度学习开发者指南
  • 3_STM32开发板使用(STM32F103ZET6)
  • Python OpenCV 4.10 库详解
  • SQL 增删改查 —— 笔记篇
  • Day.32
  • langchain从入门到精通(九)——ChatGPT/Playground手动模拟记忆功能
  • AI 神经网略小白学习笔记(一) -- 环境搭建
  • Ubuntu24.04一键安装ROS2
  • nrf52811墨水屏edp_service.c文件学习
  • PID 控制算法 | 参数整定 | 方法 / 仿真 / 应用案例
  • 先理解软件工程,再谈AI辅助研发
  • 访问网页的全过程
  • 【计网】导航
  • 常见内核TCP参数描述与配置
  • libuv 框架
  • 介质访问控制——随机访问控制
  • 大模型笔记5:Agent
  • 企业信息技术外包管理制度:如何安全高效管理IT外包服务
  • NodeJS的yarn和npm作用和区别,为什么建议用yarn
  • 分类预测 | Matlab基于AOA-VMD-GRU故障诊断分类预测