等待处理器中的通知信号是否超时或如何彻底清理所有通知信号

问：

我有一个算法，在流文件中，我创建了一个流文件 uuid 队列，我必须从上到下处理。uuid 被写入这个用换行符分隔的流文件中，因此每行的 uuid 表示下一个要处理的流文件。这是我们向等待处理器发出的通知信号。

此流文件根据我正在处理的对象的 ID 进行缓存。因此，对于这个具有给定 id 的对象，我一次只能从上到下处理 uuid 队列中的一个流文件。

根据我的数据对象 ID，有多个这样的缓存流文件。因此，对于具有特定 id 的任何给定数据对象，只能有一个流文件正在进行中。不同的数据对象具有不同的 id，允许在我的流程中并行。这是我的观点，但这总结了我的算法。

所以对于手头的问题。一旦某个 id 的给定数据对象的流文件完成，我就会从队列顶部删除此流文件的 uuid。将此流文件缓存回（在分布式缓存服务器中）。然后获取下一个要处理的 uuid 并通知此。

现在我正在处理失败场景，理论上可能发生的一种情况是，一旦给定数据对象 ID 的流文件完成，它将返回以从队列头中删除其 uuid。删除后，它将拾取队列中的下一个 uuid 并通知它。因此，现在已经发生了下一个 uuid 的通知。

但与此同时，带有此 uuid 的流文件将过期，不再位于等待处理器中。

这个过期的流文件也会进入队列，它会搜索其 uuid 并将其从队列中删除。对于来自等待处理器的过期/失败关系，他们可以从队列中的任何位置删除 uuid，因为队列中一直在等待的消息将过期。此时，已过期邮件的工作已完成。

但是现在我们在等待处理器中有这个挂起的通知信号。

问题是，delta 值为零的通知处理器能否在等待处理器中清除此数据对象 ID 的触发信号？清理是按顺序进行的，即通知已经发生，如前所述，我稍后会带着过期的流文件回来，并且只能进行此清理。此清理是否在此时间点有任何影响，即取消不存在的流文件的信号，因为它已移动到过期关系？

这些悬空的通知信号对等待处理器来说是否很重？