JSON Schema库中的引用解析缓存问题分析与解决方案

在Ruby生态中，JSON Schema验证库被广泛应用于各种多线程环境下的数据验证场景。近期在该库中发现了一个与URI引用解析相关的缓存问题，这个问题会导致在不同基础URL下解析相同片段标识符时出现错误结果。

问题背景

JSON Schema规范允许使用URI引用（如#foo）结合基础URL（如http://example.com）来构建完整的URI。在实现这一功能时，库内部使用了缓存机制来优化性能。然而，这个缓存实现存在一个关键缺陷：它会缓存片段标识符的解析结果，但后续会修改这个缓存对象，导致不同基础URL下的解析结果相互污染。

问题重现

通过以下测试用例可以稳定复现该问题：

# 第一次解析：期望得到 http://www.example.com/#foo
assert_equal(
  Addressable::URI.parse('http://www.example.com/#foo'),
  JSON::Util::URI.normalize_ref("#foo", 'http://www.example.com')
)

# 第二次解析：期望得到 http://www.example.net/#foo
assert_equal(
  Addressable::URI.parse('http://www.example.net/#foo'),
  JSON::Util::URI.normalize_ref("#foo", 'http://www.example.net')
)

实际运行中，第二次解析会错误地返回基于第一次基础URL的结果http://www.example.com#foo，而不是预期的http://www.example.net/#foo。

问题根源分析

问题的核心在于缓存实现方式不当：

1. 库将片段标识符（如#foo）的初始解析结果缓存起来
2. 后续使用时，直接修改这个缓存对象，为其添加基础URL
3. 由于Ruby中对象是引用传递，导致所有后续请求都共享同一个被修改过的URI对象

这种实现违反了缓存的基本原则——缓存的内容应该是不可变的。一旦缓存对象被修改，就会污染所有后续使用该缓存的请求。

解决方案

修复方案需要确保：

1. 缓存的对象应该是不可变的（immutable）
2. 或者在每次使用时创建缓存对象的深拷贝（deep copy）
3. 或者将基础URL作为缓存键的一部分

在实际修复中，开发者选择了在缓存前确保URI对象的不可变性，同时在必要时清空缓存来保证正确性。

多线程环境下的影响

这个问题在多线程环境下会表现得更加明显和危险：

1. 不同线程可能使用不同的基础URL解析相同的片段标识符
2. 由于缓存污染，线程间会产生不可预期的交叉影响
3. 可能导致验证结果随机错误，难以追踪和复现

最佳实践建议

在使用JSON Schema库时，特别是多线程环境下，开发者应该：

1. 及时更新到修复了此问题的版本
2. 对于关键业务场景，考虑在解析前主动清空缓存
3. 在测试用例中加入对URI解析正确性的验证
4. 避免在运行时动态修改基础URL

这个问题提醒我们，在使用缓存优化性能时，必须特别注意对象可变性带来的副作用，特别是在并发环境下，缓存实现需要更加谨慎和健壮。