Java中的UUID简单介绍

1、UUID的格式

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
8个十六进制数—4个十六进制数—4个十六进制数—4个十六进制数—12个十六进制数
一共是32个十六进制数,128bit。刚好跟IPV6数目相等。
估计我们有生之年是用不完了。(有点可惜,我尽然不能看到UUID被用尽的那一天)。
详细UUID保证唯一性的介绍,传送门。

2、获取UUID的三种方式

UUID.randomUUID();  //最常用
UUID.fromString("095c64fe-c5bf-11ea-aec6-a402b9e2b04d");
UUID.nameUUIDFromBytes("身份证号码".getBytes());
  • randomUUID() 随机获取一个UUID,有极小的概率会重复
  • fromString() 根据一个符合UUID格式的字符串获取,不常用,我都有了还获取干嘛。
  • nameUUIDFromBytes() 根据一个字节数组获取,一般要求给定的字节数组不重复

3、方法介绍

UUID类的方法好像是所有底层源码中方法最少的了吧,下面就简单介绍一下。
Java中的UUID简单介绍_第1张图片

UUID uuid = UUID.randomUUID();
System.out.println("uuid.toString() = " + uuid.toString());
System.out.println("uuid.version() = " + uuid.version());  //版本号,下面会详细介绍
System.out.println("uuid.variant() = " + uuid.variant());  //还没搞清楚

结果如下

uuid.toString() = c68c4ead-e494-40be-a276-d5b5ef4b2c01
uuid.version() = 4
uuid.variant() = 2

UUID uuid = UUID.randomUUID();
System.out.println("uuid.timestamp() = " + uuid.timestamp());
System.out.println("uuid.clockSequence() = " + uuid.clockSequence());

还可以获取时间戳,这uuid有点强啊,结果如下:
Java中的UUID简单介绍_第2张图片
纳尼?为什么会报Not a time-based UUID错误呢。
错误提示这不是一个基于时间的uuid,也就是说这个uuid不是基于时间戳生成的。
看一下源码,这个错误是怎么产生的。
Java中的UUID简单介绍_第3张图片

4、UUID的版本介绍

又有问题出来了,uuid还有版本?还真有!那这些不同版本的uuid又有什么区别呢?

UUID Version 1:基于时间的UUID基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址,这个版本的UUID可以保证在全球范围的唯一性。但与此同时,使用MAC地址会带来安全性问题,这就是这个版本UUID受到批评的地方。如果应用只是在局域网中使用,也可以使用退化的算法,以IP地址来代替MAC地址--Java的UUID往往是这样实现的(当然也考虑了获取MAC的难度)。

UUID Version 2:DCE安全的UUIDDCE(Distributed Computing Environment)安全的UUID和基于时间的UUID算法相同,但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。

UUID Version 3:基于名字的UUID(MD5)基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了:相同名字空间中不同名字生成的UUID的唯一性;不同名字空间中的UUID的唯一性;相同名字空间中相同名字的UUID重复生成是相同的。

UUID Version 4:随机UUID根据随机数,或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的,但随机的东西就像是买彩票:你指望它发财是不可能的,但狗屎运通常会在不经意中到来。

UUID Version 5:基于名字的UUID(SHA1)和版本3的UUID算法类似,只是散列值计算使用SHA1(Secure Hash Algorithm 1)算法。
UUID的应用从UUID的不同版本可以看出,Version 1/2适合应用于分布式计算环境下,具有高度的唯一性;Version 3/5适合于一定范围内名字唯一,且需要或可能会重复生成UUID的环境下;至于Version 4,个人的建议是最好不用(虽然它是最简单最方便的)。通常我们建议使用UUID来标识对象或持久化数据,但以下情况最好不使用UUID: 映射类型的对象。比如只有代码及名称的代码表。 人工维护的非系统生成对象。比如系统中的部分基础数据。对于具有名称不可重复的自然特性的对象,最好使用Version 3/5的UUID。比如系统中的用户。如果用户的UUID是Version 1的,如果你不小心删除了再重建用户,你会发现人还是那个人,用户已经不是那个用户了。(虽然标记为删除状态也是一种解决方案,但会带来实现上的复杂性。)

看到了吧。使用UUID.randomUUID()获取的uuid是不带时间戳信息的。
那么怎么获取带时间戳信息的uuid呢?

5、获取带时间戳信息的uuid

就是通过一个给定uuid来获取,有点鸡肋。

UUID.fromString("095c64fe-c5bf-11ea-aec6-a402b9e2b04d");

上面也说了,这个版本1有个不安全的地方,那就是会暴露机器的Mac地址。为了写个教程我也是拼了。怎么验证呢?

ipconfig/all

Java中的UUID简单介绍_第4张图片
上面哪个uuid是通过python获取的,可以看到人家python支持指定版本。
Java中的UUID简单介绍_第5张图片
重新获取时间戳

System.out.println("uuid.timestamp() = " + uuid.timestamp());
System.out.println("uuid.clockSequence() = " + uuid.clockSequence());

结果如下:

uuid.timestamp() = 138140162874696958
uuid.clockSequence() = 11974

这个时间戳是个啥?咋这么长呢?
对比我们用Java的System.currentTimeMillis()获取以下时间戳,对比一下长度。

138140162874696958 ------>18位
1594724368033 --------------->13位

还得反底层源码,看看timestamp()的解释。
Java中的UUID简单介绍_第6张图片
两个关键点

  • 获得的是纳秒级别的
  • 时间并不是从1970年开始的

拓展一下1582年的10月是个一个特殊的月份。可以看到少了10天。具体原因自行百度把。
Java中的UUID简单介绍_第7张图片

6、把UUID的时间戳转换

怎么把这个时间戳转成具体的我们能看懂的时间日期呢?
公式如下:
uuid.timestamp()—1970到1582年这段时间的时间差

//把uuid的时间戳转成可以识别的时间戳
LocalDateTime localDateTime = LocalDateTime.ofEpochSecond(138140162874696958L - 0x01b21dd213814000L, 0, ZoneOffset.ofHours(8));
System.out.println("localDateTime.now() = " + localDateTime.now());

结果如下:

localDateTime.now() = 2020-07-14T19:10:11.253202

你可能感兴趣的:(Java)