UUID会重复吗

[独孤帆]

public static void main(String[] args) {
		String s = UUID.randomUUID().toString();
		System.out.println(s);
	}

啥也不做，就这样运行

[hugo000002020]

UUID 是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成的API。按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字

UUID由以下几部分的组合：

　　（1）当前日期和时间，UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同。

　　（2）时钟序列

　　（3）全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

[chaoliu1024]

不会重复！重复就不叫UUID了。

[昨日凡阳]

但是，很多情况下，是不会使用UUID的，这个太长了。

[ETCentury]

Universally Unique Identifier

如果重复了，就不能用Unique来修饰了

[jueshengtianya]

[Quote=引用 11 楼 的回复:]
Universally Unique Identifier

如果重复了，就不能用Unique来修饰了
[/Quote]

++

[火龙果被占用了]

不会，JDK 中的 UUID 是随机数的版本，是采用 Random 子类 SecureRandom 强伪随机数据类产生的。

[MiceRice]

如果你可以去试图产生重复的，是可以的，但也没那么容易。

按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码等内容，大致可以理解如下（实际上不同实现所采用的具体规则还是有差异的）：

MAC地址：故意情况下可重复；
机器标识：Java下就是JVM标识，故意情况下可重复；
纳秒级当前时间：故意情况下可重复；
随机数：小概率重复；
自增序列数（或时钟序列）：循环溢出时重复；

总的来说，你需要大量机器运行海量JVM同时生成UUID，才能有很低概率得到重复的UUID。



以上是我凭理解瞎掰，也可以看看稍微专业点的说法：http://zh.wikipedia.org/wiki/UUID

与被陨石击中的机率比较的话，已知一个人每年被陨石击中的机率估计为170亿分之1[1]，也就是说机率大约是0.00000000006 (6 x 10-11)，等同于在一年内建立数十兆笔UUID并发生一次重复。换句话说，每秒产生10亿笔UUID，100年后只产生一次重复的机率是50%。如果地球上每个人都各有6亿笔UUID，发生一次重复的机率是50%。

[一飞]

理论上说,不会重复,但是实际中我不相信你是这个银河系最倒霉的,几率太太太太太....小啦,方心用吧

[coooliang]

有可能重复。只是这辈子还看不到。

[xhm0616]

[Quote=引用 16 楼 的回复:]
有可能重复。只是这辈子还看不到。
[/Quote]

++

[东东不邪]

[Quote=引用 13 楼 的回复:]

不会，JDK 中的 UUID 是随机数的版本，是采用 Random 子类 SecureRandom 强伪随机数据类产生的。
[/Quote]
学习了

[dddddz]

重复概率极小

[zhaoyun776]

哪位大牛知道，如果只取uuid的前8位，重复的可能性有多大。

[东东不邪]

[Quote=引用 19 楼 的回复:]

哪位大牛知道，如果只取uuid的前8位，重复的可能性有多大。
[/Quote]
建议MD5后再取前8位，UUID的前8位MS是日期和时间

[风云扬]

晕，不靠谱，我们的就重复了，还不只一次。

写法
StringUtils.replace(UUID.randomUUID().toString(), "-", ""),

统计
SELECT t.id , COUNT(T.id) c FROM RV_PAYMENTNOTE T GROUP BY T.id having count(t.id) > 1;
1 57ba98c0e34342bfa34d0e88e4aed536 3
2 39bc3b65e12641e49612bba4a9b38a04 2

明细
select t.id ,t.create_date from RV_PAYMENTNOTE t
where t.id in('57ba98c0e34342bfa34d0e88e4aed536', '39bc3b65e12641e49612bba4a9b38a04');
1 39bc3b65e12641e49612bba4a9b38a04 2012-01-11 14:53:07
2 39bc3b65e12641e49612bba4a9b38a04 2012-01-11 14:57:01
3 57ba98c0e34342bfa34d0e88e4aed536 2011-10-25 18:14:30
4 57ba98c0e34342bfa34d0e88e4aed536 2011-11-01 12:59:44
5 57ba98c0e34342bfa34d0e88e4aed536 2011-11-01 12:37:55

[惊鸿仙子君]

[xuxuweifeng]

可能你们数据库插入的时候出的问题。@ITFreeMan

[sky663]

这不是重复机率问题。是对科学的态度问题，你们真的不严谨。 只要知道这有重复的机率，就不应该做唯一序列修饰！ 其实在实际的应用中，ＵＵＩＤ的重复机率并不像某些人吹捧的那样ＸＸＸ年不会重复！ 因为他们总是在ＹＹ的环境中去计算。而实际环境要复杂得多，比如：在虚拟的分布环境中，ＭＡＣ地址是有可能相同的，在时间戳中也有可能相同，计算机在生成随机数的时候，是仍然需要种子的，如果某一时刻的种子相同…………　

[bingbao]

引用 26 楼 sky663 的回复:

这不是重复机率问题。是对科学的态度问题，你们真的不严谨。 只要知道这有重复的机率，就不应该做唯一序列修饰！ 其实在实际的应用中，ＵＵＩＤ的重复机率并不像某些人吹捧的那样ＸＸＸ年不会重复！ 因为他们总是在ＹＹ的环境中去计算。而实际环境要复杂得多，比如：在虚拟的分布环境中，ＭＡＣ地址是有可能相同的，在时间戳中也有可能相同，计算机在生成随机数的时候，是仍然需要种子的，如果某一时刻的种子相同…………　

主要是在虚拟环境中MAC地址有可能重复,这个问题不好解决。在部署时都需要检查一遍。或应用程序把所有机器的MAC地址汇总到一个地方，发生有重复的时间就报告给系统管理员，让他们人为地修改MAC地址。

[一别情深]

不应该像22楼那样使用UUID，UUID是标识，其目的在于交换信息，其实是系统对系统的交换信息，而不是在系统内大量对象间标识，像楼主那样的，最好使用自定义的序列。