正如@stuartmarks在评论中指出的那样，guava支持 Ordering.arbitrary() ，它提供线程安全的冲突处理。该实现有效地利用了 identityHashCode :

@Override
public int compare(Object left, Object right) {
  if (left == right) {
    return 0;
  } else if (left == null) {
    return -1;
  } else if (right == null) {
    return 1;
  }
  int leftCode = identityHashCode(left);
  int rightCode = identityHashCode(right);
  if (leftCode != rightCode) {
    return leftCode < rightCode ? -1 : 1;
  }

  // identityHashCode collision (rare, but not as rare as you'd think)
  int result = getUid(left).compareTo(getUid(right));
  if (result == 0) {
    throw new AssertionError(); // extremely, extremely unlikely.
  }
  return result;
}

所以只有在哈希冲突的情况下， getUid 调用（它使用一个已记忆的原子整数计数器来分配uid）。
在“one”行中编写所需的带时间戳的消息容器也非常容易（可能不太容易阅读？）：

db = new ConcurrentSkipListSet<>(
                (Ordering.<Float>natural().<ImmutablePair<Float,Message>>onResultOf(x -> x.left))
                        .compound(Ordering.arbitrary().nullsFirst().<ImmutablePair<Float,Message>>onResultOf(x -> x.right)))

虽然这不能保证，但我怀疑这导致问题的可能性非常小。 System.identityHashCode 返回 Object.hashCode 如果不重写，将返回，包括在文档中：
尽可能地实际，由类对象定义的hashcode方法为不同的对象返回不同的整数。
那么，“尽可能实际”就足够了吗？虽然这不能保证，但如果你遇到这样的情况，我会非常惊讶。您必须有两个时间戳完全相同的消息，并且jvm的位置完全相同 Object.hashCode 实现为两条消息返回相同的值。
如果巧合的结果是“核电站爆炸”，那么我就不会冒险了。如果这种巧合的结果是“我们没有给客户开账单”——甚至是“我们给客户开了两次账单，可能会被起诉”，如果没有更好的替代建议，我可能会接受这个机会。

comparator.comparing（system:：identityhashcode）能工作吗？还有别的办法吗？
如前所述，identityhashcode不是唯一的。
实际上，64位散列值（而不是identityhashcode提供的32位值）可能就足够了
我认为这只是减少重叠的机会，而不是消除重叠。散列算法被设计用来限制重叠，但通常不能保证没有重叠。例如，md5是128位的，仍然有重叠。
给每封邮件分配一个唯一的号码怎么样 AtomicLong . 那么你的比较函数会：
按时间比较。如果可能的话，我会用long代替float。
如果相同，则按唯一值进行比较。
如果有多个系统接收这些消息，则需要记录唯一的系统id和消息编号，以确保唯一性。