我们观察到近200,000个UUID已经重播了两个月,我想知道是否有人看到过类似的东西.
UUID是使用UUID.randomUUID()生成的.在深入研究这个问题(查看java源代码)时,randomUUID()在引擎盖下使用SecureRandom(),后者又使用NativePRNG.据我所知,NativePRNG使用/ dev/urandom获取其种子.当然这意味着莫名其妙 - 不知何故/ dev/urandom在相隔两个月的时间里将相同的种子归还给NativePRNG.据我所知,一旦实例化,PRNG就不会再播种.这是一个长时间运行的作业,它正在侦听消息并使用UUID作为它的ID.伪代码很简单:
< receive message>
String uuid = UUID.randomUUID().toString();
String fname = h.composeArtifact(uuid);
操作系统是Centos 6,位于运行JDK1.6的AWS EC2实例上.这是过去曾见过/经历过的事吗？似乎应该"永远不会发生"的事情......
Tho*_*nin 15
从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附带一个默认实现,通常以系统资源为基础(/dev/urandom在Linux上).但是,这可以配置; 查找java.security.egd系统属性,以及文件中的securerandom.source属性java.security.默认提供程序也可以与替代实现一起替换,该替换实现以不同方式执行(并且可能非常差).有关详细信息,请参阅此答案.验证什么随机源确实使用可能有点复杂,但你可以尝试启动你的进程与strace的,它会显示系统调用,因此是否/dev/random或/dev/urandom在某个时间点打开.
如果您的Java配置没问题,并且没有带有VM快照的游戏,并且您确定您确实获得了与之前相同的UUID序列,那么您真的应该购买一张强力球票(但我并不诚实地相信)在这种情况下).