顺便说一句，我在Windows XP中使用了Volume guid。这是一个非常模糊的分区布局，有3个磁盘和14个卷。

\\?\Volume{23005604-eb1b-11de-85ba-806d6172696f}\ (F:)
\\?\Volume{23005605-eb1b-11de-85ba-806d6172696f}\ (G:)
\\?\Volume{23005606-eb1b-11de-85ba-806d6172696f}\ (H:)
\\?\Volume{23005607-eb1b-11de-85ba-806d6172696f}\ (J:)
\\?\Volume{23005608-eb1b-11de-85ba-806d6172696f}\ (D:)
\\?\Volume{23005609-eb1b-11de-85ba-806d6172696f}\ (P:)
\\?\Volume{2300560b-eb1b-11de-85ba-806d6172696f}\ (K:)
\\?\Volume{2300560c-eb1b-11de-85ba-806d6172696f}\ (L:)
\\?\Volume{2300560d-eb1b-11de-85ba-806d6172696f}\ (M:)
\\?\Volume{2300560e-eb1b-11de-85ba-806d6172696f}\ (N:)
\\?\Volume{2300560f-eb1b-11de-85ba-806d6172696f}\ (O:)
\\?\Volume{23005610-eb1b-11de-85ba-806d6172696f}\ (E:)
\\?\Volume{23005611-eb1b-11de-85ba-806d6172696f}\ (R:)
                                     | | | | |
                                     | | | | +-- 6f = o
                                     | | | +---- 69 = i
                                     | | +------ 72 = r
                                     | +-------- 61 = a
                                     +---------- 6d = m

这并不是说guid非常相似，而是所有的guid都有字符串“mario”。这是巧合还是另有原因?

现在，当在GUID中搜索第4部分时，我发现大约有125,000个与音量GUID相关的点击。

结论:当涉及到Volume guid时，它们并不像其他guid那样独特。

这种情况不应该发生。然而，当. net负载过重时，可能会得到重复的guid。我有两个不同的web服务器使用两个不同的sql服务器。我去合并数据，发现我有1500万个guids和7个副本。

而每个生成的GUID不是 保证是唯一的，总数 唯一键数(2128或 3.4×1038)是如此之大，相同的数字的概率是 生成两次是非常小的。为 例如，考虑可观察对象 宇宙，其中包含约5×1022 星星;每颗恒星都有可能 6.8×1015通用唯一的guid。

从维基百科。

这是一些关于如何创建GUID(用于。net)以及如何在正确的情况下获得相同的GUID的好文章。

https://ericlippert.com/2012/04/24/guid-guide-part-one/

https://ericlippert.com/2012/04/30/guid-guide-part-two/

https://ericlippert.com/2012/05/07/guid-guide-part-three/

​​

Eric Lippert写了一系列关于guid的非常有趣的文章。

There are on the order 230 personal computers in the world (and of course lots of hand-held devices or non-PC computing devices that have more or less the same levels of computing power, but lets ignore those). Let's assume that we put all those PCs in the world to the task of generating GUIDs; if each one can generate, say, 220 GUIDs per second then after only about 272 seconds -- one hundred and fifty trillion years -- you'll have a very high chance of generating a collision with your specific GUID. And the odds of collision get pretty good after only thirty trillion years.

GUID指南，第一部分 GUID指南，第二部分 GUID指南，第三部分

在多线程/多进程单元测试期间，我经历过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地址/时间戳不再被合并的原因。