神秘的UUID

Java
301
0
0
2024-02-25

一 简介

作为开发人员大家对 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。

神秘的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-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 (Leach-Salz) UUID is as follows:
 *
 * The most significant long consists of the following  unsigned  fields:
 * <pre>
 *xFFFFFFFF00000000 time_low
 *x00000000FFFF0000 time_mid
 *x000000000000F000 version
 *x0000000000000FFF time_hi
 * </pre>
 * The least significant long consists of the following unsigned fields:
 * <pre>
 *xC000000000000000 variant
 *x3FFF000000000000 clock_seq
 *x0000FFFFFFFFFFFF node
 * </pre> 

从中我们可以看到:

1、UUID 表示一个 128 位的值;

2、这些通用标识符具有不同的变体。此类的方法用于操作 Leach-Salz 变体,不过 构造方法 允许创建任何 UUID 变体(将在下面进行描述);

3、变体 2 (Leach-Salz) UUID 的布局如下: long 型数据的最高有效位由以下无符号字段组成:

xFFFFFFFF00000000 time_low
x00000000FFFF0000 time_mid
x000000000000F000 version
x0000000000000FFF time_hi

long 型数据的最低有效位由以下无符号字段组成:

xC000000000000000 variant
x3FFF000000000000 clock_seq
x0000FFFFFFFFFFFF 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() !=) {
        throw new UnsupportedOperation Exception ("Not a time-based UUID");
    }


    return (mostSigBits &x0FFFL) << 48
         | ((mostSigBits >>) & 0x0FFFFL) << 32
         | mostSigBits >>>;
} 

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("MD not supported", nsae);
    }
    byte[] mdBytes = md.digest(name);
    mdBytes[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[];
    ng.nextBytes(randomBytes);
    randomBytes[]  &= 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 拥有相同值的机率约为:

神秘的UUID

以下是以 x=2^122 计算出 UUID 后产生碰撞的机率:

神秘的UUID

可见,随机方法产生重复 GUID 并造成错误的概率是非常低的。

3.5 是否线程安全?

我们再来看一下 UUID 的 randomUUID()方法:

 SecureRandom ng = Holder.numberGenerator;


byte[] randomBytes = new byte[];
ng.nextBytes(randomBytes);
randomBytes[]  &= 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 var = 0;
        byte[] var = this.remainder;
        if (this.state ==  null ) {
            byte[] var = new byte[20];
            SecureRandom.SeederHolder.seeder.engineNextBytes(var);
            this.state = this.digest.digest(var);
        }


        int var = this.remCount;
        int var;
        int var;
        if (var > 0) {
            var = var1.length - var2 < 20 - var7 ? var1.length - var2 : 20 - var7;


            for(var = 0; var6 < var3; ++var6) {
                var[var6] = var4[var7];
                var[var7++] = 0;
            }


            this.remCount += var;
            var += var3;
        }


        while(var < var1.length) {
            this.digest.update(this.state);
            var = this.digest.digest();
            updateState(this.state, var);
            var = var1.length - var2 > 20 ? 20 : var1.length - var2;


            for(var = 0; var6 < var3; ++var6) {
                var[var2++] = var4[var6];
                var[var6] = 0;
            }


            this.remCount += var;
        }


        this.remainder = var;
        this.remCount %=;
    } 

方法中的 synchronized 关键字,表明了这是一个同步方法,通过 synchronized 实现同步。

Uuid 是不可变的,所以它可能是线程安全的,但显然有些访问器中存在一些使其不安全的evil caching going on(该 bug 现在已修复)。但是线程转储只是说一个线程正在等待 SecureRandom.nextBytes 的锁,该锁由 UUID.randomUUID 工厂使用,这绝对是线程安全的。据我所知,当多个线程同时调用它时,应该会发生这种情况。