Centos环境下Spring Boot集成的Tomcat第一次启动缓慢的一次解决过程
起因
最近的项目是使用spring boot做微服务的开发，使用的spring boot内置的tomcat 8.0作为容器，在spring boot第一次启动的时候发现只要调用的getSession()方法获取或创建新的session，页面展示过程就会耗费了很长的时间，然后下一次就不会出现这种情况。
问题浮现
spring boot第一次启动后：
- 第一次访问数据库，速度很快。pass
- 第一次访问通过模板生成的页面，我们使用pebble最为服务器短的模板引擎，速度也很快。 pass
- 调用getSession(false) 方法，获取session，没有session的话不创建新的，速度也很快。 pass
- 调用getSession() 方法，在没有session的时候会创建新的session并返回，第一次速度非常慢，第二次就很快。
根据以上的判断，肯定是session在创建时花费了很多的时间，问题有了一些眉目。
定位
google了半天，找到了一些解决方法，大意都是：
tomcat的session id的生成主要通过java.security.SecureRandom生成随机数来实现，随机数算法使用的是”SHA1PRNG”。在sun/oracle的jdk里，这个算法的提供者在底层依赖到操作系统提供的随机数据，在linux上，与之相关的是/dev/random和/dev/urandom。有关它俩的描述如下：
/dev/random
在读取时，/dev/random设备会返回小于熵池噪声总数的随机字节。/dev/random可生成高随机性的公钥或一次性
密码本。若熵池空了，对/dev/random的读操作将会被阻塞，直到收集到了足够的环境噪声为止。
/dev/urandom
dev/random的一个副本是/dev/urandom （”unlocked”，非阻塞的随机数发生器），它会重复使用熵池中的数据
以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞，但其输出的熵可能小于/dev/random的。它
可以作为生成较低强度密码的伪随机数生成器，不建议用于生成高强度长期密码。
在tomcat的文档里的建议，采用非阻塞的熵源(entropy source)，通过java系统属性来设置：
-Djava.security.egd=file:/dev/./urandom
这个系统属性egd表示熵收集守护进程(entropy gathering daemon)，但这里值为何要在dev和random之间加一个点呢？是因为一个jdk的bug，在这个bug的连接里有人反馈及时对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random，有人提供了变通的解决方法，其中一个变通的做法是对securerandom.source设置为 /dev/./urandom 才行。
解决1
那么问题就来了，一个一个测试，当然不修改配置文件是最好的
那么按照说法我在执行jar包的时候使用
|
|
应该使能够得到解决，但是坑就坑在了这里，执行了半天，没有任何改版，难道不是这个原因吗，于是又开始找解决方案，把java的配置都dump下来，对比也没见有什么差异，当要放弃的时候，最后决定改下配置文件，于是问题就解决了
最终的解决方案
|
|
找到 securerandom.source=file:/dev/random
改为 securerandom.source=file:/dev/./urandom
保存，然后再启动就解决了。
这个配置就太坑了-Djava.security.egd 是无效的，为了这个事情浪费了3天的时间，不过最终还是解决了，也算没有白忙。