GUID是100％独一无二的吗？
它会在多个线程中保持独特吗？
虽然不保证每个生成的GUID都是唯一的，但是唯一密钥的总数（2128或3.4×1038）是如此之大，以至于两次生成相同数字的概率非常小。例如，考虑可观察的宇宙，其中包含大约5×1022个恒星;然后每个星星都有6.8×1015个通用唯一的GUID。
来自Wikipedia。
这些是关于如何制作GUID（对于.NET）以及如何在正确的情况下获得相同guid的一些好文章。
https://ericlippert.com/2012/04/24/guid-guide-part-one/
似乎没有人提到它发生概率的实际数学。
首先，假设我们可以使用整个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/2 = 0.01
我们为n解决并得到：
n = sqrt（2 * log 0.01 / log（1-1 / 2128））
哪个Wolfram Alpha变为5.598318×1019
为了对这个数字进行透视，我们可以使用10000台机器，每台机器都有4核CPU，执行4Ghz并花费10000个周期来生成Guid而不执行任何其他操作。然后它们需要大约111年才会产生重复。
来自http://www.guidgenerator.com/online-guid-generator.aspx
什么是GUID？
GUID（或UUID）是“全球唯一标识符”（或“通用唯一标识符”）的首字母缩写。它是一个128位整数，用于标识资源。术语GUID通常由使用Microsoft技术的开发人员使用，而UUID在其他任何地方使用。
GUID的独特之处是什么？
128位足够大，生成算法足够独特，如果1年内每秒产生1,000,000,000个GUID，则重复的概率仅为50％。或者，如果地球上的每个人都产生了600,000,000个GUID，那么重复的概率只有50％。
MSDN：
新Guid的值全部为零或等于任何其他Guid的可能性非常低。
如果您的系统时钟设置正确且没有缠绕，并且您的NIC有自己的MAC（即您没有设置自定义MAC）并且您的NIC供应商尚未回收MAC（他们不应该这样做）但已知会发生这种情况），如果系统的GUID生成功能正确实现，那么您的系统将永远不会生成重复的GUID。
如果地球上每个生成GUID的人都遵循这些规则，那么您的GUID将是全局唯一的。
在实践中，违反规则的人数很少，他们的GUID不太可能“逃脱”。冲突在统计上是不可能的。
我遇到了重复的GUID。
我使用Neat Receipts桌面扫描仪，它附带专有的数据库软件。该软件具有同步到云功能，并且在同步时我一直收到错误。日志上的雄鹅们发现了令人敬畏的线条：
“errors”：[{“code”：1，“message”：“creator_guid：已被占用”，“guid”：“C83E5734-D77A-4B09-B8C1-9623CAC7B167”}]}
我有点难以置信，但当然，当我找到进入我的本地neatworks数据库的方法并删除包含该GUID的记录时，错误就停止了。
所以用轶事证据回答你的问题，不。可以复制。但它可能发生的原因可能不是偶然，而是由于标准做法没有以某种方式加以遵守。 （我不是那么幸运）但是，我不能肯定地说。这不是我的软件。
他们的客户支持极其礼貌和乐于助人，但他们之前从未遇到过这个问题，因为在与他们通电3个多小时之后，他们没有找到解决方案。 （FWIW，我对Neat印象非常深刻，这个小故障，无论多么令人沮丧，都没有改变我对他们产品的看法。）
GUID是100％独一无二的吗？
不保证，因为有几种方法可以生成一个。但是，您可以尝试计算创建两个相同的GUID的机会，并且您会明白：GUID有128位，因此，有2128个不同的GUID - 远远超过已知Universe中的星星。阅读wikipedia article了解更多详情。
GUID算法通常根据v4 GUID规范实现，该规范本质上是伪随机字符串。可悲的是，这些属于“可能非独特”的类别，来自维基百科（我不知道为什么这么多人忽略了这一点）：“......其他GUID版本具有不同的唯一性属性和概率，范围从保证唯一性可能是非唯一性。“
V8的JavaScript Math.random()的伪随机属性在唯一性上是可怕的，碰撞通常仅在几千次迭代后发生，但V8并不是唯一的罪魁祸首。我已经看到使用v4 GUID的PHP和Ruby实现的真实世界GUID冲突。
因为在多个客户端和服务器集群中扩展ID生成变得越来越普遍，熵受到很大影响 - 使用相同随机种子生成ID升级的可能性（时间通常用作随机种子）在伪随机生成器中），GUID冲突从“可能非唯一”升级到“非常可能导致很多麻烦”。
为了解决这个问题，我开始创建一个可以安全扩展的ID算法，并更好地保证防止冲突。它通过使用时间戳，内存客户端计数器，客户端指纹和随机字符来实现。这些因素的组合产生了一种附加的复杂性，即使您在多个主机上进行扩展，它也能抵抗冲突：
我经历过GUID在多线程/多进程单元测试期间不是唯一的（也是？）。我想这与所有其他的相同，伪随机发生器的相同种子（或缺乏播种）有关。我用它来生成唯一的文件名。我发现操作系统做得更好:)
您询问GUID是否100％唯一。这取决于它必须是唯一的GUID数量。随着GUID的数量接近无穷大，重复GUID的概率接近100％。
在更一般的意义上，这被称为“生日问题”或“生日悖论”。维基百科有一个非常好的概述：Wikipedia - Birthday Problem
在非常粗略的术语中，池的大小的平方根是一个粗略的近似值，当你可以预期有50％的重复几率。该文章包括池大小和各种概率的概率表，包括2 ^ 128的行。因此，对于1％的碰撞概率，您可能会随机选择2.6 * 10 ^ 18个128位数字。 50％的几率需要2.2 * 10 ^ 19个选择，而SQRT（2 ^ 128）为1.8 * 10 ^ 19。
当然，这只是一个真正随机过程的理想情况。正如其他人所提到的那样，很多都是在随机的方面 - 发电机和种子有多好？如果有一些硬件支持可以帮助这个过程，那将是更好的，除了任何可以欺骗或虚拟化之外，这将是更加防弹。我怀疑这可能是为什么不再包含MAC地址/时间戳的原因。
“GUID是100％唯一的答案吗？”简直就是“不”。
简单的答案是肯定的。
Raymond Chen在GUID上写了一个great article，为什么不保证GUID的子串是唯一的。本文深入探讨了GUID的生成方式以及它们用于确保唯一性的数据，这应该在解释它们为什么的时候会有一定的篇幅:-)
最难的部分不是生成重复的Guid。
最难的部分是设计一个数据库来存储所有生成的数据库，以检查它是否实际上是重复的。
来自WIKI：
例如，为了具有至少一次碰撞的50％概率而需要生成的随机版本4 UUID的数量是2.71 quintillion，计算如下：
这个数字相当于大约85年每秒产生10亿UUID，包含这么多UUID的文件，每个UUID 16字节，大约45艾字节，比目前存在的最大数据库大很多倍，它们都在数百PB的数量级
GUID代表全球唯一标识符
简介:(线索在名称中）
详细信息：GUID设计为独特的;它们是使用基于计算机时钟和计算机本身的随机方法计算的，如果您在同一台机器上以相同的毫秒创建许多GUID，它们可能匹配，但对于几乎所有正常操作，它们应被视为唯一的。
如果你害怕相同的GUID值，那么将它们中的两个放在一起。
Guid.NewGuid().ToString() + Guid.NewGuid().ToString();
如果你太偏执，那就放三个。
作为旁注，我正在玩Windows XP中的Volume GUID。这是一个非常模糊的分区布局，有三个磁盘和十四个卷。
\\?\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中的googling for part 4发现大约125.000次点击量GUID。
结论：当涉及到卷GUID时，它们不像其他GUID那样独特。
是的，GUID应始终是唯一的。它基于硬件和时间，加上一些额外的位，以确保它是独一无二的。我确信理论上可能最终得到两个相同的，但在现实场景中极不可能。
这是Raymond Chen关于Guids的精彩文章：
https://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx
它不应该发生。但是，当.NET负载很重时，可能会获得重复的guid。我有两个不同的Web服务器使用两个不同的SQL服务器。我去合并数据，发现我有1500万guid和7副本。
Guids在统计上是独一无二的。生成相同Guid的两个不同客户端的几率是无限小的（假设Guid生成代码中没有错误）。您可能还担心由于宇宙射线造成的处理器故障，并且今天决定2 + 2 = 5。
分配新guid的多个线程将获得唯一值，但是你应该得到你正在调用的函数是线程安全的。这是哪个环境？
Eric Lippert撰写了一系列关于GUID的非常有趣的文章。
世界上有230台个人计算机（当然还有许多手持设备或非PC计算设备，它们具有或多或少相同的计算能力，但让我们忽略它们）。让我们假设我们将世界上所有这些PC都用于生成GUID的任务;如果每个人每秒可以产生220个GUID，那么仅仅大约272秒 - 一百五十万亿年 - 你将很有可能与你的特定GUID产生碰撞。仅仅三十万亿年后碰撞的几率就相当不错了。
从理论上讲，不，它们并不是唯一的。可以一遍又一遍地生成相同的guid。然而，它发生的可能性非常低，你可以认为它们是独一无二的。
我之前已经读过，机会很低，你真的应该强调别的东西 - 比如你的服务器自发地燃烧或你的代码中的其他错误。也就是说，假设它是唯一的，并且不构建任何代码来“捕获”重复项 - 将时间花在更可能发生的事情上（即其他任何事情）。
我made an attempt描述了GUID对我的博客受众（非技术家庭成员）的有用性。从那里（通过维基百科），生成重复GUID的几率：