在多线程/多进程单元测试期间，我经历过guid不是唯一的(也是?)我想这与所有其他条件相同的情况下，伪随机生成器的相同播种(或缺乏播种)有关。我用它来生成唯一的文件名。我发现操作系统在这方面做得更好:)

恶意破坏预警

你问guid是否100%唯一。这取决于它在guid中必须是唯一的。当guid的数量接近无穷大时，重复guid的概率接近100%。

在更广泛的意义上，这被称为“生日问题”或“生日悖论”。维基百科有一个很好的概述: 维基百科-生日问题

粗略地说，池大小的平方根是一个粗略的近似值，即您可以期望有50%的重复机会。这篇文章包含了一个关于池大小和各种概率的概率表，包括2^128的一行。所以对于1%的碰撞概率，你可以随机选择2.6*10^18个128位数字。50%的概率需要2.2*10^19次选择，而根号(2^128)是1.8*10^19次选择。

当然，这只是一个真正随机过程的理想情况。正如其他人所提到的，很多事情都取决于随机方面——生成器和种子有多好?如果有一些硬件支持来帮助这个过程，那就太好了，这将更加防弹，除非任何东西都可能被欺骗或虚拟化。我怀疑这可能是MAC地址/时间戳不再被合并的原因。

从统计上看，向导是独一无二的。两个不同的客户端生成相同Guid的几率非常小(假设Guid生成代码中没有错误)。你也可以担心由于宇宙射线导致的处理器故障，并决定今天2+2=5。

分配新guid的多个线程将获得唯一的值，但您应该知道您正在调用的函数是线程安全的。这是在哪个环境中?

I think that when people bury their thoughts and fears in statistics, they tend to forget the obvious. If a system is truly random, then the result you are least likely to expect (all ones, say) is equally as likely as any other unexpected value (all zeros, say). Neither fact prevents these occurring in succession, nor within the first pair of samples (even though that would be statistically "truly shocking"). And that's the problem with measuring chance: it ignores criticality (and rotten luck) entirely.

如果真的发生了，结果是什么?你的软件停止工作了吗?有人受伤了吗?有人死了吗?世界会爆炸吗?

临界性越极端，“概率”这个词就越难听。最后，链接guid(或XORing它们，或其他什么)是当你(主观地)认为你的特定临界性(和你的“幸运”感觉)是不可接受的时候所做的事情。如果它能毁灭世界，那么请代表我们所有没有参与大型强子对撞机核试验的人，不要使用guid或任何其他不确定的东西!

如果你的系统时钟设置正确，没有被环绕，如果你的网卡有自己的MAC(即你没有设置自定义MAC)，你的网卡供应商没有回收MAC(他们不应该这样做，但已经知道发生了)，如果你的系统的GUID生成功能正确实现，那么你的系统将永远不会生成重复的GUID。

如果地球上每个生成guid的人都遵循这些规则，那么您的guid将是全局唯一的。

在实践中，违反规则的人数很少，他们的guid不太可能“逃脱”。冲突在统计上是不可能发生的。

最难的部分不是生成重复的Guid。

最难的部分是设计一个数据库来存储所有生成的数据，以检查它是否实际上是重复的。

从维基:

例如，为了有至少一次碰撞的50%概率，需要生成的随机版本4 uuid的数量为2.71 quintillion，计算如下:

在这里输入图像描述

这个数字相当于在大约85年的时间里每秒生成10亿个UUID，而包含这么多UUID的文件(每个UUID 16个字节)大约是45艾字节，比目前存在的最大数据库(几百pb量级)大很多倍