我竟然能踩中JDK的这个超极限BUG？

本文共计2264个文字，预计阅读时间需要10分钟。

嗨，大家好，我是小楼。最近遇到了一个文件监听变慢的问题，刚好这周末有空研究了下，整理了一下心得，分享给大家。从一次故障说起，我们发现通过故障分析，能更贴近实际，也更能让人信服。

hello，大家好呀，我是小楼。

之前遇到个文件监听变更的问题，刚好这周末有空研究了一番，整理出来分享给大家。

从一次故障说起

我们还是从故障说起，这样更加贴近实际，也能让大家更快速理解背景。

有一个下发配置的服务，这个配置服务的实现有点特殊，服务端下发配置到各个服务的本地文件，当然中间经过了一个agent，如果没有agent也就无法写本地文件，然后由client端的程序监听这个配置文件，一旦文件有变更，就重新加载配置，画个架构图大概是这样：

今天的重点是文件的变更该如何监听（watch），我们当时的实现非常简单：

• 单独起个线程，定时去获取文件的最后更新时间戳（毫秒级）
• 记录每个文件的最后更新时间戳，根据这个时间戳是否变化来判断文件是否有变更

从上述简单的描述，我们能看出这样实现有一些缺点：

• 无法实时感知文件的变更，感知误差在于轮询文件最后更新时间的间隔
• 精确到毫秒级，如果同一毫秒内发生2次变更，且轮询时刚好落在这2次变更的中间时，后一次变更将无法感知，但这概率很小

还好，上述两个缺点几乎没有什么大的影响。