UUID.randomUUID()生成的是密码学安全的伪随机数，基于SecureRandom从操作系统熵源（如/dev/urandom）获取，非真随机但足够唯一和不可预测。
UUID.randomUUID() 生成的是真随机还是伪随机？
它用的是 SecureRandom，不是 Math.random() 或 Random。这意味着它会尝试从操作系统收集熵（比如 /dev/urandom），生成的是密码学安全的伪随机数——不是“真随机”，但对绝大多数业务场景已足够唯一和不可预测。
- 每次调用
UUID.randomUUID()都会重新初始化一个SecureRandom实例（JDK 17+ 优化为复用，但行为不变） - 不依赖系统时间戳，所以不存在毫秒级并发重复问题
- 生成结果是 version 4 UUID，格式形如
550e8400-e29b-41d4-a716-446655440000，其中 122 位由随机数填充
为什么不能直接用 toString() 存数据库？
因为默认 toString() 返回带连字符的 36 字符字符串（如 "f47ac10b-58cc-4372-a567-0e02b2c3d479"），而多数数据库（MySQL、PostgreSQL）对字符串索引效率敏感，36 字符比 32 字符（去横线）多 12.5% 存储开销，且无法利用前缀索引优势。
- 存前推荐用
uuid.toString().replace("-", "")得到 32 位小写十六进制字符串 - 若字段类型是
BINARY(16)（MySQL）或BYTEA（PostgreSQL），应调用uuid.getMostSignificantBits()和uuid.getLeastSignificantBits()拆成两个long，再转为 16 字节数组——比字符串节省 50%+ 存储，索引性能更优 - 注意：
UUID.nameUUIDFromBytes()是确定性生成（适合缓存键），但不是随机型，别误用于主键
高并发下 UUID.randomUUID() 有性能瓶颈吗？
有，但通常不是你该最先担心的点。瓶颈不在 UUID 逻辑本身，而在 SecureRandom 初始化时可能触发的熵池阻塞（尤其在容器或虚拟机中 /dev/random 不足时）。
- JDK 8u292+ 和 JDK 17+ 默认启用
NativePRNGNonBlocking，自动 fallback 到 /dev/urandom，基本消除阻塞 - 如果仍观察到
SecureRandom.getInstanceStrong()耗时突增，检查是否误用了该方法（UUID 不用它） - 真正压测时，单机每秒几万次
randomUUID()调用无压力；若达 10w+/s 且延迟升高，优先排查 GC 或锁竞争，而非 UUID 本身
替代方案对比：UUID vs Snowflake vs 数据库自增
选型关键不在“唯一”，而在「有序性」「可读性」「跨服务协调成本」：
立即学习“Java免费学习笔记（深入）”；
-
UUID：无中心、全局唯一、天然分布式友好；缺点是无序（B+树索引写放大）、不可读、占用空间大（16–36 字节） -
Snowflake（如 Twitter 的 64 位整型）：时间有序、紧凑（8 字节）、可反解出时间戳；需部署 ID 生成服务，存在机器时钟回拨风险 -
数据库自增：最简单，但强依赖单点，分库分表后需额外设计（如号段模式），不适合微服务直连
如果你的应用已经用 Spring Boot + JPA，并且主键字段定义为 @GeneratedValue(generator = "uuid2")，那 Hibernate 默认用的就是 UUID.randomUUID() ——此时改用 Snowflake 反而要重写主键策略和迁移历史数据。
public class UuidExample {
public static void main(String[] args) {
UUID uuid = UUID.randomUUID();
// 推荐存储形式：32位无横线小写
String storageKey = uuid.toString().replace("-", "");
// 或转为16字节数组（适用于BINARY(16)）
byte[] bytes = new byte[16];
long msb = uuid.getMostSignificantBits();
long lsb = uuid.getLeastSignificantBits();
for (int i = 0; i < 8; i++) {
bytes[i] = (byte) (msb >>> 8 * (7 - i));
bytes[8 + i] = (byte) (lsb >>> 8 * (7 - i));
}
}
}实际项目里，UUID 是否真“唯一”不取决于生成函数，而取决于你怎么用它——比如把 UUID.nameUUIDFromBytes("user:123".getBytes()) 当作用户 ID，就等于主动放弃随机性，还自以为安全。
