Java中UUID类的作用和使用方法

UUID能保证全局唯一性是因为其128位空间极大，随机生成时碰撞概率极低；Java中通过UUID.randomUUID()生成Version 4的UUID，适用于分布式系统、数据合并、离线操作等场景，避免ID冲突且无需中心化协调。

Java中的

UUID

UUID

解决方案

使用

java.util.UUID

UUID.randomUUID()

import java.util.UUID;

public class UuidExample {
    public static void main(String[] args) {
        // 生成一个随机UUID
        UUID uuid = UUID.randomUUID();
        System.out.println("生成的UUID: " + uuid.toString());

        // UUID的字符串形式通常是32个十六进制数字，由连字符分隔成五组
        // 例如：a1b2c3d4-e5f6-7890-abcd-ef1234567890

        // 从字符串解析UUID
        String uuidString = "a1b2c3d4-e5f6-7890-abcd-ef1234567890";
        try {
            UUID parsedUuid = UUID.fromString(uuidString);
            System.out.println("解析的UUID: " + parsedUuid);
        } catch (IllegalArgumentException e) {
            System.err.println("无效的UUID字符串: " + e.getMessage());
        }

        // 获取UUID的组成部分（高64位和低64位）
        System.out.println("UUID的高64位: " + uuid.getMostSignificantBits());
        System.out.println("UUID的低64位: " + uuid.getLeastSignificantBits());
    }
}

除了

randomUUID()

UUID

nameUUIDFromBytes(byte[] name)

UUID为什么能保证全局唯一性？它的实现原理是什么？

谈到UUID的全局唯一性，这其实是一个概率问题，而不是绝对的数学保证。但这个概率低到我们几乎可以忽略不计。一个UUID是128位的数字，这意味着它能表示的数量是2的128次方，这是一个天文数字。为了有个概念，地球上的沙子数量可能都比这个少得多。

立即学习“Java免费学习笔记（深入）”；

具体到实现原理，我们通常说的“随机UUID”（Version 4）是基于纯粹的随机数。它的128位中有122位是完全随机生成的，另外6位则用于指示版本和变体。因为随机数生成器的质量足够高，且可用的随机数空间极大，所以两个随机生成的UUID发生碰撞的可能性微乎其微。在我看来，这种“几乎不可能碰撞”的特性，在绝大多数分布式场景下，已经足够支撑其作为全局唯一标识符的职责了。

法语写作助手

法语助手旗下的AI智能写作平台，支持语法、拼写自动纠错，一键改写、润色你的法语作文。

31

查看详情

当然，还有基于时间戳和MAC地址的UUID（Version 1），它利用了当前时间、序列号和网卡MAC地址的组合来保证唯一性。这种方式的优点是可以在一定程度上保证生成顺序，但缺点是可能会暴露生成UUID的机器信息，而且如果时钟回拨或MAC地址冲突，理论上也有小概率冲突。不过，在现代应用中，Version 4因其简单和极低的碰撞率，往往是更受欢迎的选择。

在实际开发中，什么时候应该优先考虑使用UUID作为主键？

我个人觉得，在以下几种场景下，使用UUID作为数据库主键会是一个非常明智的选择：

1. 分布式系统和微服务架构： 这是UUID最闪耀的舞台。在多个服务或数据库实例并行运行的环境中，如果每个服务都自己生成主键，使用数据库自增ID很容易导致冲突。UUID天生就具备分布式生成的特性，每个节点都可以独立生成，无需协调，大大简化了架构。
2. 数据合并或迁移： 当你需要将来自不同数据库或系统的数据合并到一个新的数据库时，如果原系统都使用自增ID，那么合并时就会出现ID冲突。而如果都使用UUID，则可以直接导入，省去了复杂的ID映射和转换工作。
3. 离线操作和数据同步： 想象一下移动应用或桌面客户端，它们可能在没有网络连接的情况下创建数据。如果使用自增ID，就无法预先生成主键。UUID允许客户端在离线状态下就生成唯一标识，待网络恢复后直接同步到服务器，避免了额外的ID回填逻辑。
4. 避免暴露业务数据量： 数据库的自增ID往往能直接反映出某个表有多少条记录，这在某些情况下可能被视为敏感信息。UUID则是一串无规律的字符串，无法推断出任何关于数据量的线索。

当然，使用UUID作为主键也有其代价，比如它通常是字符串类型，占用存储空间更大，索引效率可能略低于整型主键，且由于其随机性，可能会导致数据库的B-tree索引页分裂，影响查询性能。所以，做选择时总要权衡利弊，看业务需求更侧重哪方面。

除了作为主键，UUID在Java中还有哪些不为人知的妙用？

除了作为数据库主键，UUID的用武之地远不止这些，有些场景可能不那么显眼，但同样实用：

1. 生成唯一的会话ID或令牌： 在Web应用中，为每个用户会话或授权令牌生成一个UUID，可以作为其唯一的标识符。这比简单的时间戳或递增数字更安全，也更难猜测。
2. 作为临时文件名或目录名： 当你需要上传文件到服务器，或者在本地创建临时文件时，直接使用

   UUID.randomUUID().toString()

   登录后复制
   作为文件名，可以有效避免文件名冲突，尤其是在多用户并发上传或者系统自动生成临时文件时。
3. 日志追踪ID： 在复杂的分布式系统中，一个请求可能会跨越多个服务。在请求进入系统时生成一个UUID作为“请求ID”或“链路追踪ID”，并在日志中打印出来，可以帮助我们串联起整个请求链条的日志，方便问题排查。
4. 事件标识符： 在事件驱动架构中，每个发布的事件都可以带上一个UUID作为其唯一标识符。这对于事件去重、保证幂等性，或者后续对事件的追踪和审计都非常关键。
5. 缓存键： 有时候我们需要为缓存中的数据生成一个唯一的键，尤其当数据本身没有一个天然的唯一标识时，UUID就能派上用场。

我觉得，UUID的强大之处在于它提供了一种无需中心协调就能保证“足够唯一”的能力。这使得开发者在设计系统时可以更加自由和灵活，减少了对集中式服务的依赖，从而提升了系统的可伸缩性和韧性。它就像一把万能钥匙，在很多需要“独一无二”的场景下，总能找到它的位置。

以上就是Java中UUID类的作用和使用方法的详细内容，更多请关注php中文网其它相关文章！