GUID 100%是唯一的吗?

它会在多个线程中保持唯一吗?


当前回答

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

恶意破坏预警

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

其他回答

是的,GUID应该总是唯一的。它是基于硬件和时间,加上一些额外的位,以确保它是唯一的。我相信理论上有可能得到两个一模一样的,但在现实场景中极不可能。

以下是Raymond Chen关于Guids的一篇很棒的文章:

https://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx ​ ​ ​

GUID 100%是唯一的吗?

不能保证,因为有几种方法可以生成一个。然而,您可以尝试计算创建两个完全相同的GUID的几率,您就会明白:一个GUID有128位,因此,有2128个不同的GUID——比已知宇宙中的恒星要多得多。阅读维基百科的文章了解更多细节。

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

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

GUID算法通常根据v4 GUID规范实现,它本质上是一个伪随机字符串。可悲的是,这些都属于“可能非唯一”的类别,来自维基百科(我不知道为什么这么多人忽略了这一点):“……其他GUID版本有不同的唯一性属性和概率,从保证唯一性到可能的非唯一性。”

V8的JavaScript Math.random()的伪随机属性在唯一性方面很糟糕,通常在几千次迭代之后就会发生冲突,但V8并不是唯一的罪魁祸首。我曾经使用PHP和Ruby实现的v4 GUID在现实世界中遇到过GUID冲突。

因为在多个客户端和服务器集群上扩展ID生成变得越来越普遍,熵会受到很大的冲击——使用相同的随机种子生成ID的几率会增加(在伪随机生成器中,时间经常被用作随机种子),GUID冲突也会从“可能不是唯一的”升级为“很可能造成很多麻烦”。

为了解决这个问题,我开始创建一个可以安全扩展的ID算法,并更好地保证不发生碰撞。它通过使用时间戳、内存中的客户端计数器、客户端指纹和随机字符来实现这一点。这些因素的组合产生了一种附加的复杂性,它特别抗碰撞,即使你将它扩展到多个主机:

http://usecuid.org/

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

首先,让我们假设我们可以使用整个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年才能产生一个副本。