GUID 100%是唯一的吗?
它会在多个线程中保持唯一吗?
GUID 100%是唯一的吗?
它会在多个线程中保持唯一吗?
当前回答
GUID代表全局唯一标识符
简而言之: (线索就在名字里)
详细: guid被设计为唯一的;它们是使用基于计算机时钟和计算机本身的随机方法计算的,如果你在同一毫秒内在同一台机器上创建多个guid,它们可能是匹配的,但对于几乎所有的正常操作,它们应该被认为是唯一的。
其他回答
如果你的系统时钟设置正确,没有被环绕,如果你的网卡有自己的MAC(即你没有设置自定义MAC),你的网卡供应商没有回收MAC(他们不应该这样做,但已经知道发生了),如果你的系统的GUID生成功能正确实现,那么你的系统将永远不会生成重复的GUID。
如果地球上每个生成guid的人都遵循这些规则,那么您的guid将是全局唯一的。
在实践中,违反规则的人数很少,他们的guid不太可能“逃脱”。冲突在统计上是不可能发生的。
GUID算法通常根据v4 GUID规范实现,它本质上是一个伪随机字符串。可悲的是,这些都属于“可能非唯一”的类别,来自维基百科(我不知道为什么这么多人忽略了这一点):“……其他GUID版本有不同的唯一性属性和概率,从保证唯一性到可能的非唯一性。”
V8的JavaScript Math.random()的伪随机属性在唯一性方面很糟糕,通常在几千次迭代之后就会发生冲突,但V8并不是唯一的罪魁祸首。我曾经使用PHP和Ruby实现的v4 GUID在现实世界中遇到过GUID冲突。
因为在多个客户端和服务器集群上扩展ID生成变得越来越普遍,熵会受到很大的冲击——使用相同的随机种子生成ID的几率会增加(在伪随机生成器中,时间经常被用作随机种子),GUID冲突也会从“可能不是唯一的”升级为“很可能造成很多麻烦”。
为了解决这个问题,我开始创建一个可以安全扩展的ID算法,并更好地保证不发生碰撞。它通过使用时间戳、内存中的客户端计数器、客户端指纹和随机字符来实现这一点。这些因素的组合产生了一种附加的复杂性,它特别抗碰撞,即使你将它扩展到多个主机:
http://usecuid.org/
如果你害怕相同的GUID值,那么把它们放在一起。
Guid.NewGuid().ToString() + Guid.NewGuid().ToString();
如果你太多疑,那就放三个。
“GUID是100%唯一的吗?”的答案是“不是”。
如果你想要GUID的100%唯一性,然后做下面的事情。 生成GUID 检查GUID是否存在于您正在寻找唯一性的表列中 如果存在,则转步骤1,否则转步骤4 使用这个GUID作为唯一的。
在多线程/多进程单元测试期间,我经历过guid不是唯一的(也是?)我想这与所有其他条件相同的情况下,伪随机生成器的相同播种(或缺乏播种)有关。我用它来生成唯一的文件名。我发现操作系统在这方面做得更好:)
恶意破坏预警
你问guid是否100%唯一。这取决于它在guid中必须是唯一的。当guid的数量接近无穷大时,重复guid的概率接近100%。