如何使用Java生成UUID标识 Java创建唯一ID的方式-java教程-PHP中文网

如何使用Java生成UUID标识 Java创建唯一ID的方式

爱谁谁

发布： 2025-07-21 17:42:02

原创

822人浏览过

在java中生成唯一id最推荐使用java.util.uuid类，它能生成128位全球唯一的标识符，适用于分布式系统和数据存储场景；生成uuid只需调用uuid.randomuuid().tostring()方法，若需去除横杠可使用replace方法处理；uuid版本4基于强随机数生成，冲突概率极低，满足绝大多数唯一性需求；除此之外，还有数据库自增id、雪花算法、短id生成、预生成id池等方案，各自适用于不同场景，如单体应用、分布式系统、对长度敏感的场景及高并发环境；选择唯一id方案需综合考量唯一性、性能、存储效率、业务需求和系统架构，避免uuid主键导致的数据库性能问题、雪花算法的时钟依赖、短id的冲突风险及不必要的过度设计。

如何使用Java生成UUID标识 Java创建唯一ID的方式

Java中生成唯一ID，最直接、最推荐的方式就是使用java.util.UUID类。它能提供一个全球唯一的128位标识符，几乎可以保证不重复，是分布式系统和数据存储中非常常用的解决方案。

解决方案

使用java.util.UUID类生成一个随机的UUID非常简单，只需要一行代码。

import java.util.UUID;

public class UniqueIdGenerator {

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

        // 如果需要去除横杠，可以这样处理
        String uuidWithoutHyphens = uuid.replace("-", "");
        System.out.println("去除横杠的UUID: " + uuidWithoutHyphens);
    }

    /**
     * 获取一个不带横杠的UUID字符串
     * @return 不带横杠的UUID字符串
     */
    public static String generateSimpleUUID() {
        return UUID.randomUUID().toString().replace("-", "");
    }
}

登录后复制

UUID.randomUUID()方法会生成一个基于加密强随机数生成器（CSPRNG）的UUID，属于版本4（基于随机数）的UUID。这种方式的优点是简单、无需任何外部依赖，且冲突概率极低，足以满足绝大多数应用场景的唯一性需求。

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

为什么我们需要唯一ID？UUID的内在机制是怎样的？

在现代软件开发里，唯一ID的需求几乎无处不在。你想想看，数据库里的主键、分布式系统里的请求追踪、用户会话标识、甚至文件命名，都需要一个独一无二的标识符来区分。尤其是在微服务架构下，服务之间的数据流转、日志聚合，如果ID不唯一，那简直是一场灾难。我个人在处理线上问题时，一个全局唯一的请求ID简直是排查利器，能大幅提升定位问题的效率。

UUID，全称是Universally Unique Identifier，通用唯一标识符。它是一个128位的数字，通常以32个十六进制数字的形式表示，并用连字符分隔成五组，例如550e8400-e29b-41d4-a716-446655440000。它的设计目标就是为了在分布式计算环境中保证唯一性，而无需中央协调机构。

UUID有几个版本，java.util.UUID.randomUUID()生成的是版本4的UUID。版本4的UUID完全是基于随机数生成的。它的128位中，有122位是随机或伪随机数，剩下的6位用于表示版本和变体信息。正是这巨大的随机数空间，使得两个UUID碰撞的概率变得微乎其微。具体来说，要生成十亿个UUID，发生一次碰撞的概率大约是10的-18次方，这比你被雷劈中两次的概率还要低得多。所以，在实际应用中，你可以放心地认为它就是唯一的。

快标书AI

10分钟生成投标方案

241

查看详情

除了版本4，还有版本1（基于时间戳和MAC地址），版本3和版本5（基于命名空间和哈希值）。但对于我们日常需要一个“随便什么唯一ID”的场景，版本4无疑是最简单、最常用的。

除了UUID，Java还有哪些生成唯一ID的策略？各自的优缺点是什么？

说实话，UUID虽然好用，但它并不是万能的，也不是唯一的选择。在不同的业务场景和系统架构下，我们可能会考虑其他生成唯一ID的方式。

1. 数据库自增ID 这是最常见、最传统的方式。比如MySQL的AUTO_INCREMENT。

优点： 实现简单，ID天然有序，对单体应用或单库单表非常友好，查询效率高。
缺点： 在分布式系统中，跨库跨表生成唯一ID会变得非常复杂，需要引入额外的ID生成服务或分库分表策略。同时，ID的递增性可能会暴露业务量信息，并且在并发写入非常高的情况下，可能成为性能瓶颈。

2. 雪花算法（Snowflake） 由Twitter开源的一种分布式ID生成算法。它生成的ID是一个64位的长整型数字。

优点： 可以在分布式环境下生成趋势递增的唯一ID，且生成速度非常快，每秒可生成数百万个。ID是长整型，占用空间小，且由于是趋势递增，在作为数据库主键时，对InnoDB等存储引擎的写入性能更友好（减少索引碎片）。
缺点： 算法实现相对复杂一些，需要分配机器ID和数据中心ID，并且对系统时钟有依赖，如果时钟回拨可能会导致ID重复（尽管有策略可以避免）。

3. 短ID或自定义ID生成策略 有些场景下，UUID太长了，比如作为短链接的标识，或者需要一个更“美观”的ID。

基于UUID的短ID： 可以将UUID进行Base64编码，或者截取部分，但这样会牺牲一部分唯一性，需要评估冲突风险。
时间戳 + 随机数 + 业务前缀： 结合当前纳秒级时间戳，加上一小段随机数，再根据业务需求加上前缀。这种方式的唯一性不如UUID，但对于一些局部唯一且对长度有要求的场景，可以作为补充。我曾在一个小项目里用过System.nanoTime() + Random.nextInt()，但这种只适合非常局部的，且对唯一性要求不那么极致的场景，因为纳秒时间戳在高并发下可能重复，随机数空间也有限。

4. 预生成ID池 在一些极端高并发的场景，为了避免实时生成ID的开销，可以提前生成一批ID，放入内存队列或缓存中，用的时候直接取。

优点： 极高的生成速度，低延迟。
缺点： 增加了系统的复杂性，需要考虑ID池的填充、持久化和容错，以及ID的消耗速度和预生成数量的平衡。

在实际项目中，如何选择合适的唯一ID生成方案？有哪些常见的坑？

选择合适的唯一ID生成方案，真的没有“一刀切”的答案，它更像是一个权衡和取舍的过程。你需要根据项目的具体需求、系统架构、性能瓶颈和未来扩展性来综合考虑。

选择考量点：

唯一性要求： 是需要全球唯一（如订单号），还是局部唯一（如某个批次内的文件ID）？如果需要全球唯一，UUID或雪花算法是首选。
性能要求： 每秒需要生成多少个ID？生成速度是否是瓶颈？雪花算法在这方面表现优异，UUID也足够快。
存储和传输效率： ID的长度和类型（字符串、长整型）会影响数据库存储空间、索引效率以及网络传输。UUID是字符串，相对较长；雪花算法是长整型，更紧凑。
业务需求： ID是否需要具备某种业务含义（比如包含时间信息），或者是否需要排序？如果需要趋势递增，雪花算法或数据库自增ID更合适。如果ID不希望暴露任何业务信息，随机的UUID更佳。
系统架构： 单体应用可能数据库自增ID就够了。分布式系统则必须考虑分布式ID生成方案。

常见的坑：

UUID做数据库主键的性能问题： 这是一个老生常谈的问题。虽然UUID保证唯一性，但它的随机性导致插入数据时，数据库（特别是MySQL的InnoDB存储引擎）的B+树索引会频繁分裂和合并，导致插入性能下降，并且查询时缓存命中率低。如果你的表写入非常频繁，且UUID作为主键，你可能会遇到性能瓶颈。一个常见的优化是，如果非要用UUID做主键，可以考虑将其转换为二进制存储（减少空间），或者使用“有序UUID”（如UUIDv1或通过一定算法将随机UUID的某些部分有序化，例如COMB GUIDs），但这些都增加了复杂度。
雪花算法的时钟回拨： 雪花算法依赖系统时钟。如果服务器时间发生回拨，可能会生成重复的ID。虽然可以通过记录上次生成ID的时间戳并拒绝生成，或者等待时间追上来等策略来缓解，但这增加了算法的复杂性。
短ID的冲突风险： 为了追求ID的短小，有时会牺牲唯一性。比如，对UUID进行Base64编码后，虽然短了，但冲突概率会上升。如果你的业务对唯一性要求极高，不要轻易为了“短”而牺牲“唯一”。
过度设计： 对于一个简单的单体应用，可能数据库自增ID或者UUID.randomUUID()就完全足够了。没必要为了“高大上”而引入复杂的分布式ID生成服务，那只会增加维护成本。
业务ID与技术ID混淆： 有时候，业务上可能需要一个“唯一编号”（比如订单号、流水号），它可能包含业务逻辑，且需要用户友好。这种“业务ID”和我们这里讨论的“技术唯一ID”（用于数据库主键、内部关联等）是两回事。不要把技术ID直接暴露为业务ID，反之亦然。