后端视角看 EventBus：发布订阅总线的原理、场景与用法

大家好，我是程序员天天困。今天聊一个能让你少写一大堆回调的东西------EventBus，一个在 Android 和 Java 里都挺火的事件发布订阅库。我自己做后端多一些，但这东西在 Android 用得最广，所以咱们两边都照顾着讲，争取你写哪端都能用得上。话不多说，直接开始。

一、EventBus 到底是干什么的

EventBus 不是什么新发明，它就是把「发布-订阅」模式做成一个开箱即用的总线，让两个模块不用互相认识就能通信。

EventBus（发布订阅事件总线）：greenrobot 出品的开源库，用发布-订阅模式解耦组件通信------发布者只管把事件丢进总线，订阅者通过注解方法接收，两者互不持有引用。你可以把它理解成「代码里的广播站」。

广播站的比喻最贴切：拿话筒的人喊一嗓子，所有调到这个频道的接收器都能听到，喊的人根本不用知道谁在听。回到后端，你写 Spring 时用过的 @EventListener 配 ApplicationEventPublisher，或者 Guava 的 EventBus，乃至 Kafka、RabbitMQ，都是同一套发布订阅思想的不同重量级实现。EventBus 是其中最轻的一个：一个约 60k 的 jar，不依赖任何中间件，在进程内同步或异步分发，延迟在微秒级。

它的运行机制简单到一句话：发布者调 post 把事件丢进 EventBus，EventBus 根据事件类型查到所有订阅了这个类型的方法，依次调用。就这么直接，发布者不关心谁来收，订阅者也不关心谁发的。

二、为什么需要它：组件通信的痛

那有人就会问了，Android 自己不是有通信机制吗，为啥还要再造一个 EventBus？这得先看看原生的那套东西痛在哪。

Android 想让组件之间传消息，最常用的就两样：Handler 和 BroadcastReceiver。Handler 用来切线程、投递消息，BroadcastReceiver 用来发系统级广播。能用是能用，但写起来烦------一堆样板代码不说，发消息的还得知道收消息的是谁，两边经常要互相持有引用，组件一多，引用关系就缠成一团。

最常见的场景：你在子线程里跑接口请求，数据回来要刷新 UI，得拿 Handler 切回主线程；两个 Fragment 要互换数据，得借 Activity 当中间人，或者写个 Listener 接口回调。项目小的时候忍忍就过去了，业务一膨胀，这种回调套回调、引用套引用的写法，代码量和耦合度一起失控。后端其实一个毛病------Service 之间互相 @Autowired，最后织成一张谁也拆不动的网，根子都是发布者把「我要通知谁」写死在了自己代码里。

EventBus 的解法很简单：A 不认识 B/C/D，它只认识 EventBus。谁关心谁自己订阅，发布者彻底从「通知谁」里解放出来，新增一个订阅者，发布者一行代码都不用改。

下面这张图把两种方式摆在一起------左边是组件之间互相持有引用、回调层层传递；右边是发布者只对总线 post，订阅者各自从总线取，谁也不认识谁。

可能有人会问：那我后端直接上 Kafka、RabbitMQ 不就完了，为啥还要一个进程内的 EventBus？

两者解决的不是同一个量级的问题。MQ 是跨进程、跨机器的异步消息，带持久化和集群；EventBus 是单进程内的方法调用级通信，没有网络、没有序列化开销，延迟在微秒级。同一个 JVM 内部模块解耦，上 MQ 是杀鸡用牛刀；跨服务通信，EventBus 又鞭长莫及。各管一段，别混用。

三、三步上手：在 Spring Boot 里用 EventBus

EventBus 的全部 API 浓缩成三步------定义事件、注册订阅、发送事件，背下来就能用。它不绑 Android，Spring Boot 后端一样能跑，把依赖换成 eventbus-java 就行。如果你团队已经定了用 EventBus，或者要和 Android 端共用一套事件模型，下面这套 Spring Boot 写法直接抄；至于要不要在 Spring 里上它，选型建议放在第六节。

第一步：引入 Maven 依赖。 在 pom.xml 里加这一段：

xml 复制代码

<!-- 以 Maven Central 3.3.1 为准；Spring Boot 2.x 注解用 javax，3.x 用 jakarta -->
<dependency>
    <groupId>org.greenrobot</groupId>
    <artifactId>eventbus-java</artifactId>
    <version>3.3.1</version>
</dependency>

第二步：定义事件 + 写订阅者。 事件就是一个普通 POJO，不继承任何基类；订阅者用 @Subscribe 标注接收方法，方法必须 public、有且仅有一个参数：

java 复制代码

public class LoginEvent {
    private final String username;
    public LoginEvent(String username) { this.username = username; }
    public String getUsername() { return username; }
}

java 复制代码

@Component
public class UserModule {
    @Subscribe(threadMode = ThreadMode.POSTING)
    public void onLogin(LoginEvent event) {
        System.out.println("用户 " + event.getUsername() + " 已登录");
    }

    @PostConstruct           // Bean 启动时注册
    public void init() { EventBus.getDefault().register(this); }

    @PreDestroy              // Bean 销毁时注销
    public void destroy() { EventBus.getDefault().unregister(this); }
}

把订阅者声明成 Spring 的 @Component，再用 @PostConstruct 注册、@PreDestroy 注销，register 和 unregister 就跟着 Bean 生命周期自动成对，不用你手动记着去调。

第三步：发送事件。 在任何 Service 里直接 post，发布者完全不需要知道谁在监听：

java 复制代码

@Service
public class LoginService {
    public void login(String username) {
        // 业务处理......
        EventBus.getDefault().post(new LoginEvent(username));
    }
}

我见过太多线上 OOM，根因就是 register 了却没 unregister------EventBus 持有订阅者引用，对象回收不掉。所以哪怕图省事，也务必让注册和注销跟着生命周期走，别只 register 不注销。

下面这张时序图展示了从 post 到被订阅方法处理的完整链路：发布者 post 后，EventBus 按事件类型查订阅表，再按线程模式决定同步直调还是丢进线程池。

@Subscribe 注解的三个参数不是花架子，它们决定了事件在哪个线程跑、能不能收到「早到」的事件、谁先收到。

@Subscribe：EventBus 的订阅方法注解，标注「这个方法要接收什么类型的事件」，可指定线程模式、是否粘性、优先级。被注解的方法要求 public 修饰、有且仅有一个参数。

粘性事件（Sticky Event） ：postSticky 发出后会被 EventBus 缓存下来的事件，之后新注册的订阅者也能收到它。你可以理解成「迟到的订阅者也能拿到上一条广播」。

线程模式（ThreadMode）决定了订阅方法在哪个线程被执行。纯 Java 后端主要用 POSTING 和 ASYNC；MAIN 系列依赖 Android 主线程，后端用不到：

ThreadMode	在哪执行	纯 Java 能用	典型场景
POSTING	post 所在线程直接同步调用	能	不耗时的事件，最常用
ASYNC	永远丢进线程池异步执行	能	订阅者要做耗时 IO
BACKGROUND	post 在主线程则入池，在子线程则直接调	能	轻量后台任务
MAIN	Android 主线程执行	否	更新 UI
MAIN_ORDERED	主线程，按顺序非阻塞	否	多个 UI 更新串行

粘性事件有个坑要单独说：缓存的粘性事件不会自动消失，重复 postSticky 同类型会覆盖旧的，但如果你忘了 removeStickyEvent，换场景后新订阅者可能收到一条本不该收的「历史事件」。我的习惯是粘性事件用完立刻 removeStickyEvent，别让缓存兜着脏数据。

优先级 priority 是个 int，数字越大越先收到，且只在同一线程模式下才有意义。

五、什么场景下用 EventBus

EventBus 适合「一对多、发布者不想知道订阅者是谁」的场景；不适合「调用方需要返回值」或「强顺序依赖」的场景。后者本质上是在做方法调用，硬套事件总线只会让链路更难追踪。

几类典型场景：

全局状态广播：登录登出、网络断连恢复------一处 post，多处 UI 或模块各自响应。
跨层组件通信：Fragment 之间、Fragment 与 Activity、Service 与页面，不再借 Activity 中转。
后端模块解耦：领域事件的轻量版------下单成功后通知积分、库存、推送模块各自处理，下单服务不关心下游有谁。
配置热更新 ：配置中心拉到新值后 post 一个 ConfigChangedEvent，各模块自己刷新。

可能有人会问：后端真要用 EventBus 吗，还是直接 Spring @EventListener 更香？

老实说，纯 Spring 后端我更推荐用 Spring 自带的 @EventListener：零额外依赖、和容器生命周期天然集成、还支持 @TransactionalEventListener 跟着事务走。EventBus 的甜区在 Android 和非 Spring 的纯 Java 工程------没有 Spring 容器、又想要个轻量发布订阅，它比手撸观察者模式省心。要是跨进程，老老实实上 MQ。

六、后端视角的取舍：EventBus vs Guava vs Spring

选哪个，看你在不在 Spring 容器里、要不要跨进程、对依赖体积多敏感。

方案	依赖	线程模型	跨进程	适合谁
greenrobot EventBus	~60k jar	ThreadMode 五种	否	Android / 非 Spring 纯 Java（Spring 里也能跑）
Guava EventBus	Guava 整包	同步或异步二选一	否	已用 Guava 的纯 Java 项目
Spring @EventListener	Spring 容器	同步，可配异步	否	任何 Spring 后端
Kafka / RabbitMQ	独立中间件	异步	是	跨服务、跨进程

EventBus 也不是银弹，几个老问题一直都在：事件类会越定义越多，一个项目几十个 Event 类很常见；订阅方法靠反射查找（编译时索引能优化，但要配 annotation processor）；忘了 unregister 就内存泄漏；最麻烦的是事件流难追踪------post 一条事件，到底谁会响应、什么顺序，得全局搜，调试链路偏长。这些都是它换来解耦的代价。

写法上以 Maven Central 的 org.greenrobot:eventbus:3.3.1（2021 年最后大版本）为准，长期稳定。Android 新项目也有人用 Kotlin 的 Flow / Channel 替代，但就「最快上手、几行解耦」而言，EventBus 依然是门槛最低的方案之一。

后端要不要上 EventBus，我的判断就一句：在 Spring 里别折腾，@EventListener 已经够用；写 Android 或纯 Java 又想轻量解耦，EventBus 依然是几行代码搞定、最省心的那个。跨进程的事，交给 MQ，别让一条进程内总线去干它不该干的活。

后端视角看 EventBus：发布订阅总线的原理、场景与用法

一、EventBus 到底是干什么的

二、为什么需要它：组件通信的痛

三、三步上手：在 Spring Boot 里用 EventBus

四、@Subscribe 三个关键参数：线程模式、粘性事件、优先级

五、什么场景下用 EventBus

六、后端视角的取舍：EventBus vs Guava vs Spring