GUID是否在100％的時間內是惟一的？

GUID是否在100％的時間內是惟一的？

它會在多個線程上保持惟一性嗎？

---

#1樓

埃裏克·利珀特（Eric Lippert）寫了一系列很是有趣的有關GUID的文章。

全世界大約有2 ^30臺我的計算機（固然，許多手持設備或非PC計算設備具備或多或少相同的計算能力，但請忽略它們）。 假設咱們將世界上全部這些PC都用於生成GUID。 若是每一個人每秒能夠生成2 ^20個 GUID，那麼在大約2 ⁷²秒（ 一百五十萬億年）以後 ，您極有可能與您的特定GUID發生碰撞。 僅三十萬億年後，碰撞的概率就至關可觀。

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

---

#2樓

我遇到了重複的GUID。

我使用的是Neat Receipts臺式掃描儀，它帶有專有的數據庫軟件。 該軟件具備「同步到雲」功能，而且在同步時一直出現錯誤。 日誌上的禿鷹露出了那條使人敬畏的臺詞：

「錯誤」：[{「代碼」：1，「消息」：「 creator_guid：已被使用」，「 guid」：「 C83E5734-D77A-4B09-B8C1-9623CAC7B167」}]}}

我有點難以置信，可是能夠確定的是，當我找到了進入本地neatworks數據庫的方法並刪除了包含該GUID的記錄時，錯誤中止發生。

所以，以傳聞證據回答您的問題，不是。 能夠重複。 可是，發生這種狀況的緣由極可能不是偶然的，而是因爲沒有遵循某種標準慣例。 （我不是那麼幸運）可是，我不能確定地說。 這不是個人軟件。

他們的客戶支持很是禮貌和樂於助人，可是他們必定歷來沒有遇到過這個問題，由於與他們通電話3個多小時後，他們找不到解決方案。 （FWIW，Neat給我留下了很深入的印象，儘管如此使人沮喪，但這種故障並無改變我對他們產品的見解。）

---

#3樓

GUID算法一般是根據v4 GUID規範實現的，該規範本質上是僞隨機字符串。 可悲的是，它們屬於Wikipedia的「可能非惟一」類別（我不知道爲何這麼多人忽略了這一點）：「 ...其餘GUID版本具備不一樣的惟一性屬性和機率，從保證的惟一性到不等可能的非惟一性。」

V8的JavaScript Math.random()的僞隨機屬性在惟一性方面很糟糕，衝突一般僅在數千次迭代以後發生，但V8並非惟一的罪魁禍首。 我已經看到使用v4 GUID的PHP和Ruby實現的真實世界GUID衝突。

因爲在多個客戶端和服務器羣集之間擴展ID生成變得愈來愈廣泛，所以，熵受到很大的打擊-使用同一隨機種子生成ID升級的機會（時間一般用做隨機種子）在僞隨機數生成器中），GUID衝突從「可能不惟一」升級爲「極可能形成不少麻煩」。

爲了解決這個問題，我着手建立一個ID算法，該算法能夠安全擴展，並更好地防止衝突。 它經過使用時間戳，內存中的客戶端計數器，客戶端指紋和隨機字符來實現。 因素的組合會產生額外的複雜性，即便您在多個主機上進行擴展，也特別能抵禦衝突：

http://usecuid.org/

---

#4樓

附帶說明一下，我正在使用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中搜索第4部分時，我發現批量GUID的點擊量約爲125.000。

結論：關於卷GUID，它們不像其餘GUID那樣獨特。

---

#5樓

它不該該發生。 可是，當.NET負擔很重時，就有可能得到重複的引導。 我有兩個使用兩個不一樣sql服務器的不一樣Web服務器。 我去合併數據，發現我有1500萬盾和7個副本。