linux – 来自java的UUID.randomUUID()的重复UUID集
|
我们观察到近200,000个UUID已经重播了两个月,我想知道是否有人看到过类似的东西.
UUID是使用UUID.randomUUID()生成的.在深入研究这个问题(查看java源代码)时,randomUUID()在引擎盖下使用SecureRandom(),后者又使用NativePRNG.据我所知,NativePRNG使用/ dev / urandom获取其种子.当然这意味着莫名其妙 – 不知何故/ dev / urandom在相隔两个月的时间里将相同的种子归还给NativePRNG.据我所知,一旦实例化,PRNG就不会再播种.这是一个长时间运行的作业,它正在侦听消息并使用UUID作为它的ID.伪代码很简单： <接收消息> 操作系统是Centos 6,位于运行JDK1.6的AWS EC2实例上.这是过去曾见过/经历过的事吗？似乎应该“永远不会发生”的事情…… 解决方法
实际上,从JDK 1.6源代码,UUID.randomUUID()以java.util.SecureRandom实例为基础.如果你有一个重复的UUID序列,那么要么你很幸运(或者非常不幸,取决于观点),或者有人使用VM快照,或者你的
Java配置中有些可疑.
在拍摄VM快照时,您将记录机器的完整实时状态,包括的进程和RAM.如果存在已经实例化的SecureRandom实例的实时进程,则恢复快照将恢复该状态,因此每次恢复时SecureRandom输出的随机值序列将相同,直到SecureRandom从/ dev重新安排自身为止/ urandom(/ dev / urandom持续收集“随机”物理事件,但这些事件在下次重播之前不会影响SecureRandom状态). Java配置可能会影响SecureRandom,因为SecureRandom不是PRNG,而是由正式注册的加密提供程序提供的SecureRandomSpi实例周围的shell. Sun的JDK附带了一个默认实现,通常以系统资源为基础(Linux上的/ dev / urandom).但是,这可以配置;查找java.security.egd系统属性,以及java.security文件中的securerandom.source属性.默认提供程序也可以与替代实现一起替换,该替换实现以不同方式执行(并且可能非常差).有关详细信息,请参阅this answer.验证确实使用了哪些随机源可能有点复杂,但您可以尝试使用strace启动进程,这将显示系统调用,因此是否在某些时候打开/ dev / random或/ dev / urandom. 如果您的Java配置没问题,并且没有带有VM快照的游戏,并且您确定您确实获得了与之前相同的UUID序列,那么您真的应该购买一张强力球票(但我并不诚实地相信)在这种情况下). （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |