1. 先搞清楚EventBus到底在解决什么问题先说一个我早几年的真实经历。当时在一个单体应用里做订单模块下单成功之后要干的事情特别多发短信通知、更新积分、同步给仓储系统、记录操作日志、给推荐系统喂数据。一开始代码就是老老实实地在Service层里一行一行往下写看起来没问题但等业务量上来就发现不对劲了——一次下单请求里真正核心的创建订单可能只需要30毫秒但把短信、积分、日志、仓储同步全部串行跑完接口响应时间直接飙到800多毫秒。更头疼的是每次上线新需求比如产品说要再加一个下单后推送优惠券我就得改下单核心方法的代码加一行调用改完还得担心别把核心链路搞坏了。这就是典型的核心链路被非核心逻辑污染的问题。当时组里讨论要不要上消息队列但架构师说得很直接为了这点事引入一套消息中间件运维成本、部署成本、学习成本都不划算单体应用阶段最合理的方式就是用Guava EventBus做进程内事件解耦。EventBus是Google Guava库提供的一个轻量级事件发布订阅框架用一句话概括就是进程内的、基于内存的、同步或异步的消息分发器。它不是什么高深的东西核心就三个角色发布者Publisher、订阅者Subscriber、事件总线EventBus本身。发布者把事件对象丢给EventBusEventBus根据事件的类型找到所有注册过的订阅者把事件传过去然后收工。把这个机制理解透了你会发现在很多场景下它比MQ好用得多因为它不需要网络传输、不需要序列化、不需要持久化就是纯粹的方法调用级别的解耦。但反过来它也不具备MQ的跨进程能力、削峰填谷能力、消息可靠性保证。所以这个工具用得好不好完全取决于你清不清楚它的边界在哪里。接下来我分几个层面把这件事讲透怎么用、怎么理解它的线程模型、怎么解决容易踩的坑、什么时候该用它而不是MQ以及我实际项目里沉淀下来的一些经验。2. 一次完整的集成实录依赖、注册、发布与订阅2.1 最小化依赖引入与项目结构先说引入。如果你的项目是Maven构建直接在pom.xml里加一行dependency groupIdcom.google.guava/groupId artifactIdguava/artifactId version33.0.0-jre/version /dependency注意版本号我用的是基于JDK8的33.0.0-jre版本。如果你还在用JDK7甚至更老的版本就得往下找对应版本比如21.0-jre。这个细节很容易被忽略直接拿最新版本结果项目编译不过实际上是JDK版本不兼容的原因。引入依赖之后不用做任何额外的配置。EventBus不需要Spring管理也可以跑它就是一个普通的Java对象。不过在实际项目里我习惯把它交给Spring容器管理作为一个单例Bean使用。为什么因为EventBus内部维护着一组订阅者注册表如果每次使用都new一个实例那A处注册的订阅者B处根本收不到事件这个单例特性非常重要。我的做法通常是定义一个配置类Configuration public class EventBusConfig { Bean public EventBus eventBus() { return new EventBus(app-event-bus); } }如果你有异步需求就再注册一个Bean public AsyncEventBus asyncEventBus() { return new AsyncEventBus(app-async-event-bus, Executors.newFixedThreadPool(8)); }这里有个隐性知识点AsyncEventBus不是EventBus的子类两者是平级关系都继承自EventBus的父类。所以在设计注入点的时候不要把异步总线对象直接赋给EventBus类型的字段否则你拿到的是同步总线。我自己就犯过这个低级错误调试了半天。2.2 订阅者的定义与注册方式订阅者就是普通Java类里的普通方法加一个Subscribe注解即可。EventBus没有强制你实现某个接口这点比很多框架要灵活得多public class OrderEventListener { Subscribe public void onOrderCreated(OrderCreatedEvent event) { // 处理订单创建后的逻辑 sendSms(event.getMobile(), 您的订单已创建); } Subscribe public void handleOrderTimeout(OrderTimeoutEvent event) { // 处理订单超时逻辑 } }方法名可以随便取参数类型才是关键。EventBus派发事件的时候就是根据事件对象的运行时类型去匹配订阅方法参数类型的。注册订阅也很简单eventBus.register(new OrderEventListener());这里有一个细节register和unregister需要成对出现。如果你的订阅者是有状态的或者你关注内存泄漏那么在Bean销毁的时候一定要记得调unregister。不过在Spring管理的单例场景下Bean和容器生命周期一致只要容器不销毁订阅者一直存在问题不大。但如果你在一个长生命周期对象里反复new和register那就得警惕了。2.3 事件对象的设计要点事件对象本身可以是任意POJO不需要继承任何基类。但我在实践中强烈建议你给事件类设计一个统一的父类或接口哪怕是个空壳public abstract class BaseEvent { private Long eventId; private long timestamp; public BaseEvent() { this.timestamp System.currentTimeMillis(); } // getter/setter... } public class OrderCreatedEvent extends BaseEvent { private String orderId; private String mobile; // 构造器、getter... }为什么这么做因为后期你要排查问题的时候统一的基类可以帮你打印事件来源、事件追踪ID、触发时间这些信息在分布式链路追踪还没普及的进程内场景下就是救命稻草。我见过太多同事直接用String或者Map当事件对象代码写起来是爽了但出了问题根本没法调查。发布事件就一行代码OrderCreatedEvent event new OrderCreatedEvent(); event.setOrderId(ORD123456); event.setMobile(13800000000); eventBus.post(event);post方法的逻辑是把一个事件对象交给EventBusEventBus在内部找到所有参数类型匹配的订阅者方法然后逐个调用。注意如果一个事件没有任何订阅者EventBus默认是直接丢弃的不会抛异常也不会记录日志。这个静默丢弃的机制在debug的时候很坑后面我专门讲。2.4 一个完整的上下文顺序把上面几块串起来一次完整的流转是业务代码创建一个事件对象调用eventBus.post(event)EventBus首先会把事件放到当前正在派发的事件上下文中然后EventBus遍历注册表找出所有参数类型可以接收该事件的方法如果有AllowConcurrentEvents注解则多个订阅方法并发执行否则按顺序逐个执行所有订阅方法执行完毕后post方法返回这套流程里订阅者的执行是同步且阻塞的。也就是说如果某个订阅方法执行特别慢post调用就会卡在那里。这个特性在后面讲异步化优化的时候我会再展开。3. 深入剖析同步与异步线程模型是分水岭3.1 同步EventBus的真实执行路径很多初学者以为EventBus是异步的这是最大的误解。EventBus.post()是一个同步调用它直接在当前线程内逐个调用匹配的订阅方法。什么意思假设你的主线程在Service层调用了eventBus.post(event)那么所有匹配的订阅方法都在你这个主线程内执行完毕post方法才会返回。整个链路是Web请求线程 - Service方法 - eventBus.post() - 订阅者A方法 - 订阅者B方法 - post返回 - Service继续执行如果订阅者A方法里有个外部HTTP调用耗时2秒那你的主线程就会被阻塞2秒。对于Web接口来说这2秒直接反映在接口RT上。这个问题在你处理并发请求时尤其明显——高QPS场景下一个慢订阅者可能拖垮整个线程池。我在项目里就遇到过一次。有个订阅者方法里去调用第三方的库存查询接口那个接口经常超时结果下单接口的平均响应时间从200毫秒飙升到了3秒。排查的时候我们发现问题不在核心链路代码而在一个下游的订阅方法里。这就是同步EventBus最需要警惕的地方。所以我的第一条经验法则是凡是可能耗时的操作要么不要放在订阅方法里同步执行要么就改用AsyncEventBus加异步线程池处理。如果你用了同步EventBus你就要对每个订阅者方法的执行时间负责。3.2 AsyncEventBus的线程池配置策略AsyncEventBus的核心区别在于post方法会把事件提交给一个Executor执行然后立即返回。事件的处理时间被异步化到了线程池里你的主线程不会被阻塞。但用了异步不等于万事大吉线程池才是真正的瓶颈。我见过很多人图省事直接Executors.newFixedThreadPool(8)也不管线程满了怎么办结果一个慢任务把队列堆满后续任务全部排队甚至抛出RejectedExecutionException。实际项目中我个人推荐的做法是ThreadPoolExecutor eventBusExecutor new ThreadPoolExecutor( cores, // 核心线程数 maxCores, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new ArrayBlockingQueue(500), // 有界队列 new ThreadFactoryBuilder() .setNameFormat(eventbus-pool-%d) .build(), new CallerRunsPolicy() // 拒绝策略调用者执行 );核心线程数的设定没有银弹我一般是结合业务量估算的如果平均每个事件的处理时长是50毫秒期望每秒处理200个事件那么需要的线程数约等于200×0.0510再留一点余量取12~16个左右。如果事件处理时长波动大那就要把核心线程数调高一点或者用有界队列加CallerRunsPolicy兜底。CallerRunsPolicy这个拒绝策略很关键。当线程池满了新任务不会丢而是由调用post的那个线程来执行。对于异步场景来说这意味着极端情况下事件处理会退化为同步但至少保证了消息不丢失。相比之下DiscardPolicy和DiscardOldestPolicy都会导致事件静默丢失属于生产环境禁用级别。3.3 如何选同步还是异步这个没有标准答案我的判断维度就三个实时性要求如果调用方需要立刻知道处理结果比如下单后要立即给前端返回成功并且短信通知必须同时发出那用同步更合理因为异步会导致订单创建了但短信还没发的中间状态。耗时与稳定性如果订阅者方法耗时不可控外部HTTP调用、批量IO操作必须异步化。结果依赖如果订阅者的执行结果会影响主流程的成功与否那异步就无法满足因为主流程根本等不到结果。大多数场景下我会在同一系统里混合使用两个EventBus实例一个同步的处理必须实时完成的轻量逻辑一个异步的处理耗时操作和可容忍延迟的任务。两个总线各司其职互不干扰。这种设计在代码层面没有什么额外成本却能让架构清晰很多。4. 死锁问题、事件继承与注册表结构底层原理是避坑关键4.1 同步EventBus与死锁的必然联系先看一个场景订阅者A在处理事件处理过程中它又post了另一个事件B而事件B的订阅者C又回过头来post事件A。在同步EventBus下这个循环依赖会怎样直接死锁不一定但极大概率会栈溢出。因为EventBus是递归调用的每post一次就深一层调用栈循环post会让栈无限加深最终抛出StackOverflowError。这不是EventBus特有的问题而是所有同步递归调用的通病。更隐蔽的一个死锁场景是这样的你的两个线程分别往EventBus里post不同的事件这两个事件的订阅者恰好需要互相等待对方的处理结果。因为同步EventBus的post会阻塞当前线程直到所有订阅者执行完毕所以如果订阅者之间形成了锁的交叉等待就是典型的死锁。我记得以前排查过一个诡异问题系统偶发卡死所有线程dump显示都在等待某把锁但代码逻辑看起来完全没有问题。最后发现是两个订阅者方法里各自用synchronized锁住了同一个业务对象的两个不同字段而它们的执行顺序恰好交叉了。这种问题在并发高的场景下非常难排查。我的建议是如果订阅者方法里要加锁一定要避免嵌套锁和交叉锁最好在订阅者方法入口做一次幂等性校验和去重。如果实在做不到那尽量让订阅者方法只做无状态的计算所有的共享状态变更交给主流程控制。4.2 父子类事件的绑定规则与坑EventBus在寻找订阅方法时不是只看事件的运行时类型而是考虑了继承关系。具体来说它使用TypeToken来判断一个订阅方法是否可以接收某个事件对象。举个例子public class AnimalEvent {} public class DogEvent extends AnimalEvent {} Subscribe public void onAnimal(AnimalEvent event) { ... } eventBus.post(new DogEvent());这段代码中DogEvent会同时被onAnimal接收到。因为DogEvent是AnimalEvent的子类EventBus认为它也是一个AnimalEvent。这个特性有时候是便利有时候是灾难。假设你有个订阅方法接收Object类型那几乎所有的event都会触发它这个订阅者的执行次数会非常惊人。我在一个项目里见过有人图省事用Subscribe public void handleAll(Object event)来做统一日志记录结果那是那天线上最慢的一个方法。所以事件类的继承设计要克制不要为了省事让所有事件都继承同一个父类然后只监听父类除非你就是要做全局拦截。另外要注意的是EventBus对泛型事件的支持是有限的。如果你定义了一个WrapperEventT那么在订阅时按WrapperEventOrder去匹配可能会踩坑因为泛型擦除之后事件的运行时类型实际上是WrapperEvent而不是带泛型参数的WrapperEventOrder。我自己试过结论是EventBus并不按泛型参数区分订阅方法它会匹配到所有WrapperEvent的订阅者。这个细节很容易让人误解泛型事件也能精准路由。4.3 注册数据结构的内部实现最后看一眼EventBus的注册表实现。它内部其实就是一个ConcurrentMapClass?, CopyOnWriteArraySetSubscriber的结构key是事件类型value是订阅者方法集合。这个设计的含义有两点。第一CopyOnWriteArraySet保证读多写少的并发场景性能不错所以EventBus对频繁订阅、偶尔发布的场景优化得比较好。第二注册的时间顺序是有保证的同一个事件被多个订阅者接收时执行顺序是注册顺序也就是先注册的先调用。这个顺序特性在有些场景下是有业务含义的比如你要保证先记录审计日志再执行核心逻辑那注册顺序就不能乱。不过有个谨慎点如果你依赖了注册顺序执行顺序这个约定那一定要在代码注释里写清楚否则后来维护的人随手调整了Bean的加载顺序你的顺序约定就悄悄失效了。这不是框架bug是设计脆弱性。5. EventBus与MQ的选型边界别拿大炮打蚊子也别拿牙签捅大象5.1 什么场景下该用EventBus而不是MQ我在文章开头提到了那个单体项目的例子。当你遇到以下几种情况单进程内所有组件都在同一个JVM里没有跨服务调用的需求解耦但不跨进程只是想拆分模块间的直接依赖比如订单模块不直接调用短信模块对可靠性要求中等事件丢了影响不大最多是某个非核心通知遗漏不会造成资金损失不想引入额外中间件团队规模不大运维能力有限不想维护一套消息集群在这些条件下EventBus就是最优解。它的成本极低——就是一个jar包加几行代码没有任何部署依赖。对比一下上RabbitMQ或Kafka你得部署Broker、配置交换机、考虑分区和副本、处理网络抖动、应对消费者Rebalance……如果只是为了在单体应用里做个事件通知完全是大炮打蚊子。我参与过一个项目团队在单体阶段就强行上了Kafka理由是反正以后要拆分先准备好基础架构。结果呢消息中间件集群的运维成本远超预期而且消息生产者和消费者的耦合并没有因为用了Kafka就自动解开反而因为序列化、Topic管理、消费位点这些问题让简单的事情变得很复杂。最终架构师被迫把一部分场景回退成了进程内EventBus。5.2 什么场景下EventBus是杯水车薪反过来你也得认清EventBus的硬边界跨进程通信比如订单服务需要通知积分服务和库存服务这两个服务跑在不同的应用进程里EventBus完全不支持。持久化和高可靠EventBus不会持久化任何事件进程一重启所有未处理的事件全部丢失。削峰填谷如果某个时段瞬间产生大量事件EventBus的线程池撑不住就直接拒绝或丢消息它没有MQ那种消息积压再慢慢消费的能力。分布式事务一致性如果你需要用消息驱动不同服务间的一致性事务EventBus更是无能为力。我见过一个比较可惜的项目代码里用AsyncEventBus处理订单超时关单这种关键业务结果进程重启时积压的关单事件全丢了造成了一批异常订单。这其实就是选型不当。凡是影响资金、核心订单状态、核心数据一致性的场景强制要求持久化消息进程内总线只能在非关键路径上兜底。5.3 怎么判断是否具备升级到MQ的必要性很多团队在单体阶段做了EventBus后面业务增长拆分了服务这时候怎么平稳迁移我的建议是在EventBus的基础上做一层薄封装。具体做法是定义一个自己的DomainEventPublisher接口业务代码只依赖这个接口不直接依赖EventBus的post方法。这样将来要迁移到MQ你只需要换一个实现类把事件真正转发给MQ的生产者业务代码一行不用改。public interface DomainEventPublisher { void publish(BaseEvent event); } Service public class GuavaEventPublisher implements DomainEventPublisher { private final EventBus eventBus; public void publish(BaseEvent event) { eventBus.post(event); } }这个封装看起来多此一举但在架构演进的关键节点上它是你最大的底气。我在两个项目里都因为这个封装省掉了大量迁移成本每次想到这点都觉得当初多花的半小时非常值。6. 实战中踩过的坑与排查思路6.1 事件凭空消失的排查链条有一次线上反馈部分用户的积分没有到账。我们初步判断是某个积分消息没被处理但翻日志又什么异常都没有。排查过程是这样的第一步确认是否走到了post语句。通过日志我们发现post确实被调用了因为下单流程里打印了开始发布积分事件的日志。第二步确认是否有订阅者注册。我直接写了个测试代码在启动的时候通过反射拿到EventBus内部注册表打印出了一共有哪些事件类型注册过。结果发现积分事件对应的订阅者确实存在。第三步问题出在哪后来我仔细看代码才发现EventBus.post()在没有匹配到订阅者的场景下会通过SubscriberRegistry检查如果找不到匹配的订阅方法就静默忽略。但我们的场景是匹配到了订阅者只是订阅者方法里第一行就catch了所有异常然后打印debug日志——好巧不巧那个等级是debug线上logback配置没开debug输出。所以这个事件消失的真正原因订阅者方法内部吞掉了异常日志等级掩盖了线索。不是EventBus吞事件是我们的代码把失败隐藏了。这个坑的教训非常深刻后来我在团队里强推了两条规矩订阅者方法里不允许catch后不重新抛出或记录error日志EventBus发布和订阅的两端必须打印对应的trace日志并且日志中包含同一个事件ID6.2 慢订阅者如何拖垮全局线程池再分享一个更隐蔽的坑。某次大促期间系统CPU突然居高不下线程池拒绝执行大量任务各种接口超时。排查下来罪魁祸首是一个异步订阅者方法里做了数据库批量查询数据量一大单次执行时间从50毫秒涨到800毫秒线程池的队列瞬间被打满。表面上看是数据库查询慢本质上是我设计的线程池隔离不足。所有事件都在同一个线程池执行有的快有的慢互相干扰。后来我把线程池按业务分组拆成多个比如订单事件一个池、日志事件一个池、通知事件一个池并且给每个池设置不同的核心线程数和队列大小。这样即使通知服务抖了一下也不会波及到核心订单事件的处理。这条经验我后来也用在很多其他中间件的连接池、线程池设计上——隔离比调参更根本。先隔离开再谈优化。6.3 订阅者执行顺序的隐性约定与破坏前面提到EventBus按注册顺序执行订阅者。在一个项目里我们依赖这个顺序做业务先审计、后变更状态。后来有人为了代码美观用Bean注解重新排列了配置类的顺序结果事件执行顺序变了导致审计日志比状态变更晚了半步某些对账逻辑就出了问题。这个问题排查起来特别容易绕远路因为代码逻辑没有变纯粹是注册顺序变了。最后是在测试环境里通过打印注册顺序才定位到的。我的建议是如果你的业务依赖订阅顺序干脆在订阅方法内部显式做阶段判断不要依赖注册顺序。比如给事件带一个phase字段订阅方法里根据phase决定自己要不要处理这样注册顺序随便变都不影响正确性。6.4 检查订阅者是否可重入与幂等EventBus不保证消息只处理一次。如果同一个事件在异常重试流程中被再次post你的订阅者就会重复执行。特别是异步线程池结合重试机制的场景重复消费概率不小。举例来说你有一个订单创建后发短信的订阅者如果发布者在post之前发现网络超时然后业务重试又post了一次那同一个订单就会收到两条短信。这在用户侧就是实际的客诉。解决办法是老生常谈的幂等设计在订阅者入口检查事件ID是否已经处理过用数据库唯一键或Redis的SETNX来做去重。不要嫌麻烦EventBus的便利性带来的隐含代价就是责任全部落在业务代码上——框架不管去重、不管顺序、不管事务。7. 一些实际工程里的使用习惯最后分享几个我自己的使用习惯它们不算什么了不起的技巧但都是被现实教育过之后沉淀下来的。第一个习惯是所有事件对象必须实现toString()内容至少要包含eventId和timestamp。排查问题时你会发现日志里能打印出一个可读的事件对象有多重要。如果事件对象没有toString日志输出就是一坨com.example.event.OrderCreatedEvent1a2b3c一点排查价值都没有。第二个习惯是所有订阅方法都尽量保持轻判断、快执行。在方法入口先做必要的条件过滤不满足就直接返回不要拖到后半段再判断。这样既提高执行效率也降低出错概率。第三个习惯是异步线程池的监控指标要接入最核心的几个队列深度、活跃线程数、拒绝次数。这些指标能在问题发生前给出预警而不是等问题把系统拖垮了才从告警里发现。第五个习惯是安全打印和脱敏。所有事件里如果包含手机号、身份证号等信息日志里务必脱敏这是合规底线不用多说。说到这儿如果让我用一句话总结EventBus的定位它是单体应用阶段最值得用的进程内解耦工具轻巧、灵活、无侵入但它的边界非常清晰——所有依赖它实现可靠消息传递的想法都是在错误的场景里用它。理解它的线程模型和边界之后你就能放心地把非核心链路交给它而把核心可靠性留给真正合适的中间件。