Java的UUID.randomUUID有多好？

本文翻译自：How good is Java's UUID.randomUUID?

I know that randomized UUIDs have a very, very, very low probability for collision in theory, but I am wondering, in practice, how good Java's randomUUID() is in terms of not having collision? 我知道随机UUID在理论上具有非常非常非常低的碰撞概率，但我想知道，在实践中，Java的randomUUID()在没有碰撞方面有多好？ Does anybody have any experience to share? 有没有人有经验可以分享？

---

#1楼

参考：https://stackoom.com/question/AXtV/Java的UUID-randomUUID有多好

---

#2楼

I'm not an expert, but I'd assume that enough smart people looked at Java's random number generator over the years. 我不是专家，但我认为多年来有足够聪明的人看着Java的随机数生成器。 Hence, I'd also assume that random UUIDs are good. 因此，我还假设随机UUID是好的。 So you should really have the theoretical collision probability (which is about 1 : 3 × 10^38 for all possible UUIDs. Does anybody know how this changes for random UUIDs only? Is it 1/(16*4) of the above?) 因此，您应该确实具有理论冲突概率（对于所有可能的UUID，大约为1： 3×10 ^ 38。是否有人知道这对于随机UUID的变化情况如何？是上述的1/(16*4)吗？）

From my practical experience, I've never seen any collisions so far. 根据我的实际经验，到目前为止我从未见过任何碰撞。 I'll probably have grown an astonishingly long beard the day I get my first one ;) 我得到第一个胡子的那天，我可能已经长了一个令人惊讶的长胡子;）

---

#3楼

Does anybody have any experience to share? 有没有人有经验可以分享？

There are 2^122 possible values for a type-4 UUID. 类型4 UUID有2^122可能的值。 (The spec says that you lose 2 bits for the type, and a further 4 bits for a version number.) （规范说你输入的类型为2位，版本号又输了4位。）

Assuming that you were to generate 1 million random UUIDs a second, the chances of a duplicate occurring in your lifetime would be vanishingly small. 假设您每秒产生100万个随机UUID，那么在您的生命中发生重复的可能性将会非常小。 And to detect the duplicate, you'd have to solve the problem of comparing 1 million new UUIDs per second against all of the UUIDs you have previously generated ¹ ! 要检测重复，您必须解决每秒比较100万个新UUID与您之前生成的所有UUID ^1的问题 ！

The chances that anyone has experienced (ie actually noticed ) a duplicate in real life are even smaller than vanishingly small ... because of the practical difficulty of looking for collisions. 任何人在现实生活中经历（即实际注意到 ）重复的机会甚至小于消失的小......因为寻找碰撞的实际困难。

Now of course, you will typically be using a pseudo-random number generator, not a source of truly random numbers. 当然，您通常会使用伪随机数生成器，而不是真正随机数的源。 But I think we can be confident that if you are using a creditable provider for your cryptographic strength random numbers, then it will be cryptographic strength, and the probability of repeats will be the same as for an ideal (non-biased) random number generator. 但我认为，我们可以相信，如果你正在使用你的加密强度随机数的可信供应商，那么这将是加密强度，并重复的概率是相同的理想（不带偏见的）随机数发生器。

However, if you were to use a JVM with a "broken" crypto- random number generator, all bets are off. 但是，如果您使用带有“损坏”加密随机数生成器的JVM，则所有投注均已关闭。 (And that might include some of the workarounds for "shortage of entropy" problems on some systems. Or the possibility that someone has tinkered with your JRE, either on your system or upstream.) （这可能包括某些系统上“熵短缺”问题的一些解决方法。或者有人在你的系统或上游修改了你的JRE。）

---

^{1 - Assuming that you used "some kind of binary btree" as proposed by an anonymous commenter, each UUID is going to need O(NlogN) bits of RAM memory to represent N distinct UUIDs assuming low density and random distribution of the bits. 1 - 假设您使用匿名评论者提出的“某种二进制btree”，每个UUID将需要O(NlogN)位的RAM内存来表示N不同的UUID，假设低密度和比特的随机分布。 Now multiply that by 1,000,000 and the number of seconds that you are going to run the experiment for. 现在乘以1,000,000以及您要运行实验的秒数。 I don't think that is practical for the length of time needed to test for collisions of a high quality RNG. 我认为测试高质量RNG碰撞所需的时间长度并不实用。 Not even with (hypothetical) clever representations. 甚至没有（假设的）聪明的表示。}

---

#4楼

UUID uses java.security.SecureRandom , which is supposed to be "cryptographically strong". UUID使用java.security.SecureRandom ，它应该是“加密强大的”。 While the actual implementation is not specified and can vary between JVMs (meaning that any concrete statements made are valid only for one specific JVM), it does mandate that the output must pass a statistical random number generator test. 虽然未指定实际实现，并且JVM之间可能有所不同（意味着所做的任何具体语句仅对一个特定JVM有效），但它确实要求输出必须通过统计随机数生成器测试。

It's always possible for an implementation to contain subtle bugs that ruin all this (see OpenSSH key generation bug) but I don't think there's any concrete reason to worry about Java UUIDs's randomness. 实现总是可能包含破坏所有这些的微妙错误（请参阅OpenSSH密钥生成错误），但我认为没有任何具体的理由担心Java UUID的随机性。

---

#5楼

We have been using the Java's random UUID in our application for more than one year and that to very extensively. 我们已经在我们的应用程序中使用Java的随机UUID超过一​​年，而且非常广泛。 But we never come across of having collision. 但我们从来没有遇到过碰撞。

---

#6楼

I play at lottery last year, and I've never won .... but it seems that there lottery has winners ... 去年我在乐透区比赛，我从未赢过......但似乎有彩票有赢家......

doc : http://tools.ietf.org/html/rfc4122 doc： http ： //tools.ietf.org/html/rfc4122

Type 1 : not implemented. 类型1：未实现。 collision are possible if the uuid is generated at the same moment. 如果在同一时刻生成uuid，则可能发生冲突。 impl can be artificially a-synchronize in order to bypass this problem. impl可以人为地同步以绕过这个问题。

Type 2 : never see a implementation. 类型2：永远不会看到实现。

Type 3 : md5 hash : collision possible (128 bits-2 technical bytes) 类型3：md5哈希：可能发生冲突（128位-2技术字节）

Type 4 : random : collision possible (as lottery). 类型4：随机：可能发生碰撞（作为抽奖）。 note that the jdk6 impl dont use a "true" secure random because the PRNG algorithm is not choose by developer and you can force system to use a "poor" PRNG algo. 请注意，jdk6 impl不使用“真正的”安全随机因为开发人员不选择PRNG算法，您可以强制系统使用“差”PRNG算法。 So your UUID is predictable. 所以你的UUID是可预测的。

Type 5 : sha1 hash : not implemented : collision possible (160 bit-2 technical bytes) 类型5：sha1哈希：未实现：可能发生冲突（160位-2技术字节）