我经历了一个重复的GUID。

我使用的是Neat收据桌面扫描仪，它自带专有数据库软件。该软件有一个同步到云的功能，我总是在同步时得到一个错误。浏览一下日志，你会发现这句话非常棒:

"errors":[{"code":1，"message":"creator_guid: is already . 了”、“guid”:“c83e5734 d77a - 4 - b09 b8c1 - 9623 cac7b167”}]}

我有点难以置信，但可以肯定的是，当我找到进入本地网络数据库的方法并删除包含该GUID的记录时，错误就停止了。

所以用轶事证据来回答你的问题，没有。副本是可能的。但它发生的原因很可能不是由于偶然，而是由于标准的做法在某种程度上没有得到遵守。(我只是没有那么幸运)然而，我不能肯定。这不是我的软件。

他们的客户支持非常有礼貌和乐于助人，但他们以前肯定从未遇到过这个问题，因为在与他们电话交谈3个多小时后，他们没有找到解决方案。(总之，Neat给我留下了深刻的印象，这个小故障虽然令人沮丧，但并没有改变我对他们产品的看法。)

“GUID是100%唯一的吗?”的答案是“不是”。

如果你想要GUID的100%唯一性，然后做下面的事情。 生成GUID 检查GUID是否存在于您正在寻找唯一性的表列中 如果存在，则转步骤1，否则转步骤4 使用这个GUID作为唯一的。

MSDN:

新Guid的值全为零或等于任何其他Guid的概率非常低。

简单的答案是肯定的。

Raymond Chen写了一篇关于guid和为什么guid的子字符串不能保证唯一的文章。这篇文章深入探讨了guid的生成方式以及它们用来确保唯一性的数据，这应该会花一些篇幅来解释它们为什么会这样:-)

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

恶意破坏预警

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

似乎没有人提到它发生概率的实际数学计算。

首先，让我们假设我们可以使用整个128位空间(Guid v4只使用122位)。

我们知道在n次选择中没有得到重复的一般概率是:

(1-1/2128)(1-2/2128)……(1 - (n - 1) / 2128)

因为2128比n大得多，我们可以将其近似为:

(1-1/2128) n (n - 1) / 2

因为我们可以假设n比0大很多很多，我们可以把它近似为:

(1-1/2128) n ^ 2/2

现在我们可以将其等同于“可接受的”概率，假设是1%:

(1-1/2128)n²/2 = 0.01

我们解出n，得到

N =√(2* log 0.01 / log (1-1/2128))

哪个Wolfram Alpha得到5.598318 × 1019

为了更好地理解这个数字，让我们以10000台机器为例，每台机器都有一个4核CPU，工作4Ghz，花费10000个周期来生成一个Guid，其他什么都不做。然后需要大约111年才能产生一个副本。