我想证明一个GUID在一个简单的测试程序中不是唯一的。 我原以为下面的代码会运行几个小时，但它不起作用。我该怎么做呢?
BigInteger begin = new BigInteger((long)0);
BigInteger end = new BigInteger("340282366920938463463374607431768211456",10); //2^128
for(begin; begin<end; begin++)
Console.WriteLine(System.Guid.NewGuid().ToString());
我用的是c#。
当前回答
由于部分Guid生成是基于当前机器的时间，我的理论是获得一个副本Guid:
重新安装Windows 创建一个启动脚本，在Windows启动时将时间重置为2010-01-01 12:00:00。 就在启动脚本之后，它触发应用程序生成一个Guid。 克隆此Windows安装，以便排除后续启动过程中可能出现的任何细微差异。 用此映像重新映像硬盘驱动器，并启动几次机器。
其他回答
证明GUID不是唯一的唯一解决方案是建立一个World GUID池。每次在某个地方生成GUID时，都应该将其注册到组织。或者，我们可能包括一个标准化，所有GUID生成器都需要自动注册它，为此它需要一个活跃的互联网连接!
guid是124位，因为4位保存版本号。
在GUID生成代码中出现错误的几率比算法生成冲突的几率要高得多。在测试guid的代码中出现错误的可能性更大。放弃。
如果生成的UUID的数量遵循摩尔定律，那么在可预见的未来永远用不完GUID的印象是错误的。
对于2^128个uuid，只需要18个月* Log2(2^128) ~= 192年，我们就会用完所有uuid。
而且我相信(虽然没有任何统计证据)，自从UUID被大规模采用以来，在过去的几年里，我们生成UUID的速度比摩尔定律所规定的要快得多。换句话说，我们可能只有不到192年的时间来处理UUID危机，这比宇宙末日要快得多。
但由于我们肯定不会在2012年底之前将它们耗尽，我们将把这个问题留给其他物种来担心。
这个程序虽然有错误，但证明了GUID不是唯一的。那些试图证明相反情况的人没有抓住重点。这句话只是证明了一些GUID变体的弱实现。
GUID在定义上不一定是唯一的，它在定义上是高度唯一的。你刚才精炼了高度的意思。根据版本、实现者(MS或其他)、虚拟机的使用等不同，您的定义会发生很大变化。(见前文链接)
你可以缩短你的128位表来证明你的观点。最好的解决方案是使用哈希公式来缩短重复的表，然后在哈希发生冲突时使用完整的值，并基于此重新生成一个GUID。如果从不同的位置运行，则将哈希/完整密钥对存储在一个中心位置。
Ps:如果目标只是生成x个不同的值，那么创建一个这个宽度的哈希表，并检查哈希值。
