comme l'UUID de java est bon.randomUUID?

UUID uses java.security.SecureRandom , qui est supposé être "cryptographiquement fort". Bien que la mise en œuvre réelle ne soit pas précisée et puisse varier entre les JVM (ce qui signifie que toute déclaration concrète faite n'est valable que pour une seule JVM spécifique), il est stipulé que la sortie doit passer un test de générateur de nombres aléatoires statistiques.

il est toujours possible pour une implémentation de contenir des bogues subtils qui ruinent tout cela (voir OpenSSH key generation bug) mais je ne pense pas qu'il y ait de raison concrète de s'inquiéter du caractère aléatoire des UUIDs Java.

Wikipedia a une très bonne réponse http://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions

le nombre d'UUIDs aléatoires de la version 4 qui doivent être générés pour avoir une probabilité de 50% d'au moins une collision est de 2,71 quintillions, calculé comme suit:

...

ce nombre équivaut à générer 1 milliard D'UUID par seconde pour environ 85 ans, et un fichier contenant autant d'UUIDs, à 16 octets par UUID, serait d'environ 45 exaoctets, plusieurs fois plus grand que les plus grandes bases de données existantes, qui sont de l'ordre de centaines de petaoctets.

...

ainsi, pour qu'il y ait une chance sur un milliard de duplication, 103 trillions d'UUID version 4 doivent être générés.

Quelqu'un a-t-il une expérience à partager?

il y a 2^122 valeurs possibles pour un UUID de type 4. (La spécification dit que vous perdez 2 bits pour le type, et 4 bits supplémentaires pour un numéro de version.)

en supposant que vous deviez générer 1 million d'UUIDs aléatoires par seconde, les chances qu'un duplicata se produise dans votre vie seraient insignifiantes. (Et pour détecter le duplicata, vous devez résoudre le problème de comparer 1 million de nouveaux UUIDs par seconde contre tous les UUIDs que vous avez généré précédemment !)

les chances que n'importe qui a éprouvé (c.-à-d. réellement remarqué ) un double dans la vie réelle sont encore plus petites que vanishingly petit ... en raison de la difficulté pratique de rechercher des collisions.

maintenant, bien sûr, vous utiliserez généralement un générateur de nombres pseudo-aléatoires, pas un source de nombres vraiment aléatoires. Mais je pense que nous pouvons être sûrs que si vous utilisez un fournisseur crédible pour votre force cryptographique nombres aléatoires, alors il sera force cryptographique, et la probabilité de répétitions sera le même que pour un idéal (non biaisé) générateur de nombres aléatoires.

cependant, si vous deviez utiliser une JVM avec un générateur de nombres crypto - aléatoires "cassé", tous les paris sont éteints. (Et qui pourrait inclure certains des solutions de rechange pour les problèmes de" pénurie d'entropie " sur certains systèmes. Ou la possibilité que quelqu'un a bricolé avec votre JRE, soit sur votre système ou en amont.)

Je ne suis pas un expert, mais je suppose que suffisamment de gens intelligents ont regardé le générateur de nombres aléatoires de Java au fil des ans. Par conséquent, je suppose aussi que les UUIDs aléatoires sont bons. Donc vous devriez vraiment avoir la probabilité théorique de collision (qui est d'environ 1 : 3 × 10^38 for all possible UUIDs. Quelqu'un sait comment cela change random Uuid? Est-ce 1/(16*4) de ce qui précède?)

de mon expérience pratique, je n'ai jamais vu les collisions jusqu'à présent. Je me serai probablement laissé pousser une barbe étonnamment longue le jour où j'aurai eu ma première barbe;)

le schéma de génération original pour UUIDs était de concaténer la version UUID avec L'adresse MAC de l'ordinateur qui produit L'UUID, et avec le nombre d'intervalles de 100 nanosecondes depuis l'adoption du calendrier Grégorien en Occident. En représentant un seul point dans l'espace (l'ordinateur) et le temps (le nombre d'intervalles), les chances de collision sont des valeurs est effectivement nulle.

chez un ancien employeur, nous avions une colonne unique qui contenait un uuid aléatoire. On a eu une collision la première semaine après son déploiement. Bien sûr, les chances sont faibles, mais elles ne sont pas nulles. C'est pourquoi Log4j 2 contient UuidUtil.getTimeBasedUuid. Il générera un UUID unique pour 8925 ans, à condition que vous ne génériez pas plus de 10 000 UUIDs/millisecondes sur un seul serveur.

plusieurs des réponses traitent du nombre d'UUID qu'il faudrait générer pour atteindre un risque de collision de 50%. Mais un risque de collision de 50%, 25%, ou même 1% est sans valeur pour une application où la collision doit être (pratiquement) impossible.

des programmateurs systématiquement rejeter comme "impossible" d'autres événements qui peuvent se produire et se produisent?

lorsque nous écrivons des données sur un disque ou une mémoire et que nous les relisons, nous tenons pour acquis que les données sont correctes. Nous comptons sur la correction d'erreur de l'appareil pour détecter toute corruption. Mais le risque d'erreurs non détectées est en fait autour de 2 ^-50 .

ne serait-il pas logique d'appliquer une norme similaire aux UUID aléatoires? Si vous le faites, vous constaterez qu'une collision "impossible" est possible dans une collection d'environ 100 milliards d'UUID aléatoires.(2 ^36.5 ).

C'est un nombre astronomique, mais des applications comme détaillé la facturation dans un système de santé national ou l'enregistrement de données de capteurs à haute fréquence sur un large éventail d'appareils pourrait certainement se heurter à ces limites. Si vous écrivez le prochain Guide de L'auto-stoppeur vers la galaxie, n'essayez pas d'attribuer UUIDs à chaque article!

j'ai joué à la loterie l'année dernière, et je n'ai jamais gagné .... mais il semble qu'il y a des gagnants à la loterie ...

doc: http://tools.ietf.org/html/rfc4122

Type 1: non mis en œuvre. collision sont possibles si l'uuid est généré au même moment. impl peut être synchronisé artificiellement afin de contourner ce problème.

Type 2: Ne jamais voir une implémentation.

Type 3: hachage md5: collision possible (128 bits-2 octets techniques)

Type 4 : aléatoire : collision possible (la loterie). notez que le JDK6 impl n'utilise pas un" vrai "aléatoire sécurisé parce que l'algorithme de PRNG n'est pas choisi par le développeur et vous pouvez forcer le système à utiliser un" pauvre " algo de PRNG. Donc ton UUID est prévisible.

de Type 5 : sha1 hash : pas de mise en œuvre : collision possible (160 bits 2 octets)

Je ne suis pas un expert mais puisque tout le monde a parlé de théorie je pense que je peux ajouter quelque chose à la discussion en donnant un exemple pratique. Dans ma base de données, j'ai environ 4,5 millions D'UUID générés en utilisant Java 8 UUID.randomUUID (). Les suivantes ne sont que quelques-unes que j'ai découvert:

"c0f55f62-b990-47bc-8caa-f42313669948 "

"c0f55f62-e81e-4253-8299-00b4322829d5 "

"c0f55f62-4979-4e87-8cd9-1c556894e2bb "

"b9ea2498-fb32-40ef-91ef-0ba00060fe64 "

"be87a209-2114-45b3-9d5a-86d00060fe64 "

"4a8a74a6-e972-4069-b480-bdea1177b21f "

"12fb4958-bee2-4c89-8cf8-edea1177b21f "

s'il était vraiment aléatoire, la probabilité d'avoir ce genre d'UUIDs similaires serait considérablement faible, puisque nous ne considérons que 4,5 millions d'entrées. Si, bien que cette fonction soit bonne, en termes de ne pas avoir de collisions, pour moi il ne semble pas que bon comme il serait en théorie.

nous utilisons l'UUID aléatoire de Java dans notre application depuis plus d'un an et cela de manière très extensive. Mais nous n'avons jamais rencontré de collision.