如果我使用Long uuid = uuid . randomuuid (). getmostsignificant bits()有多大可能发生碰撞。它切断了最不重要的位,所以有可能会发生碰撞,对吧?


当前回答

Raymond Chen对此有一篇非常棒的博文:

guid是全局唯一的,但guid的子字符串不是

其他回答

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

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

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

独特性有不同的层次。

如果需要在多台机器之间具有唯一性,可以使用一个中央数据库表来分配惟一的id,甚至是批量惟一的id。

如果你只需要在一个应用程序中有唯一性,你可以只需要一个计数器(或者一个从currentTimeMillis()*1000或nanoTime()开始的计数器,这取决于你的需求)

使用时间YYYYDDDD(年份+日期)作为前缀。这减少了表和索引中的数据库碎片。该方法返回字节[40]。我在一个混合环境中使用了它,其中Active Directory SID (varbinary(85))是LDAP用户的密钥,应用程序自动生成的ID用于非LDAP用户。此外,事务表(Banking Industry)中每天大量的事务不能使用标准Int类型作为key

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();
}

根据文档,静态方法UUID. randomuuid()生成一个类型4的UUID。

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

6个非随机位分布在UUID的最有效的一半,其中4个在最不有效的一半。所以你的UUID最重要的一半包含60位随机性,这意味着你平均需要生成2^30个UUID来获得碰撞(相比之下,完整的UUID为2^61)。

所以我想说你是相当安全的。但是请注意,正如Carl Seleborg提到的,对于其他类型的uuid来说,这是绝对不正确的。

顺便说一句,如果使用UUID中最不重要的那一半(或者使用securerrandom生成一个随机长),情况会稍微好一些。

Raymond Chen对此有一篇非常棒的博文:

guid是全局唯一的,但guid的子字符串不是