strace 非常聪明它不仅仅给出了System Call还给出了传递的参数和返回值，read读取的是51号文件句柄，没有返回成功(unfinished)。 顺着这条路，我们看一下51号文件句柄是什么 /dev/random 是Linux下的随机函数生成器，读取它相当于生成随机数字。搜索它，第一个是wiki 至此似乎一切真相大白了，/dev/random会根据 噪音 产生随机数，如果 噪音 不够它就会阻塞。Linux是通过I/O，键盘终端、内存使用量、CPU利用率等方式来收集 噪音 的，如果 噪音 不够生成随机数的时候就会被 阻塞 。
深入分析
如果用Tomcat /dev/random作为关键字基本上就能够回答我们的疑惑了。Tocmat的Session ID是通过SHA1算法计算得到的，计算Session ID的时候必须有一个密钥。为了提高安全性Tomcat在启动的时候回通过随机生成一个密钥。 在 http://wiki.apache.org/tomcat/HowTo/FasterStartUp (Entropy Source部分)有一段解释。stackoverflow上面也有一大批这方面的说明，所以这里就不再多做介绍。 明白了问题的原因解决起来就非常简单了——替换/dev/random为/dev/unrandom，用伪随机函数生成器(/dev/urandom)来替代随机函数生成器(/dev/random)。
通过修改Tomcat启动文件 -Djava.security.egd=file:/dev/urandom
通过修改JRE中的java.security文件 securerandom.source=file:/dev/urandom
当然JVM的开发者不是傻瓜，Tomcat的开发者也不是二百五。他们之所以没有选择/dev/urandom是为了提高系统的安全性，/dev/urandom并不是真正的随机行为。（其实一般情况下/dev/urandom也是足够安全的不太容易被“重复”）
彻底解决问题
上面介绍的两种方式都是用/dev/urandom替换/dev/random，其实还有第三种方式——增大/dev/random的熵池。问题的原因是由于熵池不够大，所以增大它是最彻底的方法。 通过 cat /proc/sys/kernel/random/entropy_avail 我们可以查看现在的熵池大小；我们需要找到一种方式来提高这个值就行了。如果你的CPU带有DRNG特性，可以充分利用硬件来提高熵池产生的速度 。通过 cat /proc/cpuinfo | grep rdrand 可以查看自己的CPU是否支持，一般来说Intel的Ivy_Bridge架构的CPU都支持（i3、i5需要注意是否采用该种架构，i7和xeon基本上都支持）；AMD的CPU在2015年以后生成的都支持。（如果你是虚拟机需要开启额外的参数)。如果你的硬件不支持，也没有关系，我们可以让/dev/unrandom来做“熵源”。以Centos7为例，
5秒产生了40960个随机数，/proc/sys/kernel/random/entropy_avail会有剧烈的变化，所有随机数产生之后它又会保持在3000左右。
选择哪种解决方法
个人建议选择第三种方式，熵池不仅仅Tomcat用，Linux下的所有应用程序产生随机数都会用到这个，所以不仅仅是Tomcat可能被 阻塞 。如果你搜索会发现Apache、Nginx、OpenSSL都被这个问题 坑过 。如果我们通过修改Java的配置来解决这个问题其实只是解决Java应用程序的问题，只能是治标不治本。根治的方法应该是通过 rngd 提高随机数生成的速度。
从 /dev/random 中读取字节后，熵池就使用 MD5 算法进行密码散列，该散列中的各个字节被转换成数字，然后返回。
如果在熵池中没有可用的随机性位， /dev/random 在池中有足够的随机性之前等待，不返回结果。这意味着如果使用 /dev/random 来产生许多随机数，就会发现它太慢了，不够实用。我们经常看到 /dev/random 生成几十字节的数据，然后在许多秒内都不产生结果。
幸运的是有熵池的另一个接口可以绕过这个限制：/dev/urandom。即使熵池中没有随机性可用，这个替代设备也总是返回随机数。如果您取出许多数而不给熵池足够的时间重新充满，就再也不能获得各种来源的合用熵的好处了；但您仍可以从熵池的 MD5 散列中获得非常好的随机数！这种方式的问题是，如果有任何人破解了 MD5 算法，并通过查看输出了解到有关散列输入的信息，那么您的数就会立刻变得完全可预料。大多数专家都认为这种分析从计算角度来讲是不可行的。然而，仍然认为 /dev/urandom 比 /dev/random 要“不安全一些”（并通常值得怀疑）。