smart_an的专栏

MQ允许跨JVM，因为它本身是独立于项目之外的，切提供了消息持久化的特性，而Spring事件机制哪怕使用了异步，本质是还是一种方法调用，宕机了就没了。同样的，对老项目改造时也是如此，如果你不知道原来的接口是干嘛的，最好不要去动它，宁愿新写一个接口，即一般提倡“对扩展开放，对修改关闭”。所以，你必须想办法把Spring的事件机制改成异步的，尽可能快地返回下单的结果本身，而不是等其他附属服务全部完成（涉及到其他问题暂时按下不表）。一个月后，京西搞了自建物流体系，用户下单成功后，还需要通知物流系统发货。

可以看到，异步事件通知主要依靠SimpleApplicationEventMulticaster 类中的Executor去实现的，如果这个变量不配置的话默认事件通知是同步的， 否则就是异步通知了，要实现同时支持同步通知和异步通知就得从这里下手；我的实现方式是为每个监听方法加个自定义注解，然后在multicastEvent方法中获取对应监听器上的注解，根据注解去决定是同步通知还是异步通知，这样就可以同时支持了，废话不多说，直接看代码。

首先，丝毫不用怀疑，定时任务绝对不是Spring首创的，JDK本身就提供了很多种实现定时任务的方式。来看一种最简单的实现：实际上JDK还提供了定时任务线程池ScheduledThreadPool，我们可以直接通过Executors工具类获取：和一般的线程池不一样的是，ScheduledThreadPool会执行提交的任务。定时任务方法的命名方式都大同小异，都叫scheduleXxx()，后面还会在别处见到这种命名方式，注意一下。那Spring是如何实现@Scheduled的呢？

定时任务是实际开发中非常普遍的需求，比如定时统计报表、定时更新用户状态等。如果你使用SpringBoot开发项目，那么只需加上@EnableScheduling + @Scheduled两个注解即可启用定时任务。但是SpringBoot提供的定时任务也存在一些小小的坑以及诸多不足，今天我们一起来了解它。为了避免大家觉得我偷懒，先放几篇上来。其实这些应该安排在另一些文章后，不然一部分读者看起来会有点懵。到时都放上来了我再微调一下。

一般来说，正向思维是想办法让updateUser()事务起效，但方法1却采用了逆向思维：让selectUser()的事务起效，从而把updateUser()放在一个更大的事务中，最终控制事务。由于test不存在事务，于是selectUser()也就没有事务，而this.updateUser()本身事务失效，所以最终整个调用事务失效。导致事务失效的根本原因在于，非事务方法中调用updateUser()本质上就是this.updateUser()，而this并不是代理对象，而是普通对象（后面再解释）。

为了让大家更容易接受我的一些观点，上一篇很多笔墨都用在了思路引导上，所以导致文章可能比较臃肿。这一篇来总结一下，会稍微精简一些，但整体趣味性不如第二篇。(上一篇说过了，目前介绍的2种注入方式的说法其实不够准确，后面源码分析时再详细介绍)主要内容：首先明确2个概念：Spring Bean和Java Object。在Spring官方文档中，Bean指的是交给Spring管理、且在Spring中经历完整生命周期（创建、赋值、各种后置处理）的Java对象。Object指的是我们自己new的、且没有加入Spring容

我们。