警惕！Spring Boot @Async正悄悄拖垮你的服务器警惕！Spring Boot @Async正悄悄拖垮你的服

警惕！Spring Boot @Async正悄悄拖垮你的服务器

@Async，一把双刃剑

在 Spring Boot 开发的奇妙世界里，@Async注解就像是一位神奇的助手，为我们开启了异步处理的大门，带来了诸多便利。当我们面对那些耗时的操作，比如发送邮件、调用第三方接口或者进行复杂的数据计算时，只需轻轻在方法上加上@Async注解，这个方法就能在独立的线程中欢快地运行，不会再死死地阻塞主线程，极大地提升了系统的响应速度和并发处理能力。就好像餐厅里，服务员在处理新订单时，不需要等待上一份餐品制作完成，就能接着服务下一桌客人，效率大幅提升。

然而，这把看似万能的 “瑞士军刀”，实际上是一把双刃剑。如果使用不当，它就会像一个隐藏在暗处的 “杀手”，悄无声息地榨干服务器的宝贵资源，引发一系列让人头疼不已的问题。比如，在高并发的场景下，若没有精心配置线程池，服务器可能会因为疯狂创建线程而导致内存被迅速耗尽，最终陷入 “死机” 状态，就像一个不堪重负的机器，零件纷纷罢工。又或者，当我们在同一个类中天真地调用异步方法时，可能会惊讶地发现，异步效果竟然神秘消失了，程序的执行逻辑变得混乱不堪，仿佛陷入了一个迷局。所以，今天就让我们一起深入探索@Async注解的底层原理，找出那些容易被忽视的陷阱，学会如何正确使用它，让它真正成为我们开发道路上的得力助手，而不是制造麻烦的 “捣蛋鬼”。

案例直击：@Async 引发的服务器危机

曾经，在一个看似平常的电商项目里，一切都按部就班地运行着。直到一场盛大的促销活动来临，高并发的浪潮瞬间将系统淹没，也让隐藏在暗处的问题彻底爆发。在这个电商系统中，为了提升用户下单时的响应速度，开发人员在订单创建后的一系列操作，如发送订单确认邮件、更新库存、记录订单日志等，都使用了@Async注解来实现异步处理。原本，这是一个看似合理的优化方案，想着让这些耗时操作在后台默默完成，不影响用户下单的流畅体验。


@Service
public class OrderService {

    @Async
    public void processOrderAfterCreate(Order order) {
        // 发送订单确认邮件
        sendOrderConfirmationEmail(order);
        // 更新库存
        updateStock(order.getProductId(), order.getQuantity());
        // 记录订单日志
        logOrder(order);
    }

    private void sendOrderConfirmationEmail(Order order) {
        // 模拟邮件发送逻辑，可能会有网络延迟
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Sent order confirmation email for order: " + order.getOrderId());
    }

    private void updateStock(Long productId, Integer quantity) {
        // 模拟库存更新逻辑，可能涉及数据库操作
        try {
            Thread.sleep(1500);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Updated stock for product: " + productId);
    }

    private void logOrder(Order order) {
        // 模拟日志记录逻辑，可能涉及文件或数据库操作
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Logged order: " + order.getOrderId());
    }
}

促销活动一开始，大量的订单如潮水般涌入。然而，很快运维人员就发现服务器的 CPU 使用率急剧飙升，一路突破 90%，内存也被迅速消耗，逐渐逼近警戒线。没过多久，服务器就开始频繁报错，大量请求超时，整个服务陷入了瘫痪状态。事后，经过一番深入排查，才发现罪魁祸首竟是@Async注解。原来，开发人员在使用@Async时，没有对线程池进行任何自定义配置，Spring Boot 采用了默认的SimpleAsyncTaskExecutor线程池。这个默认线程池有个致命的缺陷，它并不会复用线程，每次调用@Async方法都会创建一个新的线程，并且没有任务队列来缓冲请求。在平常低并发的情况下，这个问题并不明显，可一旦遇到促销活动这样的高并发场景，大量的线程被疯狂创建。假设每秒有 1000 个订单创建，那就意味着每秒要创建 1000 个新线程。每个线程都需要分配一定的栈内存，随着线程数量的暴增，内存很快就被耗尽，同时 CPU 也被大量的线程创建、销毁和上下文切换操作占满，无法再正常处理业务请求，最终导致了这场服务器的 “灾难”。这次事故给整个团队敲响了警钟，也让大家深刻认识到，在使用@Async注解时，线程池的配置绝不是一件可以忽视的小事。

@Async 的工作原理剖析

代理模式实现异步

在 Spring 的世界里，@Async注解能够实现异步的神奇魔法，背后依赖的是 Spring 强大的代理模式。当我们在一个方法上标注@Async注解时，Spring 就像一位技艺高超的工匠，在应用启动时，会悄无声息地为这个方法所在的类精心创建一个代理对象。这个代理对象就像是一个 “影子分身”，它和原始对象有着千丝万缕的联系，却又有着独特的使命。

当我们调用这个被@Async注解修饰的方法时，奇妙的事情发生了。实际上，我们并不是直接在调用原始对象的方法，而是在和这个代理对象打交道。代理对象会迅速拦截这个方法调用，就像一个敏捷的守门员，稳稳地接住飞来的足球。然后，代理对象会将这个方法的调用请求巧妙地包装成一个任务，就好比把物品打包好准备发货。这个任务被封装成Callable或者Runnable对象，里面包含了方法的所有信息，如方法参数、方法对象本身等。

接下来，代理对象会把这个包装好的任务提交到一个特定的线程池中。这个线程池就像是一个繁忙的工厂车间，里面有许多勤劳的 “工人”（线程）随时准备接受任务并执行。在这个过程中，主线程就像是一个急性子的人，它不会停下来等待任务在另一个线程中完成，而是会立刻返回，继续去处理其他的事情，就像把包裹交给快递员后，就去忙自己的事了。

Spring 在创建代理对象时，有两种主要的方式，就像我们去上班可以选择开车或者坐地铁一样。如果目标类实现了至少一个接口，Spring 就会优先使用 JDK 动态代理。JDK 动态代理就像是一个灵活的工具，它基于 Java 原生的反射机制，在运行时动态地生成代理类的字节码，然后加载到 JVM 中。这个代理类会实现目标类所实现的接口，通过InvocationHandler接口来拦截方法调用，并在其中实现异步处理的逻辑。例如，在一个电商系统中，如果订单服务接口OrderService有一个方法processOrder被标注为@Async，JDK 动态代理就会为OrderService创建一个代理类，当调用processOrder方法时，代理类会拦截这个调用，将其封装成任务提交到线程池，而主线程则继续执行其他任务，从而实现异步处理。

而当目标类没有实现任何接口时，Spring 就会切换到 CGLIB 代理。CGLIB 代理就像是一个强大的 “变形金刚”，它通过字节码操作库 ASM，直接对目标类进行操作，生成目标类的子类作为代理类。这个子类会重写目标类的非final方法，在重写的方法中实现异步处理的逻辑。例如，在一个简单的业务类UserBusiness中，如果有一个方法updateUserInfo被标注为@Async，且UserBusiness没有实现接口，CGLIB 代理就会生成UserBusiness的子类，在子类中重写updateUserInfo方法，实现异步处理。需要注意的是，由于 CGLIB 是通过继承实现代理的，所以目标类不能是final类，否则无法生成子类，也就无法使用 CGLIB 代理了。

线程池的关键作用

在@Async注解实现异步处理的过程中，线程池扮演着至关重要的角色，就像军队中的指挥官，掌控着整个任务执行的节奏和资源分配。当代理对象将任务提交给线程池后，线程池会根据自身的配置和当前的运行状态，合理地安排线程来执行这些任务。

线程池的主要作用之一是控制并发线程的数量。在高并发的场景下，如果没有线程池的控制，每一个异步任务都创建一个新的线程，那么线程数量可能会像失控的野草一样疯狂增长。过多的线程会导致系统资源被大量消耗，就像一个人吃了过多的食物却无法消化，会引起各种不适。例如，线程的创建和销毁需要消耗 CPU 和内存资源，过多的线程还会导致 CPU 上下文切换频繁，降低系统的整体性能。而线程池通过设置核心线程数、最大线程数等参数，可以有效地限制并发线程的数量，确保系统资源的合理利用。比如，在一个在线教育平台中，当大量学生同时请求课程资源时，线程池可以控制处理这些请求的线程数量，避免因线程过多而导致服务器崩溃。

线程池还提供了任务队列的功能。当线程池中的所有线程都在忙碌地执行任务时，新提交的任务并不会被直接丢弃，而是会被放入任务队列中等待执行。这个任务队列就像是一个有序的 “候车室”，任务们在这里按照顺序排队等待线程的 “召唤”。不同类型的任务队列有着不同的特性，比如LinkedBlockingQueue是一个无界队列，它可以容纳大量的任务，但如果任务过多，可能会导致内存溢出；而ArrayBlockingQueue是一个有界队列，它的大小在创建时就已经确定，当队列满时，新的任务就需要根据线程池的拒绝策略来处理。合理选择任务队列的类型和大小，对于系统的稳定性和性能有着重要的影响。例如，在一个订单处理系统中，订单处理任务可以先放入任务队列，等待线程池中的线程空闲时再进行处理，这样可以避免因瞬间大量订单请求而导致系统崩溃。

线程池还提供了丰富的拒绝策略。当线程池中的线程数量达到最大线程数，并且任务队列也已满时，再提交新的任务，就会触发拒绝策略。拒绝策略就像是一个 “危机处理专家”，它决定了如何处理这些无法被线程池接受的任务。常见的拒绝策略有AbortPolicy，它会直接抛出RejectedExecutionException异常，告诉调用者任务被拒绝了；CallerRunsPolicy则会让提交任务的线程自己来执行这个任务，这样可以避免任务丢失，但可能会影响主线程的性能；DiscardPolicy会默默地丢弃这个新提交的任务，不做任何处理；DiscardOldestPolicy会丢弃任务队列中最老的一个任务，然后尝试将新任务放入队列。在实际应用中，我们需要根据业务场景和需求，选择合适的拒绝策略。比如，在一个实时交易系统中，对于订单处理任务，我们可能不希望丢弃任务，所以可以选择CallerRunsPolicy策略，让提交订单的线程自己处理订单，以保证订单的完整性。

为何 @Async 会榨干服务器资源

默认线程池的致命缺陷

Spring Boot 中@Async注解的默认线程池SimpleAsyncTaskExecutor，看似方便，实则暗藏诸多致命缺陷，就像一个看似坚固实则漏洞百出的城堡，在高并发的攻击下，不堪一击。

这个默认线程池最大的问题在于它没有线程复用机制，每次调用@Async方法时，它都会毫不犹豫地创建一个新的线程，就像一个挥霍无度的人，不懂得珍惜资源。在低并发的情况下，这种行为可能不会引起太多注意，就像偶尔浪费一点资源，不会对整体造成太大影响。但一旦进入高并发场景，问题就会被无限放大。想象一下，一个电商平台在促销活动期间，每秒可能会有数千个订单创建请求。如果每个订单创建后的异步操作都由SimpleAsyncTaskExecutor来处理，那么每秒就会创建数千个新线程。而创建线程是一个代价高昂的操作，它需要分配一定的栈内存，通常每个线程的栈内存默认大小为 1MB 左右（可通过-Xss参数调整）。如此大量的线程创建，会迅速消耗系统的内存资源，就像一个无底洞，不断吞噬着内存，很快就会导致内存耗尽，引发OutOfMemoryError异常，让系统陷入瘫痪。

SimpleAsyncTaskExecutor没有任务队列。在高并发场景下，当大量的任务瞬间到达时，由于没有任务队列来缓冲这些任务，线程池只能不断地创建新线程来处理它们。这就好比一个没有候车室的车站，乘客们（任务）来了之后只能直接上车（创建新线程处理），而不能在候车室等待（放入任务队列）。这种缺乏缓冲机制的设计，使得线程数量无法得到有效的控制，进一步加剧了资源的消耗。同时，没有任务队列也意味着无法对任务进行合理的排序和调度，可能会导致一些重要的任务被延迟处理，影响系统的整体性能。

另外，大量线程的创建和销毁还会导致 CPU 资源的严重浪费。线程的创建和销毁都需要 CPU 进行大量的工作，包括分配内存、初始化寄存器、设置栈指针等。当线程数量过多时，CPU 会花费大量的时间和精力在这些线程的管理操作上，而真正用于执行任务的时间就会被大幅压缩，就像一个忙碌的管家，大部分时间都花在了处理琐事上，而没有时间去完成重要的工作。这种情况下，CPU 的使用率会急剧升高，系统的吞吐量反而会下降，整个系统就会变得异常缓慢，甚至无法响应新的请求。

高并发场景下的资源压力

为了更直观地感受@Async默认配置在高并发场景下对服务器资源的巨大压力，我们以一个电商秒杀活动为例。在这个活动中，商品数量有限，而参与秒杀的用户却数以万计。当秒杀开始的那一刻，大量的请求如同潮水般涌入服务器，每个请求都触发了一系列被@Async注解修饰的异步操作，比如记录秒杀日志、更新库存、发送秒杀结果通知等。

假设每个秒杀请求的处理时间为 100 毫秒（这已经是一个相对较快的处理时间了），而服务器的 CPU 核心数为 8 核。在理想情况下，如果线程池配置合理，能够充分利用这 8 个核心，那么理论上每秒可以处理 80 个请求（假设每个请求都能在 100 毫秒内完成）。但由于使用了@Async的默认线程池SimpleAsyncTaskExecutor，情况就变得截然不同了。

在高并发场景下，假设每秒有 1000 个秒杀请求到达。由于SimpleAsyncTaskExecutor没有线程复用机制和任务队列，它会立即创建 1000 个新线程来处理这些请求。这 1000 个线程会同时竞争 CPU 资源，导致 CPU 上下文切换频繁。每个线程在执行过程中，还需要占用一定的内存空间，这使得内存压力也急剧增大。随着线程数量的不断增加，很快就会达到系统的内存上限，导致内存耗尽，系统开始频繁进行垃圾回收（GC）。而垃圾回收本身也是一个非常耗时的操作，会进一步占用 CPU 资源，使得系统的性能进一步恶化。

由于 CPU 资源被大量线程的创建、销毁和上下文切换所占用，真正用于处理秒杀业务逻辑的 CPU 时间变得非常有限。原本每个请求 100 毫秒的处理时间，在这种情况下可能会被延长到数秒甚至数十秒，导致大量请求超时。用户在前端看到的就是页面长时间加载无响应，最终得到一个秒杀失败的提示，这无疑会极大地影响用户体验，也可能会给电商平台带来巨大的经济损失。这个例子充分说明了，在高并发场景下，@Async默认配置对服务器资源的消耗是多么的惊人，也凸显了合理配置线程池的重要性。

如何避免 @Async 的资源陷阱

自定义线程池的配置与优化

为了避免@Async注解因默认线程池的缺陷而榨干服务器资源，我们需要学会自定义线程池，让它能根据业务的实际需求，灵活且高效地管理线程资源，就像为不同的工作场景量身定制合适的工具一样。在 Spring Boot 中，我们可以使用ThreadPoolTaskExecutor来实现这一目标。

首先，我们要确定核心线程数corePoolSize 。这个参数就像是一支球队的首发阵容，它表示线程池中始终保持存活的线程数量，即使这些线程暂时处于空闲状态，也不会被回收。核心线程数的设置至关重要，它直接影响着线程池的基础处理能力。如果设置得过小，在高并发场景下，线程池可能无法及时处理大量的任务，导致任务堆积；而设置得过大，则会浪费系统资源，因为即使在低负载情况下，这些多余的线程也会占用内存等资源。一般来说，对于 I/O 密集型任务，由于线程大部分时间都在等待 I/O 操作完成，所以可以将核心线程数设置为 CPU 核心数的 2 倍左右，这样可以充分利用 CPU 资源，同时让线程在等待 I/O 时，其他线程有机会执行。例如，在一个电商系统中，订单处理涉及到数据库查询、网络请求等 I/O 操作，如果服务器是 4 核 CPU，那么核心线程数可以设置为 8 左右。而对于 CPU 密集型任务，由于线程主要在进行 CPU 计算，线程数过多会导致 CPU 上下文切换频繁，反而降低性能，因此核心线程数可以设置为与 CPU 核心数相等或略多一些。

最大线程数maxPoolSize也不容忽视。它就像是球队的替补阵容加上首发阵容，是线程池允许创建的最大线程数量。当任务队列已满，且核心线程都在忙碌地执行任务时，线程池就会尝试创建新的线程，直到达到最大线程数。最大线程数的设置需要谨慎考虑，它既要满足高并发场景下的任务处理需求，又不能过大导致系统资源耗尽。通常，我们可以将最大线程数设置为核心线程数的 2 - 3 倍。比如，核心线程数为 5，那么最大线程数可以设置为 10 - 15 之间。但具体的数值还需要根据实际业务场景和服务器的硬件资源进行调整。在一个在线教育平台中，当大量学生同时观看课程视频时，会产生大量的视频流请求，这些请求可能涉及到视频解码、缓存读取等操作，对线程池的处理能力要求较高，此时就需要合理设置最大线程数，以应对高并发的情况。

任务队列容量queueCapacity的设置也很关键。任务队列就像是一个任务的 “候车室”，当线程池中的核心线程都在忙碌时，新提交的任务就会被放入任务队列中等待执行。队列容量的大小决定了线程池能够缓冲的任务数量。如果队列容量设置得过小，在高并发场景下，任务队列很快就会被填满，从而触发线程池创建更多的线程，直到达到最大线程数，这可能会导致系统资源紧张；而如果队列容量设置得过大，虽然可以缓冲大量的任务，但可能会导致任务在队列中等待的时间过长，影响系统的响应速度，同时也会占用大量的内存资源。因此，我们需要根据业务的实际情况来选择合适的队列类型和容量。对于一些对响应时间要求较高的业务，如实时交易系统，我们可以选择较小的队列容量，并结合合理的拒绝策略，以保证任务能够及时得到处理；而对于一些对响应时间要求不是特别严格，但任务量较大的业务，如日志记录系统，可以适当增大队列容量。在实际应用中，常用的队列类型有LinkedBlockingQueue（无界队列）和ArrayBlockingQueue（有界队列）。LinkedBlockingQueue可以容纳大量的任务，但如果任务过多，可能会导致内存溢出；ArrayBlockingQueue的大小在创建时就已经确定，当队列满时，新的任务就需要根据线程池的拒绝策略来处理。

线程存活时间keepAliveSeconds用于设置非核心线程在空闲状态下的最大存活时间。当线程池中的线程数量超过核心线程数时，如果某线程的空闲时间超过了keepAliveSeconds，那么这个线程就会被终止，以释放系统资源。这个参数的设置可以在一定程度上平衡系统资源的利用和线程的创建销毁开销。如果设置得过短，可能会导致线程频繁地创建和销毁，增加系统的开销；而设置得过长，则可能会导致一些空闲线程长时间占用系统资源。一般来说，我们可以将keepAliveSeconds设置为 60 - 120 秒之间，这样既可以保证线程在空闲一段时间后能够及时被回收，又不会过于频繁地创建和销毁线程。

线程名前缀threadNamePrefix是一个容易被忽视但非常有用的参数。它就像是给每个线程贴上了一个独特的标签，为线程设置一个有意义的前缀，可以方便我们在日志中快速识别和追踪线程的执行情况。例如，我们可以将线程名前缀设置为 “order - async -”，这样在日志中看到以这个前缀开头的线程名，就可以知道它是与订单异步处理相关的线程，便于排查问题和进行性能分析。

拒绝策略RejectedExecutionHandler则是线程池的 “危机处理专家” 。当任务队列已满，且线程数达到最大线程数时，再提交新的任务，就会触发拒绝策略。Spring 提供了几种常见的拒绝策略，如AbortPolicy（直接抛出RejectedExecutionException异常，拒绝新任务）、CallerRunsPolicy（让提交任务的线程自己来执行这个任务，这样可以避免任务丢失，但可能会影响主线程的性能）、DiscardPolicy（默默地丢弃这个新提交的任务，不做任何处理）、DiscardOldestPolicy（丢弃任务队列中最老的一个任务，然后尝试将新任务放入队列）。在实际应用中，我们需要根据业务场景和需求，选择合适的拒绝策略。比如，在一个实时交易系统中，对于订单处理任务，我们可能不希望丢弃任务，所以可以选择CallerRunsPolicy策略，让提交订单的线程自己处理订单，以保证订单的完整性；而在一些对任务实时性要求不是特别高的场景中，如日志记录任务，可以选择DiscardPolicy策略，当线程池繁忙时，直接丢弃一些日志记录任务，因为即使丢失一些日志，对系统的核心业务也不会产生太大影响。

下面是一个自定义线程池的配置示例：


import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

import java.util.concurrent.Executor;
import java.util.concurrent.ThreadPoolExecutor;

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean(name = "customTaskExecutor")
    public Executor customTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(20);
        executor.setKeepAliveSeconds(60);
        executor.setThreadNamePrefix("custom-async-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}

在这个示例中，我们创建了一个名为customTaskExecutor的线程池，设置了核心线程数为 5，最大线程数为 10，队列容量为 20，线程存活时间为 60 秒，线程名前缀为 “custom - async -”，并采用了CallerRunsPolicy拒绝策略。然后，在使用@Async注解时，我们可以指定使用这个自定义线程池，如下所示：


@Service
public class AsyncService {

    @Async("customTaskExecutor")
    public void asyncMethod() {
        System.out.println("异步方法执行，线程：" + Thread.currentThread().getName());
    }
}

通过这样的配置，我们就可以有效地避免@Async注解因默认线程池的问题而导致的资源耗尽问题，让异步任务在一个合理配置的线程池中高效运行。

其他使用 @Async 的注意事项

除了合理配置线程池外，在使用@Async注解时，还有一些其他的注意事项，这些细节就像是隐藏在暗处的 “小陷阱”，如果不小心踩到，也会导致异步功能无法正常发挥，甚至引发一些难以排查的问题。

开启@Async功能需添加@EnableAsync注解，这就像是启动一辆汽车需要插入钥匙并点火一样，是必不可少的步骤。@EnableAsync注解可以添加在 Spring Boot 的主启动类上，也可以添加在专门的配置类上。例如，在主启动类中添加@EnableAsync注解：


import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableAsync;

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

只有添加了这个注解，Spring 才会识别并处理被@Async注解修饰的方法，将其异步执行。如果忘记添加这个注解，那么即使方法上标注了@Async，它也会像一个被忽视的指令，仍然在主线程中同步执行，无法实现异步的效果。

要避免在同一类中调用@Async方法。这是因为 Spring AOP（面向切面编程）机制在实现@Async功能时，是通过代理对象来实现的。当在同一个类中调用被@Async注解修饰的方法时，实际上是通过this关键字来调用的，而this指向的是原始对象，并不是代理对象，所以无法触发异步功能。例如：


@Service
public class UserService {

    public void test() {
        // 这种调用方式不会触发异步，仍然是同步执行
        this.asyncMethod();
    }

    @Async
    public void asyncMethod() {
        System.out.println("异步方法执行，线程：" + Thread.currentThread().getName());
    }
}

如果需要在同一类中调用异步方法，可以通过注入自身 Bean 或使用ApplicationContext.getBean()方法来获取代理对象，然后通过代理对象来调用异步方法。例如，使用注入自身 Bean 的方式：


@Service
public class UserService {

    private final UserService self;

    public UserService(UserService self) {
        this.self = self;
    }

    public void test() {
        // 通过代理对象调用异步方法，触发异步功能
        self.asyncMethod();
    }

    @Async
    public void asyncMethod() {
        System.out.println("异步方法执行，线程：" + Thread.currentThread().getName());
    }
}

或者使用ApplicationContext.getBean()方法：


import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    @Autowired
    private ApplicationContext applicationContext;

    public void test() {
        UserService userService = applicationContext.getBean(UserService.class);
        // 通过代理对象调用异步方法，触发异步功能
        userService.asyncMethod();
    }

    @Async
    public void asyncMethod() {
        System.out.println("异步方法执行，线程：" + Thread.currentThread().getName());
    }
}

确保异步方法为public 。因为@Async注解的异步功能依赖于 Spring 的 AOP 代理机制，而代理对象只能对public方法进行代理和增强。如果将异步方法定义为private、protected或默认访问权限，那么 Spring 无法为其创建代理对象，@Async注解也就无法生效。例如：


@Service
public class UserService {

    // 这种异步方法不会生效，因为是private方法
    @Async
    private void privateAsyncMethod() {
        System.out.println("异步方法执行，线程：" + Thread.currentThread().getName());
    }
}

所以，为了确保@Async注解能够正常工作，我们必须将异步方法声明为public 。

在使用@Async注解时，只有充分注意这些细节，合理配置线程池，并遵循相关的使用规范，才能让它真正发挥出异步处理的优势，提升系统的性能和响应速度，而不是成为引发问题的源头。

总结与展望

@Async注解在 Spring Boot 开发中无疑是一个强大的工具，它为我们实现异步处理提供了便捷的方式，在很多场景下都能显著提升系统的性能和响应速度。然而，从我们前面深入剖析的原理、实际案例以及各种使用细节来看，如果使用不当，它就像一颗隐藏在代码中的 “定时炸弹”，随时可能引发服务器资源耗尽、系统性能急剧下降等严重问题。

通过对默认线程池SimpleAsyncTaskExecutor的缺陷分析，我们清楚地看到它在高并发场景下对服务器资源的巨大消耗，这就像是一个没有节制的消费者，不断吞噬着系统的内存和 CPU 资源，最终导致系统崩溃。而在高并发场景下，不合理的@Async配置会使问题进一步恶化，大量的线程创建和任务堆积，让服务器不堪重负。

为了避免这些资源陷阱，我们详细探讨了自定义线程池的配置与优化方法。通过合理设置核心线程数、最大线程数、任务队列容量、线程存活时间等参数，以及选择合适的拒绝策略，我们可以打造出一个高效、稳定的线程池，就像为服务器配备了一位精明的管家，能够有条不紊地管理异步任务，充分利用系统资源，同时避免资源的浪费和过度消耗。同时，我们还强调了其他使用@Async的注意事项，如开启@Async功能需添加@EnableAsync注解、避免在同一类中调用@Async方法、确保异步方法为public等，这些细节虽然看似微不足道，但却可能对异步功能的正常实现产生关键影响。

在今后的开发中，希望大家能够深刻理解@Async注解的工作原理和使用要点，在享受异步处理带来的便利的同时，时刻保持警惕，避免陷入资源陷阱。每一次对@Async的使用，都应该根据具体的业务场景和系统架构进行精心的设计和配置，就像为不同的病人开出个性化的药方一样。让我们一起优化代码，让@Async注解真正成为提升系统性能的得力助手，保障系统的稳定运行，为用户提供更加流畅、高效的服务体验。相信通过不断地学习和实践，我们都能在 Spring Boot 的开发中，熟练运用@Async注解，打造出更加健壮、高性能的应用系统。