在冒重复的风险之前，您可以随机生成 GUID 多少次？ （。网）
从数学上讲，我认为即使使用 .NET 框架中的内置方法生成的两个随机 GUID 也可能是相同的，但如果生成数百或数千，它们发生冲突的可能性大致有多大？
如果您为世界上每一个 Windows 副本都生成一个，它们会发生冲突吗？
我问的原因是因为我有一个程序创建了很多对象，也销毁了一些对象，并且我想知道这些对象（包括被销毁的对象）中的任何一个具有相同的 GUID 的可能性。
Mathematically I suppose it's possible that even two random GUIDs generated using the built in method in the .NET framework are identical, but roughly how likely are they to clash if you generate hundreds or thousands?
If you generated one for every copy of Windows in the world, would they clash?
The reason I ask is because I have a program that creates a lot of objects, and destroys some too, and I am wondering about the likelihood of any of those objects (including the destroyed ones) having identical GUIDs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
有大约 3E38 个可能的 GUID 值。但生日悖论将产生重复 GUID 的可能性降低到 1E19 左右。虽然仍然是一个巨大的数字，但与您的计算机首先被流星撞击摧毁的可能性相比，系统时钟用于确保不会发生重复。
许多大型和任务关键型数据库应用程序使用 GUID 作为表中的主键。不要犹豫，跟随他们的脚步。
There are ~3E38 possible GUID values. But the Birthday Paradox cuts the 50/50 odds to producing a duplicate GUID to ~1E19. While still an enormous number, comparing quite favorably to the odds that your machine will be destroyed by a meteor impact first, the system clock is used to ensure no duplicates can occur.
Many large and mission critical dbase apps use a GUID as the primary key in a table. Don't hesitate to follow their lead.
GUID 具有基于
时间（系统时钟）
空间（系统 MAC 地址）
随机数
的组件>
因此，如果同时为世界上的每台机器生成一个随机数，它们的 MAC 和随机数将有所不同
。这里有一个有用的链接。 http://blogs.msdn.com/oldnewthing/archive/ 2008/06/27/8659071.aspx
A GUID has components based on
Time (System clock)
Space (System MAC address)
Random numbers
So if one is generated for each machine in the world at the sam etime, they will differ by their MAC and random numbers
Here's a helpful link. http://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx
如果不了解 GUID 生成器实现的内部细节，就很难计算机会。
您可以使用 组合 来获取数字，但这只会帮助您假设组合是同样可能。因此，如果没有任何实施方面的统计知识，就很难判断真正的机会。
与 Midhat 所暗示的相反（如果我理解正确的话），GUID 冲突是可能的。内置随机数生成器通常使用基于时间戳的种子来实现。 MAC 地址本质上并不是唯一的，因为它们在许多情况下都可以被覆盖（至少在我知道的某些情况下，它们是唯一的）。两个 GUID 生成器可能会获得相同的输入，从而产生相同的输出。
GUID 的长度为 128 位，因此“足够每个人使用”，但这并不能保证不会发生冲突。
It is hard to calculate the chances without knowing the inner-details of the GUID-generator's implementation.
You can use combinatorics to get the numbers, but that will only help you assuming that the combinations are equally-likely. Therefore, without any statistical knowledge of the implementation - it would be hard to tell the real chances.
As opposed to what Midhat implies (if i understood him correctly), GUID collisions are possible. Built-in Random Number Generators are usually implemented using a timestamp-based seed. MAC addresses are not unique by nature, as they can be overwritten in many situations (and they are, at least in some cases i know of). It is possible that two GUID-generators will gain the same input and thus yield the same output.
GUIDs are 128-bit long, so "there is enough for everyone to use", but that does not guarantee that collisions won't occur.
在过去的 25 年里，我一直在使用 RPC 和 COM（其中 GUID 和 UUID 至关重要）以及使用 GUID 作为唯一行标识符的分布式数据库，我从未遇到过冲突问题 - 无论它们是在单台计算机上生成还是在单台计算机上生成。不同的机器。 MSDN 对此的另一个有趣的看法是，作为 rowid，它们比作为对象的寿命要长得多：
http://weblogs.asp.net/wwright/archive/2007/11/04/the-gospel-of-the-guid-and-why-it-matters.aspx
Having spent the past 25 years working with RPC and COM (where GUIDs and UUIDs are critical) and working with distributed databases where GUIDs are used as unique row identifiers, I have never encountered a collision problem - whether they were generated on a single machines or different machines. Another interesting take on this from MSDN where as rowids they are much longer lived than as objects:
http://weblogs.asp.net/wwright/archive/2007/11/04/the-gospel-of-the-guid-and-why-it-matters.aspx
这根本不是你应该关心的事情。这只是工作中的可用性启发式。这是您了解并认识到的“风险”，因此您想要关心它。但还有许多其他风险的可能性要高出数百万倍，但我们仍然不用担心。我认为这本精彩的 Pro Git 书说得最好：
你必须产生数百万或数十亿美元才能实现这种可能性。
This isn't something you should be at all concerned with. It's just the availability heuristic at work. It's a "risk" that you know about and recognize, so you want to care about it. But there are many other risks millions of times more likely, that we still don't worry about. The wonderful Pro Git book says it best, I think:
You would have to be generating million or billions for it to even be a remote possibility.
这将需要很长的时间！
It would take a really long time!
只是为了添加 Midhat 的正确答案，这里引用了 Eric Lippert 的博客关于系统中没有安装网卡（因此没有 MAC 地址）的情况：
Just to add to Midhat's right answer, here is a quotation from Eric Lippert's Blog about the situation, where there is no network card installed in the system (therefore, no MAC address):