我正在使用Guava的EventBus来启动一些处理和报告结果。这是一个非常简单的可编译示例：
import com.google.common.eventbus.EventBus;
import com.google.common.eventbus.Subscribe;
public class Test {
public static class InitiateProcessing { }
public static class ProcessingStarted { }
public static class ProcessingResults { }
public static class ProcessingFinished { }
public static EventBus bus = new EventBus();
@Subscribe
public void receiveStartRequest(InitiateProcessing evt) {
System.out.println("Got processing request - starting processing");
bus.post(new ProcessingStarted());
System.out.println("Generating results");
bus.post(new ProcessingResults());
System.out.println("Generating more results");
bus.post(new ProcessingResults());
bus.post(new ProcessingFinished());
}
@Subscribe
public void processingStarted(ProcessingStarted evt) {
System.out.println("Processing has started");
}
@Subscribe
public void resultsReceived(ProcessingResults evt) {
System.out.println("got results");
}
@Subscribe
public void processingComplete(ProcessingFinished evt) {
System.out.println("Processing has completed");
}
public static void main(String[] args) {
Test t = new Test();
bus.register(t);
bus.post(new InitiateProcessing());
}
}
我将这些事件用作其他软件组件的一种方式，以便为此处理做准备。例如，他们可能必须在处理之前保存其当前状态并在之后恢复它。
我希望这个程序的输出是：
Got processing request - starting processing
Processing has started
Generating results
got results
Generating more results
got results
Processing has completed
相反，实际输出是：
Got processing request - starting processing
Generating results
Generating more results
Processing has started
got results
got results
Processing has completed
应该指示处理已经开始的事件实际发生在实际处理之后（“生成结果”）。
查看源代码后，我理解为什么它会以这种方式运行。这是source code的相关EventBus。
/**
* Drain the queue of events to be dispatched. As the queue is being drained,
* new events may be posted to the end of the queue.
*/
void dispatchQueuedEvents() {
// don't dispatch if we're already dispatching, that would allow reentrancy
// and out-of-order events. Instead, leave the events to be dispatched
// after the in-progress dispatch is complete.
if (isDispatching.get()) {
return;
}
// dispatch event (omitted)
发生了什么事，因为我已经调度了顶级InitiateProcessing事件，其余的事件只是被推到了队列的末尾。我希望这与.NET事件类似，在所有处理程序完成之前调用事件不会返回。
我不太明白这个实现的原因。当然，事件保证是有序的，但周围代码的顺序完全失真。
有没有办法让总线按照描述运行并产生所需的输出？我确实读过Javadocs
EventBus保证它不会同时从多个线程调用订阅者方法，除非该方法通过承载@AllowConcurrentEvents批注明确允许它。
但我不认为这适用于此 - 我在单线程应用程序中看到了这个问题。
编辑
这里问题的原因是我在订阅者中进行了posting。由于事件总线不可重入，因此这些“子帖子”排队并在第一个处理程序完成后处理。我可以在if (isDispatching.get()) { return; }源中注释掉EventBus部分，一切都像我期望的那样 - 所以真正的问题是我通过这样做引入了哪些潜在的问题？似乎设计师做出了一个尽责的决定，不允许重入。
EventBus通常的运作原则是，将事件发布到总线的代码不应该关心订阅者对事件的处理方式，或者除了事件发布的命令之外的时间（在同步事件的情况下）巴士无论如何）。
如果您希望在方法过程中的特定时间调用特定方法，并且希望确保在方法继续之前完成这些方法（如您在示例中所示），为什么不直接调用这些方法？当您使用事件总线时，您明确地将代码与响应给定事件的确切事件分开。这在许多情况下是可取的，并且是EventBus存在的主要原因，但它似乎并不是你想要的。
我试着总结一下Guava的EventBus事件传递行为：
如果在时刻t1发布事件E1，则通知所有订户。如果其中一个订阅者在其@Subs-方法中发布了一个事件本身（稍后一刻），那么“新”事件E2将被排队并在之后传递。之后就意味着：毕竟@ t1的订阅方法确实从t1返回。
将这种“级联”事件发布与广度优先树遍历进行比较。
它似乎是EventBus的明确选择设计。
虽然发布到EventBus不会返回，直到所有“订阅者”都已发出信号。这些订阅者可能尚未开始执行。这意味着当第一个bus.post返回时，您继续下一个帖子，而没有任何干预用户开始处理。
public void post（Object event）将事件发布给所有注册用户。事件发布到所有订阅者后，此方法将成功返回，并且无论订阅者抛出任何异常。如果没有订阅者订阅了事件的类，并且事件不是DeadEvent，它将被包装在DeadEvent中并重新发布。
参数：event - 要发布的事件。
我知道这个问题已经有4年了，但我今天遇到了同样的问题。有一个简单（和反直觉）的变化来获得你想要的行为。根据https://stackoverflow.com/a/53136251/1296767，您可以将AsyncEventBus与DirectExecutor一起使用：
public static EventBus bus = new AsyncEventBus(MoreExecutors.newDirectExecutorService());
使用上述更改运行测试代码，结果正是您想要的：
Got processing request - starting processing
Processing has started
Generating results
got results
Generating more results
got results
Processing has completed