UUID.randomUUID() 慢是因为依赖 SecureRandom 访问 /dev/random 或 /dev/urandom，引发 I/O 和熵池延迟，且高并发下存在锁争用；JDK 9+ 优化分段锁但仍比纯内存计算慢 10–100 倍。
UUID.randomUUID() 为什么慢？底层到底在做什么
UUID.randomUUID() 每次调用都会触发一次 SecureRandom 实例的初始化（首次）或重取随机数，而 SecureRandom 在 Linux 上默认依赖 /dev/random 或 /dev/urandom —— 前者可能阻塞，后者虽不阻塞但仍有系统调用开销。这不是“算法慢”，是 I/O 和熵池访问带来的延迟。
- 高并发下频繁调用
UUID.randomUUID()可能引发线程争用SecureRandom内部锁（JDK 8 及以前尤其明显） - JDK 9+ 对
SecureRandom做了分段锁优化，但单次生成仍比纯内存计算慢 10–100 倍 - 如果你只需要“业务唯一”而非“密码学安全”，它大概率是过度设计
不用 randomUUID() 的三种替代方案
真正影响性能的是“要不要密码学强度”，而不是“要不要 UUID”。明确场景后，可选更轻量的方式：
- 时间戳 + 进程 ID + 序列号：适合单机、短生命周期服务，用
System.nanoTime()和AtomicLong拼接，无锁且纳秒级 - 基于
ThreadLocalRandom的变种：避免全局SecureRandom竞争，ThreadLocalRandom.current().nextLong()配合机器标识拼成 128 位，速度提升 5–8 倍 - 使用
UUID.nameUUIDFromBytes(byte[])：传入稳定输入（如用户 ID + 时间戳），结果确定性可复现，适合幂等场景；注意字节数组不能为 null，否则抛NullPointerException
String.valueOf(uuid) 和 uuid.toString() 性能差多少
两者都生成标准 32 字符 + 4 连字符格式（如 550e8400-e29b-41d4-a716-446655440000），但实现路径不同：
-
uuid.toString()是UUID类的重写方法，直接操作内部两个long字段，无对象分配 -
String.valueOf(uuid)先触发uuid.toString()，再走通用String.valueOf(Object)分支，多一层判空和类型检查 —— 实测 JDK 17 下慢约 3% - 高频日志或序列化场景中，直接用
uuid.toString()更稳妥；若已存在泛型逻辑依赖String.valueOf，不必强改
UUID 作为数据库主键时的隐性成本
很多人只关注生成快慢，却忽略存储和索引层面的连锁反应：
立即学习“Java免费学习笔记（深入）”；
- UUID 是 16 字节二进制，但多数人存为
VARCHAR(36)，实际占 36 字节 + 字符集开销（UTF-8 下可能达 108 字节） - MySQL 中用
BINARY(16)存储需配合UNHEX(REPLACE(uuid, '-', ''))写入，读取时用HEX()转回字符串 —— 不做转换就查不到 - PostgreSQL 支持原生
UUID类型，但默认 B-tree 索引对随机 UUID 散布敏感，页分裂多；可考虑pgcrypto的gen_random_uuid()（依赖扩展）或改用time-basedUUIDv1
真正难的不是生成一个“唯一 ID”，而是让这个 ID 在整个数据链路里不拖慢写入、不撑爆索引、不增加序列化负担。很多团队卡在这一步，不是因为不会写 UUID.randomUUID()，而是没往下看两层。
