OpenTripPlanner实时更新中的并发修改异常问题分析与解决

问题背景

在OpenTripPlanner（OTP）这一开源多模式交通规划系统中，Transmodel API是其提供的重要功能接口之一。近期在生产环境中发现，当使用/datedServiceJourneys数据获取器进行GraphQL API调用时，系统会间歇性地抛出ConcurrentModificationException异常，导致API调用失败。

异常现象

从异常堆栈信息可以清晰地看到，问题发生在DatedServiceJourneyQuery.java的第161行，当尝试对TransitModelIndex.tripOnServiceDateForTripAndDay集合进行操作时，出现了并发修改异常。这种异常通常发生在多线程环境下，当一个线程正在遍历集合而另一个线程同时修改该集合时。

技术分析

根本原因

1. 共享集合的线程安全问题： TransitModelIndex.tripOnServiceDateForTripAndDay是一个在多线程环境下共享的集合数据结构。在OTP系统中，这个集合会被实时更新线程和API查询线程同时访问。

2. 实时更新机制： OTP支持实时数据更新，这意味着后台线程会定期更新行程信息。当实时更新线程修改tripOnServiceDateForTripAndDay集合时，如果恰好有API查询线程正在遍历该集合，就会触发并发修改异常。

3. 集合遍历方式： 从堆栈信息可以看到，异常发生在使用Java Stream API对HashMap进行遍历操作时。HashMap本身不是线程安全的集合实现。

影响范围

这个问题主要影响：

• 使用Transmodel API查询日期服务行程的客户端
• 依赖实时更新的应用场景
• 高并发查询环境下的系统稳定性

解决方案

短期修复方案

1. 同步访问控制： 对tripOnServiceDateForTripAndDay集合的所有访问操作进行同步控制，可以使用synchronized关键字或ReentrantLock实现。

2. 使用线程安全集合： 将现有的HashMap替换为ConcurrentHashMap，这种专门为并发访问设计的集合实现。

长期架构改进

1. 读写分离设计： 实现读写分离的架构，维护两个数据副本：一个用于查询，一个用于更新。通过原子引用切换来实现无锁访问。

2. 不可变数据结构： 采用不可变集合，每次更新都创建新的集合实例，通过volatile引用保证可见性。

3. 事件总线机制： 引入事件总线模式，将实时更新事件化，减少直接对共享数据的并发访问。

实施建议

1. 性能考量： 在实现同步控制时，需要考虑粒度问题。过粗的锁粒度会影响系统吞吐量，过细则增加复杂性。

2. 测试验证： 修改后需要进行充分的并发测试，特别是高负载下的稳定性测试。

3. 监控机制： 增加对集合访问的监控，及时发现潜在的并发问题。

总结

OpenTripPlanner作为实时交通规划系统，其并发控制机制至关重要。这次发现的ConcurrentModificationException揭示了系统在实时更新与查询并发处理上的不足。通过合理的同步策略或架构改进，可以显著提升系统的稳定性和可靠性。对于类似的多线程数据访问场景，开发者应当特别注意共享数据结构的线程安全性，这是构建高可用分布式系统的关键要素之一。