缓存过期：hazelcast如何处理集群节点上的非同步时钟

假设我有两个hazelcast节点没有保证同步`系统时间不要问我为什么要这样做，这只是一个假设问题：

假设节点1在开始系统中将其绝对时间设置为0。currentTimeMillis返回0，节点2将其绝对时间设置为1000

我创建了一个存储在节点1上的锁，并将其过期时间设置为100毫秒。它在节点1绝对时间100和节点2绝对时间1100到期。现在节点2加入集群。我还检索在节点2上运行的应用程序中的锁，而不尝试将其锁定在cource上，因为它仍然锁定在节点1上。现在，我持有对锁的两个ILock引用，一个在节点1上运行的应用程序中，另一个在节点2上运行的应用程序中

当我调用节点2上的ILock上的操作时，它会看到锁存储中的实际对象位于节点1上，因此它会远程调用节点1上的操作。在这一点上，我们还没有时间差的问题。如果我们等待100毫秒，节点1将使锁过期

但我们不等待。相反，我们关闭了节点1。锁被转移到节点2，因为节点1不再可用。在传输过程中，节点1上的LockResourceImpl.writeData方法将锁的数据写入某个缓冲区。然后，这个缓冲区被传输到节点2，LockResourceImpl.readData方法在那里读取它并设置自身的值

据我所知，时间戳只是复制到各个字段，而没有考虑节点2上的时钟可能不同。这意味着过期时间仍然是节点1设置的绝对时间100，而节点2系统时间已经是1000。这意味着锁立即过期，即使它不应该过期

---

我理解对了吗？这真的是个问题吗？

不，这不是问题。当节点死亡时，立即释放节点拥有的锁是标准行为。仔细想想，这是有道理的，因为死节点不需要锁，如果您在另一台机器上使用锁来强制定时等待，那么代码确实有问题

---

免责声明：我尚未调查此问题，但所描述的行为是集群系统（包括hazelcast系统）上的锁的标准行为。

如果节点1在开始时持有并管理锁，则您是对的。但是现在假设节点2上的线程1在开始时获得了锁。节点1关闭，在将锁传输到节点2时，锁错误地过期。现在，节点2上的线程2可以获取锁，即使它仍然应该由节点2上的线程1持有。如果过期处理不当，这会破坏一切。由于hazelcast提供锁过期服务，我有点希望它能正常工作……抱歉，最近两天不可用。你真的能复制这个吗？我想得到一个确定的答案。但是，在这种情况下，即使节点1在传输锁时关闭，锁也应该被释放并提供给节点2的线程1。我可以确认，在任何时候，锁都只能由一个线程持有。我不能复制它，我的观点只是基于我查看的源代码。我现在不能做任何事情，因为我在度假，我没有我的电脑。当你从vactaion回来，如果你发现任何与我描述不符的事情，请在这里分享。始终愿意学习：。祝你假期愉快。