OpenRewrite项目中RecipeRunStats文件计数异常问题分析

在OpenRewrite项目的实际使用过程中，我们发现RecipeRunStats.csv中记录的"edited source files"数值存在异常现象。该数值在某些情况下会显著超过项目实际包含的源文件总数，这给开发者通过数据表格分析"极端"配方(recipe)带来了困扰。

问题现象

当在小型项目上启用数据表功能并查看RecipeRunStats.csv时，如果按照第一列(编辑过的源文件)排序，可以观察到某些配方的文件计数明显高于项目实际包含的文件总数。例如在一个仅有2600个文件的项目中，某些配方的计数却达到了数万。

技术分析

经过深入代码分析，发现问题根源在于RecipeRunCycle.java文件中的统计逻辑。当前实现中，文件计数器在两层嵌套循环(配方循环和文件循环)中被无条件递增，导致最终计数变成了"文件数×配方数"的乘积关系。

具体来说，recordEdit方法被调用的位置存在问题。该方法目前位于循环内部，但未考虑visitor.isAcceptable()的条件判断。理想情况下，只有当文件确实被配方接受处理时，才应该增加计数器。

进一步研究发现，当同一个配方以不同参数多次执行时，由于使用相同的配方名称作为标签(tag)，CumulativeTimer#recordNonNegative方法会自动为相同配方的计数器进行累加。这就解释了为何某些可配置配方的计数会异常偏高。

解决方案探讨

针对此问题，我们提出了几种可能的解决方案：

1. 条件计数：将计数器递增逻辑移至visitor.isAcceptable()条件判断内部，确保只有实际处理的文件才被统计。

2. 计时器改进：考虑使用不同类型的Timer实现，或者在现有基础上进行修改，避免相同配方的多次执行导致计数累加。

3. 标签策略调整：为相同配方但不同参数的情况创建不同的标签，但在最终输出前合并统计结果。

经过验证，第一种方案最为直接有效，能够确保统计数字真实反映实际处理的文件数量，而不会影响其他统计指标(如处理时间)的准确性。

影响评估

需要特别说明的是，此问题仅影响统计数据的准确性，不会对实际的代码重写功能产生任何负面影响。修复后，开发者将能够更准确地通过数据表格分析各个配方的行为特征，识别异常情况。

最佳实践建议

对于使用OpenRewrite数据统计功能的开发者，我们建议：

1. 定期检查RecipeRunStats.csv中的数据合理性
2. 对于异常高的文件计数保持警惕
3. 结合项目实际文件数量验证统计结果
4. 关注项目更新，及时应用修复版本

该问题的修复将显著提升OpenRewrite数据统计功能的可靠性和实用性，帮助开发者更好地理解和优化重写过程。