Java中的UUID简单介绍
1、UUID的格式
xxxxxxxx—xxxx—xxxx—xxxx—xxxxxxxxxxxx
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类的方法好像是所有底层源码中方法最少的了吧，下面就简单介绍一下。
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有点强啊，结果如下：
纳尼？为什么会报Not a time-based UUID错误呢。
错误提示这不是一个基于时间的uuid，也就是说这个uuid不是基于时间戳生成的。
看一下源码，这个错误是怎么产生的。
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
上面哪个uuid是通过python获取的，可以看到人家python支持指定版本。
重新获取时间戳
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()的解释。
两个关键点
- 获得的是纳秒级别的
- 时间并不是从1970年开始的
拓展一下1582年的10月是个一个特殊的月份。可以看到少了10天。具体原因自行百度把。
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