OpenTelemetry Java SDK中ConfigUtil的ConcurrentModificationException问题解析

在OpenTelemetry Java SDK 1.42.1版本中，开发者报告了一个关于ConfigUtil工具类的并发修改异常问题。这个问题主要出现在Android环境下，当系统属性被并发修改时，会导致LongGaugeBuilder构建过程中抛出ConcurrentModificationException异常。

问题背景

OpenTelemetry的指标构建器在初始化时会通过ConfigUtil读取系统属性配置。DebugConfig类在静态初始化块中调用ConfigUtil.getString()方法，而该方法底层使用了System.getProperties()来获取系统属性。由于Properties类本身不是线程安全的，当系统属性被其他线程修改时，就会导致迭代过程中出现并发修改异常。

技术分析

从异常堆栈可以清晰地看到问题发生的路径：

1. LongGaugeBuilder.build()触发InstrumentDescriptor创建
2. 需要获取SourceInfo用于调试
3. DebugConfig类初始化时读取系统属性
4. ConfigUtil.getString()使用Properties的流式操作导致异常

Properties类继承自Hashtable，虽然Hashtable本身是线程安全的，但其迭代器Enumerator并不是快速失败的(fail-fast)。然而在多线程环境下，如果在迭代过程中有其他线程修改了哈希表，仍然可能导致ConcurrentModificationException。

解决方案探讨

开发团队讨论了多种可能的解决方案：

1. 使用防御性拷贝：通过new HashMap<>(System.getProperties())创建属性副本，但这种方式在拷贝过程中仍可能遇到并发问题。

2. 捕获异常处理：在迭代代码周围添加try-catch块捕获异常，但这只是治标不治本的方法。

3. 使用keys()枚举：Properties/Hashtable的keys()方法返回的枚举器不是快速失败的，理论上可以避免并发修改异常，但需要进一步测试验证。

4. 完全拷贝属性集合：使用System.getProperties().entrySet().stream().toArray()或Set.copyOf()创建不可变副本，这能确保迭代安全，但无法感知后续的属性变化。

最佳实践建议

对于这类系统属性读取的场景，建议采用以下方案：

1. 在首次读取时创建属性的不可变快照，后续操作基于这个快照进行
2. 如果需要实时获取最新属性值，可以使用同步块保护读取过程
3. 考虑使用ConcurrentHashMap作为属性缓存，但要注意内存开销

对于OpenTelemetry这类观测性工具来说，系统属性的读取通常只需要在初始化阶段进行一次，因此采用防御性拷贝是最稳妥的方案。即使后续系统属性发生变化，也不会影响已经初始化的配置。

总结