April - 2024 - 开发工具分享

CWIKIUS.CN

一个有独立思考和温度的清新站

概述在本文中，我们将会对 UUIDs 和基于时间的 UUIDs（time-based UUIDs）进行一些探讨。当我们在对基于时间的 UUIDs 进行选择的时候，总会遇到一些好的方面和不好的方面，如何进行选择，也是我们将要简要探讨的内容。同时我们还会对可能会使用类库进行一些比较和探索，以便于我们更好的做出选择。 UUIDs 和基于时间的 UUIDs UUID 的全称是 Universally Unique Identifier，中文为通用唯一识别码。当生成 UUID 的时候，系统总会自动生成一个 128 位的 UUID。基于 UUID 的生产算法的不同，我们会有不同的版本。 UUID 的主要目的就是用来在全世界中唯一标识一个数据，而且需要保证生成的 UUID 在全世界范围内是不重复的。因此我们可以用来标识一个上下文，包括数据库系统，计算机系统中的消息，分布式系统中的对象等等。为了实现这个目标，我们需要确保哪怕是在同一个时间瞬间生成的 UUID 也是不相同，这样能够让我们更好的利用 UUID 在分布式计算机系统中标识存在的对象。基于时间的 UUID，通过字面就可以了解到，这个 UUID 是基于时间的，实际上这个 UUID 存在 UUID 设计中的第一版。这个版本是基于随机数的，使用的基数为每 100 纳秒为一个单位，时间的起点为1582年10月15日。同时还需要加上当前计算机的网卡物理地址（MAC）。在后续的版本中，UUID （v6 和 v7）也是基于时间的 UUID 生成算法，可以说是基于 UUID v1 的更新版本。 UUID v1 因为是基于时间的，所以具有排序功能，这个在对数据库的设计上就很有帮助，当我们使用 UUID v1 来作为 PK（主键）的时候，我们就知道了，我们创建的这条记录的时间戳是什么时候，这个对我们在对数据进行调试和问题分析的时候就很有帮助了。有优势就自然会有劣势，因为我们是基于时间创建 UUID 的，那么在同一个系统产生 UUID 冲突的可能性就会大很多，假设在同一个时间点，我们创建了很多个 UUID，那么大概率就会有出现冲突，重复出现的情况。在本文的后部分，我们会对这个可能出现的情况进行一些探索。另外一个原因，就是在 UUID v1 版本中使用主机地址这种做法会潜在的增加系统的安全性问题。这就是 UUID v6 尝试希望解决的问题。对比程序为了对可能出现的 UUID 冲突进行演示。我们尝试使用程序来对比可能出现 UUID 冲突的可能性。这个程序，将会创建 128 个线程，在每个线程中将会生成 100,000 个 UUID。首先我们对需要使用的变量来进行一些初始化： int threadCount = 128; int iterationCount = 100_000; Map<UUID, Long> uuidMap = new ConcurrentHashMap<>(); AtomicLong collisionCount = new AtomicLong(); long startNanos = System.nanoTime(); CountDownLatch endLatch = new CountDownLatch(threadCount); 如上面的程序所表示的内容，我们定义了 128 个线程，在这 128 个线程中，我们会循环 100,000 次。同时，我们还初始化了一个 ConcurentHashMap 把我们生成的 UUID 存储到 ConcurentHashMap 中。同时，我们还会记录出现 UUID 冲突的次数。为了记录程序的性能，我们对程序开始时间和程序的结束也都进行了存储。在最后我们定义了一个 latch 等待所有线程的执行完成。当定义完成后变量后，我们就需要启动线程并对线程序进行执行。 for (long i = 0; i < threadCount; i++) { long threadId = i; new Thread(() -> { for (long j = 0; j < iterationCount; j++) { UUID uuid = Generators.timeBasedGenerator().generate(); Long existingUUID = uuidMap.put(uuid, (threadId * iterationCount) + j); if(existingUUID != null) { collisionCount.incrementAndGet(); } } endLatch.countDown(); }).start(); } 在 UUID 的创建过程中，我们使用了 fasterxml 包中的 Generators，这个 Generators 使用的是 java.util.UUID 类来创建的。在创建 UUID v1 的使用，使用 fasterxml 是我们常用的做法。当 UUID 创建后，我们就把创建好的 UUID 存储到 Map 中，UUID 为 map 的 Key，当我们的 UUID 重复出现冲突的时候，Map 将会提示错误，我们程序就会捕获这个错误，然后把出现错误的计数器 + 1。 endLatch.await(); System.out.println(threadCount * iterationCount + " UUIDs generated, " + collisionCount + " collisions in " + TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startNanos) + "ms"); 在程序的最后，CountDownLatch 的 await() 方法会等待所有的线程完成。当所有线程完成后，我们就会把结果打印在计算机屏幕上。下面就让我们开始对程序进行运行。 12800000 UUIDs generated, 0 collisions in 16913ms 上面出现了程序的运行结果，我们可以看到并没有出现…

概述使用 Base64 编码来对 UUID（Universally Unique Identifiers）存储在一些特定的场合被广泛的使用。使用 Base64 对比直接使用 UUID 进行存储来说能够更多的节约空间。本文对这方面的相关内容和问题进行探讨。在这里，使用 Base64 来对 UUID 进行存储，涉及到一些类型的转换的。Base64 是编码算法，在实际使用的时候我们更多会用到 Byte 数组的方式来进行编码的。这样我们就比较明确在对其进行 Base64 转换之前，我们应该要先干什么了。使用 byte[] 和 Base64.Encoder Base64.Encoder 就能够提供 byte[] 的 Base64 编码了，我们先使用这个最简单的方式来进行处理。编码首先我们需要给出的 UUID 位中创建出我们需要的 byte 数组。我们先获得 UUID 的 most significant bits 和 least significant bits，然后放入我们 byte 数组中的 0-7 和 8-15 的位置。程序代码如下： private byte[] convertToByteArray(UUID uuid) { byte[] result = new byte[16]; long mostSignificantBits = uuid.getMostSignificantBits(); fillByteArray(0, 8, result, mostSignificantBits); long leastSignificantBits = uuid.getLeastSignificantBits(); fillByteArray(8, 16, result, leastSignificantBits); return result; } 上面的代码中还有一个 fillByteArray 方法，这个方法，这个方法将会把我们的 bit 存如 byte array 数组中，同时还会移动 8 位。方法的代码如下： void fillByteArray(int start, int end, byte[] result, long bits) { for (int i = start; i < end; i++) { int shift = i * 8; result[i] = (byte) ((int) (255L & bits >> shift)); } } 当我们获得 byte 数组后，我们就可以调用 JDK 的 Base64.Encoder 方法来直接进行编码了成一个 Base64 加密字符串了。完整的测试代码如下： UUID originalUUID = UUID.fromString("cc5f93f7-8cf1-4a51-83c6-e740313a0c6c"); @Test void givenEncodedString_whenDecodingUsingBase64Decoder_thenGiveExpectedUUID() { String expectedEncodedString = "UUrxjPeTX8xsDDoxQOfGgw=="; byte[] uuidBytes = convertToByteArray(originalUUID); String encodedUUID = Base64.getEncoder().encodeToString(uuidBytes); assertEquals(expectedEncodedString, encodedUUID); } 解码把我们获得的 UUID Base64 字符串进行解码，我们可以使用完全相反的方法： @Test public void givenEncodedString_whenDecodingUsingBase64Decoder_thenGiveExpectedUUID() { String expectedEncodedString = "UUrxjPeTX8xsDDoxQOfGgw=="; byte[] decodedBytes = Base64.getDecoder().decode(expectedEncodedString); UUID uuid = convertToUUID(decodedBytes); } 首先把 Base64 字符串解码成 Byte 数组，然后调用我们的转换方法，把我们获得 byte 数组转换成为 UUID 对象。 UUID convertToUUID(byte[] src) { long mostSignificantBits = convertBytesToLong(src, 0); long leastSignificantBits = convertBytesToLong(src, 8); return new UUID(mostSignificantBits, leastSignificantBits); } 在上面的方法中，我们分别对 UUID 中需要使用的 most significant bits 和 less significant bits 分别进行转换，然后再组合在一起。转换的方法如下： long convertBytesToLong(byte[] uuidBytes, int start) { long result = 0; for(int i = 0; i < 8; i++) { int shift = i * 8; long bits = (255L & (long)uuidBytes[i + start]) <<…

getMostSignificantBits() 方法的一些介绍： getMostSignificantBits 这个方法主要用于在 UUID 中获取高64 位的有效位后返回 Long 数据类型。在获取最高有效位时不会引发异常。对应的还有一个 getLeastSignificantBits() 方法。这个方式是从 UUID 中获取低 64 位的有效位返回 Long数据类型。如查看 UUID 的数据结构，我们能看到 UUID 是拆分 2 部分的。 https://www.isharkfly.com/t/java-uuid-getmostsignificantbits-leastsignificantbits/15683

UUID 是有多个版本的，如何查看 UUID 是那个版本，可以用 UUID 对象中的 version() 方法。创建 UUID 对象： UID originalUUID = UUID.fromString("cc5f93f7-8cf1-4a51-83c6-e740313a0c6c"); uuid.version(); 上面方法显示 UUID 的版本为 4。 Version 4 （基于随机数） UUID-v4 组成 UUID v4 的位是随机生成的，没有固有逻辑（除了第三段首个数字，该数字标识版本号），不包含命名空间、设备信息、时间信息。故，UUID-v4 最容易理解、应用也最为广泛。 https://www.isharkfly.com/t/uuid/15684

概述在本文中，我们将会对 Java 特性预览背后的动机进行一些探索，对比当前使用 Java 的版本提供了哪些实验性的功能，以及如何在不同的 IDE 工具中启用这个功能。为什么使用特性预览如你对 Java 版本的发行计划不太熟悉的话，那么需要了解的是 Java 目前是每 6 个月将会发行一个版本。在发行新的版本的时候会提供一些新的特性。 Java 特性预览这个功能，将能够让用户提前了解一些 Java 将会在新版本中使用的功能，同时也能让 Java 团队能够更多的获得用户的反馈意见。我们都知道 Java 被在很多大中小系统中使用，哪怕是实现中的一点点瑕疵或者糟糕的糟糕的设计都会带来很多意想不到情况和损失。又因 Java 系统的广泛应用，这种损失通常是非常巨大的。如何能够确保每一个发行的 Java 版本能够稳定的发布和升级，同时也能够满足 Java 社区的需要就成了一个问题。针对 JEP-12 的改进，Java 提供了针对 VM（虚拟机）和语言特性的预览功能。通过这种方式 Java 社区能够在环境中直接测试新的功能，同时这些功能也不会影响到服务器的开发和使用。 Java 团队会基于社区中的反馈而对预览的功能会进行一些调整，同时会针对后续的发行版本而对提供的新的特性进行多次修改。在最后，新特性可能会成为官方正式的发布版本，当然提供的一些新特性可能会在后续的官方正式发布版本中被完全的删除。预览一些实验性特性 Java 的预览特性是针对正在开发中的特性，并且这些特性还在接受评估。所以这些特性还没有完全确定，所以很多特性可能会在新的发行版本中出现，当然很多也可能会被完全抛弃。正是因为 Java 对品质的要求，针对 JDK 的不版本的实现，都会要求在 JDK 发布的时候同时也包含有实验性的特性预览。但是，针对最后的发布版本，这种实验性的预览功能是不会提供的。特性预览只是让 Java 社区提前知道 Java 团队目前正在干什么和计划要干什么的一种方式。需要明确的是，不要把这些可能还会删掉的特性和功能包含到你的发行版本中。下面是 JEP-12 有关预览特性的定义，官方的链接地址在：https://openjdk.org/jeps/12。如你有兴趣的话，可以直接阅读官方的原文。使用预览特性 Java 预览特性在默认情况下是关闭的。为了启用这个功能，我们必须使用启用预览参数，使用这个参数将会把所有的特性一次性全部启用。 Java 编译器（JVM）和 Java 的版本必须保持一致。让我们来尝试使用 JDK 13 中提供的 String 字符串块功能。 String query = """ SELECT 'Hello World' FROM DUAL; """; System.out.println(query); 上面的功能只能够在 JDK 13 及其后续版本中使用，所以为了使用这个功能，你需要安装 JDK 13 到你的计算机中。使用 Eclipse 如果拷贝上面的代码到 Eclipse 中，你的 Eclipse 是不会进行进行正确编译的，在编译的过程中将会提示代码错误。提示的内容是：如果需要这个功能请使用 JDK 13 的 String 字符串块功能。这个时候，我们在我们的项目中单击右键，然后在弹出的菜单中选择属性。然后进入到 Java 编辑器，这个时候我们就可以为我们的这个项目或者整个 Workspace 启用预览特性。同时，我们还不能选择使用默认编译器设置（Use default compliance settings）这个选项，这样可以让我们能够对 Java 13 的特性进行预览。因目前我们使用的编译器版本比较高，为 JDK 17 的版本，所以在预览选项这里就只能对 JDK 21 的版本进行预览了。 IntelliJ IDEA 针对使用不同的 IDE，我们也希望我们的预览功能能够在 IDEA 中也可以使用。与 Eclipse 相同，IDEA 也有这个方面的配置，你只需要在 IDEA 中修改配置即可。配置是在语言结构上。单击语言结构上的 SDK 默认，往下拉，就可以看到针对新版本的选项。同时还可以看到那些版本是支持新特性预览的，那些版本是不支持新特性预览的。整体来说，IntelliJ IDEA 的新特性预览功能做得要比 Eclipse 更好一些。 Maven 针对 Maven 项目，因 Maven 项目的配置都会依赖 pom.xml 来进行，对 IDE 的修改，可能在某些时候没有效果。如果是这个情况的话，那你需要打开你的 pom.xml 文件，在 pom.xml 文件中找到针对编译有关的插件配置，然后再插件配置中添加 compilerArgs 参数。具体的示例如下： <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>13</source> <target>13</target> <compilerArgs> --enable-preview </compilerArgs> </configuration> </plugin> </plugins> </build> 针对上面的修改，同样也能让你的 IDE 能够识别到。使用命令行在编译期间，Java 有 2 个参数来控制启用预览的功能，请参考下面的编译命令： javac --release 13 --enable-preview ClassUsingTextBlocks.java 如果当前使用的 JDK 版本是不支持的预览功能的，那么使用上面的命令将会得到错误的提示。例如 JDK 14 的版本是不支持预览的，在命令行中，如果我们把命令行的中的 13 替换成 14 的话，都那么编译器将会提示我们错误。在实际的开发环境中，在命令行中使用预览功能的可能性非常小，设置我们都不会使用命令行的方式来编译我们的 Java 代码。上面提出这种编译方式的目的就是告诉大家，我们还是有这个选项的，主要还是能够让大家了解我们是有这 2 个参数提供的。在运行时，Java 只需要 enable-preview 参数就可以启用预览功能。 java --enable-preview ClassUsingTextBlocks 需要注意的是，在这里如果你的 JDK 版本和预览的版本不匹配的话，你的程序是没有办法运行的。结论在本篇文章中我们主要针对 Java 提供的特性预览功能进行了一些讨论。在实际使用的时候，我们确实也会遇到一些，这些情况就是项目使用的 JDK 版本比较低，但是下载的 JDK 编译的 Jar 包版本又比较高，这就导致了无法编译的情况。我们会考虑使用 Java 的预览功能来查看下代码的兼容性。比如说，当前项目使用的 JDK 版本为 8，但是我们项目中的一个依赖却使用了 JDK 11 来编译了包，所以我们可能会把我们的编译器版本提升下到 JDK 11 来查看代码的兼容情况。如你只是针对自己的项目的话，Java 新特性功能用得就比较少，主要是对架构师而言，他们需要确定下代码的兼容性，以便于在对 JDK 是否可以进行升级上做出判断。 https://www.isharkfly.com/t/java/15682

如果你有学生账号，并且账号是 EDU 结尾的，可以申请 IDEA 的学生许可证。有效期一年，完全免费。在界面上输入邮件地址，然后单击按钮提交。邮件中单击链接 JetBrains 会把一个带有链接的邮件发送到你的邮箱中。单击邮箱中的链接，在下一个界面中输入邮箱地址和创建一个账号就可以了。进入新创建的账号，可以在账号页面中看到签发的许可证信息。直接登录账号激活可以在本地软件上直接登录账号。然后你的 IDEA 就已经激活使用了。 https://www.isharkfly.com/t/idea/15674

如 Eclipse 不配置的话，是没有办法编译 lombok 项目的。下载 Jar 如果你项目使用的是 maven，那么 jar 应该下载下来了。到 pom.xm 文件中找到有关 lombok 的依赖。 <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.32</version> <scope>provided</scope> </dependency> 运行命令然后在命令行中运行命令： java -jar lombok-1.18.32.jar lombok 将会打开右侧的界面。指定安装路径随后需要指定 Eclipse 的安装路径和文件。在这里，直接指向到 exe 文件即可。然后单击右侧的安装和更新。安装成功当安装成功后，Lombok 会在界面中提示安装成功。然后你的 Eclipse 会被刷新，如果没有刷新的话，重启下 Eclipse。至此有关 lombok 的错误就完成修改了。随后打开 Eclipse 编辑器，我们看到也没有问题了。 https://www.isharkfly.com/t/eclipse-lombok/15678

针对项目的新特性预览在 Java 的编译器中。单击左侧项目属性中的编译器，然后取消选择使用默认的编译设置。在下面就可以启用针对 Java 21 的新特性预览了。 JDK 针对你计算机中安装的发行版本不同，启用的预览版本也会不同。 https://www.isharkfly.com/t/eclipse/15679

在 Eclipse 的 Windows 菜单下选择属性。然后在 Maven 选项下，选择下载包的源代码和文档。保存应用即可。 https://www.isharkfly.com/t/eclipse-maven/15680

创建基于时间的 UUID

Java 中将 UUID 存储为 Base64 字符串

Java UUID 类中的 getMostSignificantBits 和 leastSignificantBits 方法

如何查看 UUID 是哪个版本

Java 特性预览

Java 特性预览

IDEA 申请学生许可证

Eclipse 安装 lombok 和配置

Eclipse 如何启用新特性预览

Eclipse 如何设置 Maven 下载源代码和文档