/dev/random, /dev/urandom

【原文】

今天对进程做性能测试的时候，发现进程会偶然性的多耗时几秒，一会这里，一会那里，我找啊找，到处打log，花了一下午也没找出原因， 极度郁闷的时候，猛然看见有个read调用，莫非是它搞的鬼？读写fd最容易阻塞的，往上看，但它已是非阻塞的，read的文件是/dev /random，不管，先看看/dev/random有没有什么系统设置超时之类的，上网一查，果然发现/dev/random确实有问题，当系统取不到 足够的随机数时，调用了/dev/random的进程会等待，等多长时间不一定，一直等到能取到一个随机数为止，狂喜，原来是/dev/random搞的 鬼，改吧，改为优先用/dev/urandom取随机数，它取不到再用/dev/urandom。虽然/dev/urandom的随机性不如/dev /random，但/dev/urandom能立即返回，不影响进程性能。问题搞定。

此次事情得到的收获：

1、/dev/random与/dev/urandom的区别：虽然random的随机性更好，但不保证能立即返回，如果系统生成随机数次数多，很 可能会导致random取不到足够的随机数而使进程等待，所以如果对性能要求较高的话，还是优先用随机性稍差些的urandom吧。

2、不要轻易改开源库的代码，要知道别人那样用也是有他的道理的。

这次就是改的libuuid，里面是优先用的urandom，觉得random随机性更好，轻易的改成用random，结果就出问题了，别人也知道random的随机性更好，但为什么就是不用呢？当时就没想过这个问题。