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

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

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

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

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

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

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

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

独特性有不同的层次。

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

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

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

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

使用时间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();
}