ListChangeBuilder抛出NullPointerException的原因排查

你的猜想完全正确——这个NullPointerException几乎可以肯定是多线程同时修改ObservableList导致的竞态条件问题，而且JavaFX的ObservableList确实是非线程安全的。

具体原因拆解 #

从你提供的栈跟踪和代码来看：

1. 异常发生在ListChangeBuilder.findSubChange的if (idx >= change.to)行，说明此时change实例的to字段可能为null，或者change本身就是null。这是因为ListChangeBuilder是JavaFX集合内部用来跟踪变更状态的工具类，它完全没有考虑并发场景下的线程安全。
2. 你的触发代码getActivity().add(new ActivityEntry("..."))，从栈信息看是在一个独立线程（Thread.run，对应PubNub的消息处理线程）中执行的，而JavaFX的ObservableList（包括FXCollections.observableArrayList()返回的实例）设计为仅允许在JavaFX应用线程（UI线程）中访问和修改。

当非UI线程直接修改ObservableList时，会破坏内部的变更跟踪结构：多个线程同时操作ListChangeBuilder的内部状态（比如添加变更记录、修改索引范围），会导致数据竞争，使得findSubChange方法在查找变更记录时拿到了不完整或已被破坏的SubChange实例，最终抛出NullPointerException。

解决办法 #

要彻底解决这个问题，核心是确保所有对JavaFX集合的修改操作都在JavaFX应用线程中执行，具体可以这样做：

• 使用Platform.runLater(Runnable)将修改操作包装起来，切换到UI线程执行：

  Platform.runLater(() -> {
      getActivity().add(new ActivityEntry("..."));
  });
  

• 如果你需要在多线程环境下共享集合，可以先用FXCollections.synchronizedObservableList()包装你的ObservableList，这能保证集合本身的基础操作（如add/remove）的线程安全，但注意：变更通知仍然会在调用线程触发，所以还是需要结合Platform.runLater确保修改逻辑在UI线程执行，避免后续UI监听时出现问题。

总结 #

你的问题完全符合多线程修改非线程安全ObservableList的典型症状，只要把集合修改操作切换到JavaFX应用线程，就能避免这类不可复现的并发异常。

内容的提问来源于stack exchange，提问作者Pablo Fernandez