我不是专家，但我认为已经有足够多的聪明人研究过Java的随机数生成器。因此，我还假定随机uuid是好的。所以你应该有理论上的碰撞概率(对于所有可能的uuid，碰撞概率约为1:3 × 10^38)。有人知道这只对随机uuid有什么变化吗?是上面的1/(16*4)吗?)

从我的实际经验来看，到目前为止我还从未见过任何碰撞。我第一次留胡子的那天可能已经长出了惊人的长胡子;)

我不是专家，但我认为已经有足够多的聪明人研究过Java的随机数生成器。因此，我还假定随机uuid是好的。所以你应该有理论上的碰撞概率(对于所有可能的uuid，碰撞概率约为1:3 × 10^38)。有人知道这只对随机uuid有什么变化吗?是上面的1/(16*4)吗?)

从我的实际经验来看，到目前为止我还从未见过任何碰撞。我第一次留胡子的那天可能已经长出了惊人的长胡子;)

在以前的雇主那里，我们有一个包含随机uuid的唯一列。在部署后的第一周就发生了碰撞。当然，几率很低，但也不是零。这就是为什么Log4j 2包含UuidUtil.getTimeBasedUuid。只要在一台服务器上每毫秒生成的UUID不超过10,000个，它就会生成一个在8,925年内惟一的UUID。

维基百科给出了一个很好的答案 http://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions

the number of random version 4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion, computed as follows: ... This number is equivalent to generating 1 billion UUIDs per second for about 85 years, and a file containing this many UUIDs, at 16 bytes per UUID, would be about 45 exabytes, many times larger than the largest databases currently in existence, which are on the order of hundreds of petabytes. ... Thus, for there to be a one in a billion chance of duplication, 103 trillion version 4 UUIDs must be generated.

UUID的原始生成方案是将UUID版本与生成UUID的计算机的MAC地址以及自西方采用格里高利历法以来的100纳秒间隔数连接起来。通过表示空间(计算机)和时间(间隔数)中的单个点，值碰撞的机会实际上为零。

我去年买彩票，但我从来没有中过.... 但似乎彩票中了奖…

Doc: https://www.rfc-editor.org/rfc/rfc4122

类型1:未实现。如果uuid在同一时刻生成，则可能发生冲突。Impl可以人为地实现a同步，以绕过这个问题。

类型2:从未看到实现。

类型3:md5哈希:可能发生冲突(128位-2技术字节)

类型4:随机:可能发生碰撞(如抽签)。注意jdk6 impl没有使用一个“真正的”安全随机，因为PRNG算法不是由开发人员选择的，你可以强制系统使用一个“糟糕的”PRNG算法。所以UUID是可预测的。

类型5:sha1哈希:未实现:可能发生冲突(160位-2技术字节)