Black项目中的LRU缓存污染问题解析

在Python代码格式化工具Black的开发过程中，开发团队遇到了一个非常有趣的测试失败问题。这个问题揭示了在多进程测试环境下LRU缓存使用不当可能导致的隐蔽错误。

问题现象

当Black项目的测试用例数量超过367个，并且使用pytest的--numprocesses参数设置为4、6或8时，两个特定的测试用例会失败。这两个测试用例分别是test_get_sources_with_stdin_filename_and_exclude和test_get_sources_with_stdin_filename_and_extend_exclude。

问题分析

通过深入调查，发现问题根源在于files.py模块中的_cached_resolve函数。这个函数使用了Python的lru_cache装饰器来缓存路径解析结果，目的是提高性能。然而，在多进程测试环境下，这种缓存机制导致了测试间的相互干扰。

具体来说，test_get_sources_with_stdin_symlink_outside_root测试用例会修改缓存状态，进而影响了后续测试的执行结果。这种测试间的相互影响被称为"测试污染"。

技术背景

LRU(Least Recently Used)缓存是Python中常用的性能优化技术，通过functools.lru_cache装饰器实现。它会缓存函数的调用结果，当相同参数再次传入时直接返回缓存结果，避免重复计算。

然而，在多进程环境下，缓存状态可能会带来以下问题：

1. 缓存可能在不同进程间不一致
2. 测试间的执行顺序会影响缓存状态
3. 缓存可能保留前一个测试修改的状态

解决方案

修复方案很简单：移除_cached_resolve函数的lru_cache装饰器。虽然这会带来轻微的性能损失，但保证了测试的可靠性和一致性。

对于确实需要缓存的场景，开发者应该考虑：

1. 使用测试夹具(setup/teardown)来重置缓存状态
2. 为每个测试创建独立的缓存实例
3. 或者完全避免在多进程测试中使用全局缓存

经验教训

这个案例给开发者提供了几个重要启示：

1. 性能优化技术(如缓存)需要谨慎使用，特别是在测试环境中
2. 多进程测试会放大状态共享问题
3. 测试失败可能由完全不相关的测试引起，需要系统性的排查方法
4. 测试数量和执行顺序可能暴露出隐藏的问题

在Black这样的重要开源项目中，即使是看似微小的优化也可能产生意想不到的后果，因此需要全面的测试覆盖和仔细的问题排查。