Java UUID

前提

UUID是Universally Unique IDentifier的缩写,翻译为通用唯一标识符或者全局唯一标识符。对于UUID的描述,下面摘录一下规范文件A Universally Unique IDentifier (UUID) URN Namespace中的一些描述: :::info UUID(也称为GUID)定义了统一资源名称命名空间。UUID的长度为128比特,可以保证在空间和时间上的唯一性。 ::: 「动机:」 :::info 使用UUID的主要原因之一是不需要集中式管理,其中一种格式限定了IEEE 802节点标识符,其他格式无此限制。可以自动化按需生成UUID,应用于多重不同的场景。UUID算法支持极高的分配速率,每台机器每秒钟可以生成超过1000万个UUID,因此它们可以作为事务ID使用。UUID具有固定大小128比特,与其他替代方案相比,它具有体积小的优势,非常适用于各种排序、散列和存储在数据库中,具有编程易用性的特点。 ::: 这里只需要记住UUID几个核心特定:

  • 全局时空唯一性
  • 固定长度128比特,也就是16字节(1 byte = 8 bit)
  • 分配速率极高,单机每秒可以生成超过1000万个UUID(实际上更高)

下面就JDK中的UUID实现详细分析一下UUID生成算法。编写本文的时候选用的JDK为JDK11。

再聊UUID

前面为了编写简单的摘要,所以只粗略摘录了规范文件里面的一些章节,这里再详细聊聊UUID的一些定义、碰撞概率等等。

UUID定义

UUID是一种软件构建的标准,也是开放软件基金会组织在分布式计算环境领域的一部分。提出此标准的目的是:让分布式系统中的所有元素或者组件都有唯一的可辨别的信息,因为极低冲突频率和高效算法的基础,它不需要集中式控制和管理唯一可辨别信息的生成,由此,每个使用者都可以自由地创建与其他人不冲突的UUID。
「UUID本质是一个128比特的数字」,这是一个位长巨大的数值,理论上来说,UUID的总数量为2^128个。这个数字大概可以这样估算:如果「每纳秒」产生「1兆」个不相同的UUID,需要花费超过100亿年才会用完所有的UUID。

UUID的变体与版本

UUID标准和算法定义的时候,为了考虑历史兼容性和未来的扩展,提供了多种变体和版本。接下来的变体和版本描述来源于维基百科中的Versions章节和RFC 4122中的Variant章节。
目前已知的变体如下:

  • 变体0xx:Reserved, NCS backward compatibility,为向后兼容做预留的变体
  • 变体10x:The IETF aka Leach-Salz variant (used by this class),称为Leach–Salz UUID或者IETF UUID,JDK中UUID目前正在使用的变体
  • 变体110:Reserved, Microsoft Corporation backward compatibility,微软早期GUID预留变体
  • 变体111:Reserved for future definition,将来扩展预留,目前还没被使用的变体

目前已知的版本如下:

  • 空UUID(特殊版本0),用00000000-0000-0000-0000-000000000000表示,也就是所有的比特都是0
  • date-time and MAC address(版本1):基于时间和MAC地址的版本,通过计算当前时间戳、随机数和机器MAC地址得到。由于有MAC地址,这个可以保证其在全球的唯一性。但是使用了MAC地址,就会有MAC地址暴露问题。若是局域网,可以用IP地址代替
  • date-time and MAC address, DCE security version(版本2):分布式计算环境安全的UUID,算法和版本1基本一致,但会把时间戳的前4位置换为POSIX的UID或GID
  • namespace name-based MD5(版本3):通过计算名字和命名空间的MD5散列值得到。这个版本的UUID保证了:相同命名空间中不同名字生成的UUID的唯一性;不同命名空间中的UUID的唯一性;相同命名空间中相同名字的UUID重复生成是相同的
  • random(版本4):根据随机数,或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的,还有一个特点就是预留了6比特存放变体和版本属性,所以随机生成的位一共有122个,总量为2^122,比其他变体的总量要偏少
  • namespace name-based SHA-1(版本5):和版本3类似,散列算法换成了SHA-1

其中,JDK中应用的变体是Leach-Salz,提供了namespace name-based MD5(版本3)和random(版本4)两个版本的UUID生成实现。

UUID的格式

在规范文件描述中,UUID是由16个8比特数字,或者说32个16进制表示形式下的字符组成,一般表示形式为8-4-4-4-12,加上连接字符-一共有36个字符,例如:

  1. ## 例子
  2. 123e4567-e89b-12d3-a456-426614174000
  3. ## 通用格式
  4. xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

其中4比特长度的M和1到3比特长度的N分别代表版本号和变体标识。UUID的具体布局如下:

属性 属性名 长度(bytes) 长度(16进制符) 内容
time_low 时间戳低位 4 8 代表时间戳的低32
比特的整数表示
time_mid 时间戳中位 2 4 代表时间戳的中间16
比特的整数表示
time_hi_and_version 时间戳高位和版本号 2 4 高位4比特是版本号表示,剩余是时间戳的高12比特的整数表示
clock_seq_hi_and_res clock_seq_low 时钟序列与变体编号 2 4 最高位1到3比特表示变体编号,剩下的13到15比特表示时钟序列
node 节点ID 6 12 48比特表示的节点ID

基于这个表格画一个图:
2021-05-19-14-53-14-892857.png
「严重注意,重复三次」:

  • 上面提到的UUID的具体布局只适用于date-time and MAC address(版本1)和date-time and MAC address, DCE security version(版本2),其他版本虽然采用了基本一样的字段分布,但是无法获取时间戳、时钟序列或者节点ID等信息
  • 上面提到的UUID的具体布局只适用于date-time and MAC address(版本1)和date-time and MAC address, DCE security version(版本2),其他版本虽然采用了基本一样的字段分布,但是无法获取时间戳、时钟序列或者节点ID等信息
  • 上面提到的UUID的具体布局只适用于date-time and MAC address(版本1)和date-time and MAC address, DCE security version(版本2),其他版本虽然采用了基本一样的字段分布,但是无法获取时间戳、时钟序列或者节点ID等信息 :::info JDK中只提供了版本3和版本4的实现,但是java.util.UUID的布局采用了上面表格的字段 :::

    UUID的碰撞几率计算

    UUID的总量虽然巨大,但是如果不停地使用,假设每纳秒生成超过1兆个UUID并且人类有幸能够繁衍到100亿年以后,总会有可能产生重复的UUID。那么,怎么计算UUID的碰撞几率呢?这是一个数学问题,可以使用比较著名的「生日悖论」解决:
    2021-05-19-14-53-15-131221.png
    上图来源于某搜索引擎百科。刚好维基百科上给出了碰撞几率的计算过程,其实用的也是生日悖论的计算方法,这里贴一下:
    2021-05-19-14-53-15-413467.png
    上面的碰撞几率计算是基于Leach–Salz变体和版本4进行,得到的结论是:

  • 103万亿个UUID中找到重复项的概率是十亿分之一

  • 要生成一个冲突率达到50%的UUID至少需要生成2.71 * 1_000_000^3个UUID

有生之年不需要担心UUID冲突,出现的可能性比大型陨石撞地球还低。

UUID的使用场景

基本所有需要使用全局唯一标识符的场景都可以使用UUID,除非对长度有明确的限制,常用的场景包括:

  • 日志框架映射诊断上下文中的TRACE_ID
  • APM工具或者说OpenTracing规范中的SPAN_ID
  • 特殊场景下数据库主键或者虚拟外键
  • 交易ID(订单ID)
  • 等等……

    JDK中UUID详细介绍和使用

    这里先介绍使用方式。前面提到JDK中应用的变体是Leach-Salz(变体2),提供了namespace name-based MD5(版本3)和random(版本4)两个版本的UUID生成实现,实际上java.util.UUID提供了四种生成UUID实例的方式:

  • 最常见的就是调用静态方法UUID#randomUUID(),这就是版本4的静态工厂方法

  • 其次是调用静态方法UUID#nameUUIDFromBytes(byte[] name),这就是版本3的静态工厂方法
  • 另外有调用静态方法UUID#fromString(String name),这是解析8-4-4-4-12格式字符串生成UUID实例的静态工厂方法
  • 还有低层次的构造函数UUID(long mostSigBits, long leastSigBits),这个对于使用者来说并不常见

最常用的方法有实例方法toString(),把UUID转化为16进制字符串拼接而成的8-4-4-4-12形式表示,例如:

  1. String uuid = UUID.randomUUID().toString();

其他Getter方法:

  1. UUID uuid = UUID.randomUUID();
  2. // 返回版本号
  3. int version = uuid.version();
  4. // 返回变体号
  5. int variant = uuid.variant();
  6. // 返回时间戳 - 这个方法会报错,只有Time-based UUID也就是版本1或者2的UUID实现才能返回时间戳
  7. long timestamp = uuid.timestamp();
  8. // 返回时钟序列 - 这个方法会报错,只有Time-based UUID也就是版本1或者2的UUID实现才能返回时钟序列
  9. long clockSequence = uuid.clockSequence();
  10. // 返回节点ID - 这个方法会报错,只有Time-based UUID也就是版本1或者2的UUID实现才能返回节点ID
  11. long nodeId = uuid.node();
  12. 可以验证一下不同静态工厂方法的版本和变体号:
  13. UUID uuid = UUID.randomUUID();
  14. int version = uuid.version();
  15. int variant = uuid.variant();
  16. System.out.println(String.format("version:%d,variant:%d", version, variant));
  17. uuid = UUID.nameUUIDFromBytes(new byte[0]);
  18. version = uuid.version();
  19. variant = uuid.variant();
  20. System.out.println(String.format("version:%d,variant:%d", version, variant));
  21. // 输出结果
  22. version:4,variant:2
  23. version:3,variant:2

探究JDK中UUID源码实现

java.util.UUID被final修饰,实现了Serializable和Comparable接口,从一般理解上看,有下面的特定:

  • 不可变,一般来说工具类都是这样定义的
  • 可序列化和反序列化
  • 不同的对象之间可以进行比较,比较方法后面会分析

下面会从不同的方面分析一下java.util.UUID的源码实现:

  • 属性和构造函数
  • 随机数版本实现
  • namespace name-based MD5版本实现
  • 其他实现
  • 格式化输出
  • 比较相关的方法

    属性和构造函数

    前面反复提到JDK中只提供了版本3和版本4的实现,但是java.util.UUID的布局采用了UUID规范中的字段定义,长度一共128比特,刚好可以存放在两个long类型的整数中,所以看到了UUID类中存在两个long类型的整型数值:

    1. public final class UUID implements java.io.Serializable, Comparable<UUID> {
    2. // 暂时省略其他代码
    3. /*
    4. * The most significant 64 bits of this UUID.
    5. * UUID中有效的高64比特
    6. *
    7. * @serial
    8. */
    9. private final long mostSigBits;
    10. /*
    11. * The least significant 64 bits of this UUID.
    12. * UUID中有效的低64比特
    13. *
    14. * @serial
    15. */
    16. private final long leastSigBits;
    17. // 暂时省略其他代码
    18. }

    从UUID类注释中可以看到具体的字段布局如下:
    「高64比特mostSigBits的布局」

字段 bit长度 16进制字符长度
time_low 32 8
time_mid 16 4
version 4 1
time_hi 12 3

「低64比特leastSigBits的布局」

字段 bit长度 16进制字符长度
variant 2 小于1
clock_seq 14 variant和clock_seq加起来等于4
node 48 12

接着看UUID的其他成员属性和构造函数:

  1. public final class UUID implements java.io.Serializable, Comparable<UUID> {
  2. // 暂时省略其他代码
  3. // Java语言访问类,里面存放了很多底层相关的访问或者转换方法,在UUID中主要是toString()实例方法用来格式化成8-4-4-4-12的形式,委托到Long.fastUUID()方法
  4. private static final JavaLangAccess jla = SharedSecrets.getJavaLangAccess();
  5. // 静态内部类确保SecureRandom初始化,用于版本4的随机数UUID版本生成安全随机数
  6. private static class Holder {
  7. static final SecureRandom numberGenerator = new SecureRandom();
  8. }
  9. // 通过长度为16的字节数组,计算mostSigBits和leastSigBits的值初始化UUID实例
  10. private UUID(byte[] data) {
  11. long msb = 0;
  12. long lsb = 0;
  13. assert data.length == 16 : "data must be 16 bytes in length";
  14. for (int i=0; i<8; i++)
  15. msb = (msb << 8) | (data[i] & 0xff);
  16. for (int i=8; i<16; i++)
  17. lsb = (lsb << 8) | (data[i] & 0xff);
  18. this.mostSigBits = msb;
  19. this.leastSigBits = lsb;
  20. }
  21. // 直接指定mostSigBits和leastSigBits构造UUID实例
  22. public UUID(long mostSigBits, long leastSigBits) {
  23. this.mostSigBits = mostSigBits;
  24. this.leastSigBits = leastSigBits;
  25. }
  26. // 暂时省略其他代码
  27. }

私有构造private UUID(byte[] data)中有一些位运算技巧:

  1. long msb = 0;
  2. long lsb = 0;
  3. assert data.length == 16 : "data must be 16 bytes in length";
  4. for (int i=0; i<8; i++)
  5. msb = (msb << 8) | (data[i] & 0xff);
  6. for (int i=8; i<16; i++)
  7. lsb = (lsb << 8) | (data[i] & 0xff);
  8. this.mostSigBits = msb;
  9. this.leastSigBits = lsb;

输入的字节数组长度为16,mostSigBits由字节数组的前8个字节转换而来,而leastSigBits由字节数组的后8个字节转换而来。中间变量msb或者lsb在提取字节位进行计算的时候:

  • 先进行左移8位确保需要计算的位为0,已经计算好的位移动到左边
  • 然后右边需要提取的字节data[i]的8位会先和0xff(补码1111 1111)进行或运算,确保不足8位的高位被补充为0,超过8位的高位会被截断为低8位,也就是data[i] & 0xff确保得到的补码为8位
  • 前面两步的结果再进行或运算

一个模拟过程如下:

  1. (为了区分明显,每4位加了一个下划线)
  2. (为了简答,只看字节数组的前4个字节,同时只看long类型的前4个字节)
  3. 0xff === 1111_1111
  4. long msb = 0 => 0000_0000 0000_0000 0000_0000 0000_0000
  5. byte[] data
  6. 0000_0001 0000_0010 0000_0100 0000_1000
  7. i = 0(第一轮)
  8. msb << 8 = 0000_0000 0000_0000 0000_0000 0000_0000
  9. data[i] & 0xff = 0000_0001 & 1111_1111 = 0000_0001
  10. (msb << 8) | (data[i] & 0xff) = 0000_0000 0000_0000 0000_0000 0000_0001
  11. (第一轮 msb = 0000_0000 0000_0000 0000_0000 0000_0001
  12. i = 1(第二轮)
  13. msb << 8 = 0000_0000 0000_0000 0000_0001 0000_0000
  14. data[i] & 0xff = 0000_0010 & 1111_1111 = 0000_0010
  15. (msb << 8) | (data[i] & 0xff) = 0000_0000 0000_0000 0000_0001 0000_0010
  16. (第二轮 msb = 0000_0000 0000_0000 0000_0001 0000_0010
  17. i = 2(第三轮)
  18. msb << 8 = 0000_0000 0000_0001 0000_0010 0000_0000
  19. data[i] & 0xff = 0000_0100 & 1111_1111 = 0000_0100
  20. (msb << 8) | (data[i] & 0xff) = 0000_0000 0000_0001 0000_0010 0000_0100
  21. (第三轮 msb = 0000_0000 0000_0001 0000_0010 0000_0100
  22. i = 3(第四轮)
  23. msb << 8 = 0000_0001 0000_0010 0000_0100 0000000
  24. data[i] & 0xff = 0000_1000 & 1111_1111 = 0000_1000
  25. (msb << 8) | (data[i] & 0xff) = 0000_0001 0000_0010 0000_0100 0000_1000
  26. (第四轮 msb = 0000_0001 0000_0010 0000_0100 0000_1000

以此类推,这个私有构造函数执行完毕后,长度为16的字节数组的所有位就会转移到mostSigBits和leastSigBits中。

随机数版本实现

构造函数分析完,接着分析重磅的静态工厂方法UUID#randomUUID(),这是使用频率最高的一个方法:

  1. public static UUID randomUUID() {
  2. // 静态内部类Holder持有的SecureRandom实例,确保提前初始化
  3. SecureRandom ng = Holder.numberGenerator;
  4. // 生成一个16字节的安全随机数,放在长度为16的字节数组中
  5. byte[] randomBytes = new byte[16];
  6. ng.nextBytes(randomBytes);
  7. // 清空版本号所在的位,重新设置为4
  8. randomBytes[6] &= 0x0f; /* clear version */
  9. randomBytes[6] |= 0x40; /* set to version 4 */
  10. // 清空变体号所在的位,重新设置为
  11. randomBytes[8] &= 0x3f; /* clear variant */
  12. randomBytes[8] |= 0x80; /* set to IETF variant */
  13. return new UUID(randomBytes);
  14. }

关于上面的位运算,这里可以使用极端的例子进行推演:

  1. 假设randomBytes[6] = 1111_1111
  2. // 清空version位
  3. randomBytes[6] &= 0x0f => 1111_1111 & 0000_1111 = 0000_1111
  4. 得到randomBytes[6] = 0000_1111 (这里可见高4比特被清空为0
  5. // 设置version位为整数4 => 十六进制0x40 => 二级制补码0100_0000
  6. randomBytes[6] |= 0x40 => 0000_1111 | 0100_0000 = 0100_1111
  7. 得到randomBytes[6] = 0100_1111
  8. 结果:version => 01004 bit)=> 对应十进制数4
  9. 同理
  10. 假设randomBytes[8] = 1111_1111
  11. // 清空variant位
  12. randomBytes[8] &= 0x3f => 1111_1111 & 0011_1111 = 0011_1111
  13. // 设置variant位为整数128 => 十六进制0x80 => 二级制补码1000_0000 (这里取左边高位2位)
  14. randomBytes[8] |= 0x80 => 0011_1111 | 1000_0000 = 1011_1111
  15. 结果:variant => 102 bit)=> 对应十进制数2

关于UUID里面的Getter方法例如version()variant()其实就是找到对应的位,并且转换为十进制整数返回,如果熟练使用位运算,应该不难理解,后面不会分析这类的Getter方法。
「随机数版本实现强依赖于SecureRandom生成的随机数(字节数组)」。SecureRandom的引擎提供者可以从sun.security.provider.SunEntries中查看,对于不同系统版本的JDK实现会选用不同的引擎,常见的如NativePRNG。JDK11配置文件$JAVA_HOME/conf/security/java.security中的securerandom.source属性用于指定系统默认的随机源:
2021-05-19-14-53-17-355317.png
这里要提一个小知识点,想要得到密码学意义上的安全随机数,可以直接使用真随机数产生器产生的随机数,或者使用真随机数产生器产生的随机数做种子。通过查找一些资料得知「非物理真随机数产生器」有:

  • Linux操作系统的/dev/random设备接口
  • Windows操作系统的CryptGenRandom接口

如果不修改java.security配置文件,默认随机数提供引擎会根据不同的操作系统选用不同的实现,这里不进行深究。在Linux环境下,SecureRandom实例化后,不通过setSeed()方法设置随机数作为种子,默认就是使用/dev/random提供的安全随机数接口获取种子,产生的随机数是密码学意义上的安全随机数。「一句话概括,UUID中的私有静态内部类Holder中的SecureRandom实例可以产生安全随机数,这个是JDK实现UUID版本4的一个重要前提」。这里总结一下随机数版本UUID的实现步骤:

  • 通过SecureRandom依赖提供的安全随机数接口获取种子,生成一个16字节的随机数(字节数组)
  • 对于生成的随机数,清空和重新设置versionvariant对应的位
  • 把重置完versionvariant的随机数的所有位转移到mostSigBitsleastSigBits

    namespace name-based MD5版本实现

    接着分析版本3也就是namespace name-based MD5版本的实现,对应于静态工厂方法UUID#nameUUIDFromBytes()

    1. public static UUID nameUUIDFromBytes(byte[] name) {
    2. MessageDigest md;
    3. try {
    4. md = MessageDigest.getInstance("MD5");
    5. } catch (NoSuchAlgorithmException nsae) {
    6. throw new InternalError("MD5 not supported", nsae);
    7. }
    8. byte[] md5Bytes = md.digest(name);
    9. md5Bytes[6] &= 0x0f; /* clear version */
    10. md5Bytes[6] |= 0x30; /* set to version 3 */
    11. md5Bytes[8] &= 0x3f; /* clear variant */
    12. md5Bytes[8] |= 0x80; /* set to IETF variant */
    13. return new UUID(md5Bytes);
    14. }

    它的后续基本处理和随机数版本基本一致(清空版本位的时候,重新设置为3),唯一明显不同的地方就是生成原始随机数的时候,采用的方式是:基于输入的name字节数组,通过MD5摘要算法生成一个MD5摘要字节数组作为原始安全随机数,返回的这个随机数刚好也是16字节长度的。使用方式很简单:

    1. UUID uuid = UUID.nameUUIDFromBytes("throwable".getBytes());

    namespace name-based MD5版本UUID的实现步骤如下:

  • 通过输入的命名字节数组基于MD5算法生成一个16字节长度的随机数

  • 对于生成的随机数,清空和重新设置version和variant对应的位
  • 把重置完version和variant的随机数的所有位转移到mostSigBits和leastSigBits中

namespace name-based MD5版本的UUID强依赖于MD5算法,有个明显的特征是如果输入的byte[] name一致的情况下,会产生完全相同的UUID实例。

其他实现

其他实现主要包括:

  1. // 完全定制mostSigBits和leastSigBits,可以参考UUID标准字段布局进行设置,也可以按照自行制定的标准
  2. public UUID(long mostSigBits, long leastSigBits) {
  3. this.mostSigBits = mostSigBits;
  4. this.leastSigBits = leastSigBits;
  5. }
  6. // 基于字符串格式8-4-4-4-12的UUID输入,重新解析出mostSigBits和leastSigBits,这个静态工厂方法也不常用,里面的位运算也不进行详细探究
  7. public static UUID fromString(String name) {
  8. int len = name.length();
  9. if (len > 36) {
  10. throw new IllegalArgumentException("UUID string too large");
  11. }
  12. int dash1 = name.indexOf('-', 0);
  13. int dash2 = name.indexOf('-', dash1 + 1);
  14. int dash3 = name.indexOf('-', dash2 + 1);
  15. int dash4 = name.indexOf('-', dash3 + 1);
  16. int dash5 = name.indexOf('-', dash4 + 1);
  17. if (dash4 < 0 || dash5 >= 0) {
  18. throw new IllegalArgumentException("Invalid UUID string: " + name);
  19. }
  20. long mostSigBits = Long.parseLong(name, 0, dash1, 16) & 0xffffffffL;
  21. mostSigBits <<= 16;
  22. mostSigBits |= Long.parseLong(name, dash1 + 1, dash2, 16) & 0xffffL;
  23. mostSigBits <<= 16;
  24. mostSigBits |= Long.parseLong(name, dash2 + 1, dash3, 16) & 0xffffL;
  25. long leastSigBits = Long.parseLong(name, dash3 + 1, dash4, 16) & 0xffffL;
  26. leastSigBits <<= 48;
  27. leastSigBits |= Long.parseLong(name, dash4 + 1, len, 16) & 0xffffffffffffL;
  28. return new UUID(mostSigBits, leastSigBits);
  29. }

格式化输出

格式化输出体现在UUID#toString()方法,这个方法会把mostSigBitsleastSigBits格式化为8-4-4-4-12的形式,这里详细分析一下格式化的过程。首先从注释上看格式是:

  1. <time_low>-<time_mid>-<time_high_and_version>-<variant_and_sequence>-<node>
  2. time_low = 4 * <hexOctet> => 416进制8位字符
  3. time_mid = 2 * <hexOctet> => 216进制8位字符
  4. time_high_and_version = 4 * <hexOctet> => 216进制8位字符
  5. variant_and_sequence = 4 * <hexOctet> => 216进制8位字符
  6. node = 4 * <hexOctet> => 616进制8位字符
  7. hexOctet = <hexDigit><hexDigit>(2hexDigit
  8. hexDigit = 0-9a-F(其实就是16进制的字符)

和前文布局分析时候的提到的内容一致。UUID#toString()方法源码如下:

  1. private static final JavaLangAccess jla = SharedSecrets.getJavaLangAccess();
  2. public String toString() {
  3. return jla.fastUUID(leastSigBits, mostSigBits);
  4. }
  5. ↓↓↓↓↓↓↓↓↓↓↓↓
  6. // java.lang.System
  7. private static void setJavaLangAccess() {
  8. SharedSecrets.setJavaLangAccess(new JavaLangAccess() {
  9. public String fastUUID(long lsb, long msb) {
  10. return Long.fastUUID(lsb, msb);
  11. }
  12. }
  13. ↓↓↓↓↓↓↓↓↓↓↓↓
  14. // java.lang.Long
  15. static String fastUUID(long lsb, long msb) {
  16. // COMPACT_STRINGS在String类中默认为true,所以会命中if分支
  17. if (COMPACT_STRINGS) {
  18. // 初始化36长度的字节数组
  19. byte[] buf = new byte[36];
  20. // lsb的低48位转换为16进制格式写入到buf中 - node => 位置[24,35]
  21. formatUnsignedLong0(lsb, 4, buf, 24, 12);
  22. // lsb的高16位转换为16进制格式写入到buf中 - variant_and_sequence => 位置[19,22]
  23. formatUnsignedLong0(lsb >>> 48, 4, buf, 19, 4);
  24. // msb的低16位转换为16进制格式写入到buf中 - time_high_and_version => 位置[14,17]
  25. formatUnsignedLong0(msb, 4, buf, 14, 4);
  26. // msb的中16位转换为16进制格式写入到buf中 - time_mid => 位置[9,12]
  27. formatUnsignedLong0(msb >>> 16, 4, buf, 9, 4);
  28. // msb的高32位转换为16进制格式写入到buf中 - time_low => 位置[0,7]
  29. formatUnsignedLong0(msb >>> 32, 4, buf, 0, 8);
  30. // 空余的字节槽位插入'-',刚好占用了4个字节
  31. buf[23] = '-';
  32. buf[18] = '-';
  33. buf[13] = '-';
  34. buf[8] = '-';
  35. // 基于处理好的字节数组,实例化String,并且编码指定为LATIN1
  36. return new String(buf, LATIN1);
  37. } else {
  38. byte[] buf = new byte[72];
  39. formatUnsignedLong0UTF16(lsb, 4, buf, 24, 12);
  40. formatUnsignedLong0UTF16(lsb >>> 48, 4, buf, 19, 4);
  41. formatUnsignedLong0UTF16(msb, 4, buf, 14, 4);
  42. formatUnsignedLong0UTF16(msb >>> 16, 4, buf, 9, 4);
  43. formatUnsignedLong0UTF16(msb >>> 32, 4, buf, 0, 8);
  44. StringUTF16.putChar(buf, 23, '-');
  45. StringUTF16.putChar(buf, 18, '-');
  46. StringUTF16.putChar(buf, 13, '-');
  47. StringUTF16.putChar(buf, 8, '-');
  48. return new String(buf, UTF16);
  49. }
  50. }
  51. /**
  52. * 格式化无符号的长整型,填充到字节缓冲区buf中,如果长度len超过了输入值的ASCII格式表示,则会使用0进行填充
  53. * 这个方法就是把输入长整型值val,对应一段长度的位,填充到字节数组buf中,len控制写入字符的长度,offset控制写入buf的起始位置
  54. * 而shift参数决定基础格式,4是16进制,1是2进制,3是8位
  55. */
  56. static void formatUnsignedLong0(long val, int shift, byte[] buf, int offset, int len) {
  57. int charPos = offset + len;
  58. int radix = 1 << shift;
  59. int mask = radix - 1;
  60. do {
  61. buf[--charPos] = (byte)Integer.digits[((int) val) & mask];
  62. val >>>= shift;
  63. } while (charPos > offset);
  64. }

比较相关的方法

比较相关方法如下:

  1. // hashCode方法基于mostSigBits和leastSigBits做异或得出一个中间变量hilo,再以32为因子进行计算
  2. public int hashCode() {
  3. long hilo = mostSigBits ^ leastSigBits;
  4. return ((int)(hilo >> 32)) ^ (int) hilo;
  5. }
  6. // equals为实例对比方法,直接对比两个UUID的mostSigBits和leastSigBits值,完全相等的时候返回true
  7. public boolean equals(Object obj) {
  8. if ((null == obj) || (obj.getClass() != UUID.class))
  9. return false;
  10. UUID id = (UUID)obj;
  11. return (mostSigBits == id.mostSigBits &&
  12. leastSigBits == id.leastSigBits);
  13. }
  14. // 比较规则是mostSigBits高位大者为大,高位相等的情况下,leastSigBits大者为大
  15. public int compareTo(UUID val) {
  16. // The ordering is intentionally set up so that the UUIDs
  17. // can simply be numerically compared as two numbers
  18. return (this.mostSigBits < val.mostSigBits ? -1 :
  19. (this.mostSigBits > val.mostSigBits ? 1 :
  20. (this.leastSigBits < val.leastSigBits ? -1 :
  21. (this.leastSigBits > val.leastSigBits ? 1 :
  22. 0))));
  23. }

所有比较方法仅仅和mostSigBitsleastSigBits有关,毕竟这两个长整型就存储了UUID实例的所有信息。