一 简介
作为开发人员大家对UUID应该都比较熟悉了，Java中也提供了相关的类和生成方法，供业务中使用。这里准备对UUID生成的过程做一次深入了解。
二 什么是UUID
2.1 概念
根据百度百科的描述：
UUID 是 通用唯一识别码（Universally Unique Identifier）的缩写，是一种软件建构的标准，亦为开放软件基金会组织在分布式计算环境领域的一部分。其目的，是让分布式系统中的所有元素，都能有唯一的辨识信息，而不需要通过中央控制端来做辨识信息的指定。如此一来，每个人都可以创建不与其它人冲突的UUID。
2.2 UUID实例
现实中，最广泛应用的UUID，是微软的全局唯一标识符（GUID），而其他重要的应用，则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等。
恰好手边有一台mac电脑，我们可以在：点击电脑左上角苹果图标-->关于本机-->系统报告-->硬件-->硬件uuid 查看到硬件uuid。
2.3 UUID组成
UUID由下面的几部分组成：
（1）UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同。
（2）时钟序列。
（3）全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
生成的结果串会比较长是UUID的缺陷。关于UUID这个标准，使用最普遍的是微软的GUID(Globals Unique Identifiers)。在ColdFusion中可以用CreateUUID()函数很简单地生成UUID，其格式为：xxxxxxxx-xxxx- xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)，其中每个 x 是 0-9 或 a-f 范围内的一个十六进制的数字。而标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，可以从cflib 下载CreateGUID() UDF进行转换。
三 Java中的UUID类
3.1 java.util.UUID
java.util包中提供了一个UUID类，其中包含了生成UUID的方法，供开发者调用。文档中对此也做了一些注释，从中我们也可以了解到更详细的关于UUID的信息（以下为注释中的部分关键信息截取）：
A UUID represents a 128-bit value * <p> There exist different variants of these global identifiers. The methods * of this class are for manipulating the Leach-Salz variant, although the * constructors allow the creation of any variant of UUID (described below). * * <p> The layout of a variant 2 (Leach-Salz) UUID is as follows: * * The most significant long consists of the following unsigned fields: * <pre> * 0xFFFFFFFF00000000 time_low * 0x00000000FFFF0000 time_mid * 0x000000000000F000 version * 0x0000000000000FFF time_hi * </pre> * The least significant long consists of the following unsigned fields: * <pre> * 0xC000000000000000 variant * 0x3FFF000000000000 clock_seq * 0x0000FFFFFFFFFFFF node * </pre>
从中我们可以看到：
1、UUID 表示一个 128 位的值；
2、这些通用标识符具有不同的变体。此类的方法用于操作 Leach-Salz 变体，不过构造方法允许创建任何 UUID 变体（将在下面进行描述）；
3、变体 2 (Leach-Salz) UUID 的布局如下： long 型数据的最高有效位由以下无符号字段组成：
0xFFFFFFFF00000000 time_low 0x00000000FFFF0000 time_mid 0x000000000000F000 version 0x0000000000000FFF time_hi
long 型数据的最低有效位由以下无符号字段组成：
0xC000000000000000 variant 0x3FFF000000000000 clock_seq 0x0000FFFFFFFFFFFF node
variant 字段包含一个表示 UUID 布局的值。以上描述的位布局仅在 UUID 的 variant 值为 2（表示 Leach-Salz 变体）时才有效。
version 字段保存描述此 UUID 类型的值。有 4 种不同的基本 UUID 类型：基于时间的 UUID、DCE 安全 UUID、基于名称的 UUID 和随机生成的 UUID。 这些类型的 version 值分别为 1、2、3 和 4。
关于UUID的文档可以参考：类 UUID。
3.2 UUID的版本及相关代码
version 1：基于时间的UUID
public long timestamp() { if (version() != 1) { throw new UnsupportedOperationException("Not a time-based UUID"); } return (mostSigBits & 0x0FFFL) << 48 | ((mostSigBits >> 16) & 0x0FFFFL) << 32 | mostSigBits >>> 32; }
version 2：DCE安全的UUID
相关文档：https://www.ietf.org/rfc/rfc4122.txt
DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。
version 3：基于名字的UUID
public static UUID nameUUIDFromBytes(byte[] name) { MessageDigest md; try { md = MessageDigest.getInstance("MD5"); } catch (NoSuchAlgorithmException nsae) { throw new InternalError("MD5 not supported", nsae); } byte[] md5Bytes = md.digest(name); md5Bytes[6] &= 0x0f; /* clear version */ md5Bytes[6] |= 0x30; /* set to version 3 */ md5Bytes[8] &= 0x3f; /* clear variant */ md5Bytes[8] |= 0x80; /* set to IETF variant */ return new UUID(md5Bytes); }
version 4：随机UUID
public static UUID randomUUID() { SecureRandom ng = Holder.numberGenerator; byte[] randomBytes = new byte[16]; ng.nextBytes(randomBytes); randomBytes[6] &= 0x0f; /* clear version */ randomBytes[6] |= 0x40; /* set to version 4 */ randomBytes[8] &= 0x3f; /* clear variant */ randomBytes[8] |= 0x80; /* set to IETF variant */ return new UUID(randomBytes); }
version 5：基于名字的UUID（SHA1）
3.3 UUID生成方法
下面代码是生成uuid的典型方法：
UUID uuid = UUID.randomUUID(); System.out.println(uuid);
本地测试生成的uuid结果为：744124dc-0e39-460b-8898-ba7285d796f5，是一个十六进制数字的字符串。
因为字符串包含36个字符，比较长，所以在使用时，有时候也会考虑用UUID的getMostSignificantBits方法，只保留最具明显特征的64bit，例如：
long uuid = UUID.randomUUID().getMostSignificantBits(); System.out.println(uuid);
结果为：-3023758490243282597。
3.4 UUID的唯一性保证
随机产生的UUID（例如说由java.util.UUID类别产生的）的128个比特中，有122个比特是随机产生，4个比特在此版本（'Randomly generated UUID'）被使用，还有2个在其变体（'Leach-Salz'）中被使用。利用生日悖论，可计算出两笔UUID拥有相同值的机率约为：
以下是以x=2^122计算出UUID后产生碰撞的机率：
可见，随机方法产生重复GUID并造成错误的概率是非常低的。
3.5 是否线程安全？
我们再来看一下UUID的randomUUID()方法：
SecureRandom ng = Holder.numberGenerator; byte[] randomBytes = new byte[16]; ng.nextBytes(randomBytes); randomBytes[6] &= 0x0f; /* clear version */ randomBytes[6] |= 0x40; /* set to version 4 */ randomBytes[8] &= 0x3f; /* clear variant */ randomBytes[8] |= 0x80; /* set to IETF variant */ return new UUID(randomBytes);
重点是SecureRandom ng = Holder.numberGenerator;这里。Holder的位置：
private static class Holder { static final SecureRandom numberGenerator = new SecureRandom(); }
看到这里，相信有些基础扎实的朋友会想到单例模式的一种实现方式了，静态内部类方式，通过这种方式保证了获取单例实例时的线程安全。
接下来是ng.nextBytes(randomBytes);
@Override public void nextBytes(byte[] bytes) { secureRandomSpi.engineNextBytes(bytes); }
SecureRandomSpi是一个抽象类：
protected abstract void engineNextBytes(byte[] bytes);
SecureRandom就是SecureRandomSpi的实现类，实现方法如下：
public synchronized void engineNextBytes(byte[] var1) { int var2 = 0; byte[] var4 = this.remainder; if (this.state == null) { byte[] var5 = new byte[20]; SecureRandom.SeederHolder.seeder.engineNextBytes(var5); this.state = this.digest.digest(var5); } int var7 = this.remCount; int var3; int var6; if (var7 > 0) { var3 = var1.length - var2 < 20 - var7 ? var1.length - var2 : 20 - var7; for(var6 = 0; var6 < var3; ++var6) { var1[var6] = var4[var7]; var4[var7++] = 0; } this.remCount += var3; var2 += var3; } while(var2 < var1.length) { this.digest.update(this.state); var4 = this.digest.digest(); updateState(this.state, var4); var3 = var1.length - var2 > 20 ? 20 : var1.length - var2; for(var6 = 0; var6 < var3; ++var6) { var1[var2++] = var4[var6]; var4[var6] = 0; } this.remCount += var3; } this.remainder = var4; this.remCount %= 20; }
方法中的synchronized关键字，表明了这是一个同步方法，通过synchronized实现同步。
Uuid是不可变的，所以它可能是线程安全的，但显然有些访问器中存在一些使其不安全的evil caching going on（该bug现在已修复）。但是线程转储只是说一个线程正在等待SecureRandom.nextBytes的锁，该锁由UUID.randomUUID工厂使用，这绝对是线程安全的。据我所知，当多个线程同时调用它时，应该会发生这种情况。
