UUID.randomUUID()生成的版本4 UUID在实际场景中可视为全局唯一，因122位来自SecureRandom，碰撞概率极低（约2.7×10¹⁸个达50%），但非数学绝对唯一；需避免截断、误用nameUUIDFromBytes、存储截断及日志缩略等人为错误。
UUID.randomUUID() 生成的值在绝大多数实际场景下可视为全局唯一，但“不重复”不是绝对数学保证，而是基于概率极低的碰撞风险。
为什么 UUID.randomUUID() 通常不会重复
它生成的是版本 4（random-based）UUID，128 位中 122 位来自加密安全随机数（SecureRandom），理论碰撞概率需生成约 2.7×10¹⁸ 个才达 50%（生日悖论估算）。日常业务如订单号、消息 ID、数据库主键完全够用。
注意：UUID.randomUUID() 内部使用 SecureRandom，首次调用可能因熵池阻塞稍慢（尤其容器或虚拟机环境），后续调用无明显开销。
常见误用：把 UUID 当字符串直接拼接或截断
直接调用 toString() 得到形如 "f47ac10b-58cc-4372-a567-0e02b2c3d479" 的 36 字符字符串。有人为节省空间截取前 8 位（如 uuid.toString().substring(0, 8)），这彻底破坏唯一性——只剩 32 位，碰撞概率飙升。
立即学习“Java免费学习笔记（深入）”；
- 需要紧凑表示？用
uuid.toString().replace("-", "")得到 32 位十六进制字符串 - 存数据库？优先用
CHAR(36)或UUID类型（PostgreSQL/MySQL 8.0+ 支持） - 序列化传输？保持原样，不要 base64 编码后再解码——容易引入大小写/填充问题
线程安全与性能陷阱
UUID.randomUUID() 是线程安全的，但高并发下（如每秒数万次）可能因 SecureRandom 内部锁成为瓶颈。
- 确认是否真有性能问题：先压测，别预设瓶颈
- 若确实卡在
UUID.randomUUID()，可复用一个SecureRandom实例（但注意其非线程安全，需配合ThreadLocal） - 更简单方案：用
java.util.concurrent.ThreadLocalRandom手动生成 128 位再组装 UUID（仅当确定不需要标准 UUID 格式时）
示例（安全复用 SecureRandom）：
private static final ThreadLocal<SecureRandom> SECURE_RANDOM = ThreadLocal.withInitial(SecureRandom::new);
public static UUID fastRandomUUID() {
byte[] data = new byte[16];
SECURE_RANDOM.get().nextBytes(data);
long msb = Long.toUnsignedLong(((long) data[0] << 56) | ((long) data[1] << 48) | ...); // 省略位运算细节
long lsb = Long.toUnsignedLong(...);
return new UUID(msb, lsb);
}
真正该警惕的“重复”来源
绝大多数“UUID 重复”问题根本不是算法导致，而是逻辑错误：
- 误将
UUID.nameUUIDFromBytes(...)当作随机 UUID（它是 deterministic 的，同输入必得同输出） - 测试时硬编码了固定 UUID 字符串，未及时替换
- 数据库字段类型为
VARCHAR(32)却存了带短横线的 36 位字符串，导致前 32 字符被截断后看似重复 - 日志或监控里没打印完整 UUID，只显示哈希或缩略值，造成误判
查重前，先确认你看到的“重复值”是不是同一行完整字符串——复制粘贴比对，别靠肉眼扫。
