一 简介
作为开发人员大家对 UUID 应该都比较熟悉了， Java 中也提供了相关的类和生成方法，供业务中使用。这里准备对 UUID 生成的过程做一次深入了解。
二 什么是 UUID
2.1 概念
根据 百度百科 的描述：
UUID 是 通用唯一识别码（Universally Unique Identifier）的缩写，是一种软件建构的标准，亦为 开放软件基金会 组织在分布式计算环境领域的一部分。其目的，是让 分布式系统 中的所有元素，都能有唯一的辨识信息，而不需要通过中央控制端来做辨识信息的指定。如此一来，每个人都可以创建不与其它人冲突的 UUID。
2.2 UUID 实例
现实中，最广泛应用的 UUID，是 微软 的全局唯一标识符（GUID），而其他重要的应用，则有 Linux ext2/ ext 3 文件系统、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 UnsupportedOperation Exception ("Not a time-based UUID");
}
return (mostSigBits & 0x0FFFL) << 48
| ((mostSigBits >> 16) & 0x0FFFFL) << 32
| mostSigBits >>> 32;
} version 2：DCE 安全的 UUID
相关文档：
DCE（Distributed Computing Environment）安全的 UUID 和基于时间的 UUID 算法相同，但会把时间戳的前 4 位置换为 POSIX 的 UID 或 GID。这个版本的 UUID 在实际中较少用到。
version 3：基于名字的 UUID
public static UUID nameUUIDFrom byte s(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. number Generator;
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); Secure Random 就是 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 工厂使用，这绝对是线程安全的。据我所知，当多个线程同时调用它时，应该会发生这种情况。
