Java 中使用 UUID 最高有效位发生冲突的可能性

Question

如果我使用 Long uuid = UUID.randomUUID().getMostSignificantBits() 发生碰撞的可能性有多大。 它会切断最低有效位，因此有可能会遇到冲突，对吧？

Answer 1

根据 文档，静态方法 < code>UUID.randomUUID() 生成类型 4 UUID。

这意味着 6 位用于某些类型信息，其余 122 位是随机分配的。

六个非随机位分布在 UUID 的最高有效一半中，两个在最低有效一半中。 因此，UUID 的最重要的一半包含 60 位随机性，这意味着您平均需要生成 2^30 个 UUID 才能发生冲突（相比之下，完整 UUID 需要生成 2^61 个）。

所以我想说你还是比较安全的。 但请注意，正如 Carl Seleborg 提到的那样，对于其他类型的 UUID 来说绝对不是这样。

顺便说一句，使用 UUID 的最低有效一半（或者只是使用 SecureRandom 生成随机长整数）会稍微好一些。

Answer 2

Raymond Chen 在这方面有一篇非常出色的博客文章：

GUID 是全球唯一的，但是GUID 的子字符串不是

Answer 3

我认为这是使用 randomUUID 的最佳示例：

http://www.javapractices。 com/topic/TopicAction.do?Id=56

Answer 4

您最好只生成一个随机长值，然后所有位都是随机的。 在 Java 6 中，new Random() 使用 System.nanoTime() 加上一个计数器作为种子。

有不同程度的独特性。

如果您需要在多台机器上保持唯一性，您可以使用一个中央数据库表来分配唯一 ID，甚至批量分配唯一 ID。

如果您只需要在一个应用程序中具有唯一性，您可以只拥有一个计数器（或根据您的要求从 currentTimeMillis()*1000 或 nanoTime() 开始的计数器）

Answer 5

使用时间 YYYYDDDD（年 + 一年中的某天）作为前缀。 这减少了表和索引中的数据库碎片。 此方法返回byte[40]。 我在混合环境中使用了它，其中 Active Directory SID (varbinary(85)) 是 LDAP 用户的密钥，应用程序自动生成的 ID 用于非 LDAP 用户。 此外，交易表（银行业）中每天的大量交易不能使用标准 Int 类型作为键

private static final DecimalFormat timeFormat4 = new DecimalFormat("0000;0000");

public static byte[] getSidWithCalendar() {
    Calendar cal = Calendar.getInstance();
    String val = String.valueOf(cal.get(Calendar.YEAR));
    val += timeFormat4.format(cal.get(Calendar.DAY_OF_YEAR));
    val += UUID.randomUUID().toString().replaceAll("-", "");
    return val.getBytes();
}