Spring @Async 注解的配置使用问题

发布于 2022-09-07 23:01:40 字数 464 浏览 29 评论 0

关于Spring中的@Async的使用问题

在使用过程中发现在applicationContext.xml中仅配置 <task:annotation-driven/> 就可以使用@Async注解处理异步

第一种配置:
<task:annotation-driven/>

第二种配置:
<task:annotation-driven executor="myExecutor"/>
<task:executor id="myExecutor" pool-size="5-10" queue-capacity="200" keep-alive="180" rejection-policy="ABORT"/>

之前一直使用的是第一种配置,使用spring的默认线程池来处理。但在查询各种@Async的使用方法时,都是使用的第二种配置方式。想请教一下使用第一种有什么弊端,这两种有什么区别

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

许仙没带伞 2022-09-14 23:01:40

默认的线程池不一定符合你的业务需求

情何以堪。 2022-09-14 23:01:40

你这个问题可以转变为为什么要修改默认的 Executor 的问题,这也是线程池的配置问题。
自定义的线程池配置肯定是更适合你的项目的,况且默认的线程池配置可能会造成 bug 。

引用《阿里巴巴开发手册》:

【强制】线程池不允许使用Executors去创建,而是通过ThreadPoolExecutor的方式,这样

的处理方式让写的同学更加明确线程池的运行规则,规避资源耗尽的风险。

说明:Executors各个方法的弊端:

1)newFixedThreadPool和newSingleThreadExecutor:

主要问题是堆积的请求处理队列可能会耗费非常大的内存,甚至OOM。

2)newCachedThreadPool和newScheduledThreadPool:

主要问题是线程数最大数是Integer.MAX_VALUE,可能会创建数量非常多的线程,甚至OOM。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文