Tomcat starts slowly in the CentOS environment

A problem was found when the recent project was deployed on line. Tomcat takes a long time to launch. Look at the logs and find that the longest time is:
INFO [localhost-startstop-1] Org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID Gener
ation using [sha1prng] took [1,693,533] milliseconds.
After finding the information on the Internet, the problem is that the generation of the session ID of Tomcat is mainly realized by java.security.SecureRandom generating random numbers, and the random number algorithm uses "SHA1PRNG". In Sun/oracle's JDK, the provider of this algorithm relies on random data provided by the operating system at the bottom, and on Linux, it is related to/dev/random and/dev/urandom. The descriptions of the two are as follows:
/dev/random
On reading, the/dev/random device returns random bytes that are less than the total entropy pool noise. /dev/random can generate high-randomness public keys or disposable
Password book. If the entropy pool is empty, the read operation on the/dev/random will be blocked until sufficient ambient noise is collected.
/dev/urandom
A copy of the Dev/random is/dev/urandom ("unlocked", a non-blocking random number generator) that reuses the data in the entropy pool
To produce pseudo-random data. This means that the read operation on the/dev/urandom is not blocked, but its output entropy may be less than/dev/random. It
Can be used as a pseudo-random number generator for generating lower strength passwords and is not recommended for generating strong long-term passwords.
As suggested in the Tomcat documentation, the non-blocking entropy source (entropy source) is used to set the Java System Properties:
-djava.security.egd=file:/dev/./urandom
This system attribute EGD represents the Entropy collection daemon (entropy gathering daemon), but why is it worth adding a point between dev and random? is because of a JDK bug, in the connection of this bug someone feedback timely to securerandom.source set to/dev/urandom it also still use/dev/random, someone provides a workaround, One of the workarounds is to set Securerandom.source to/dev/./urandom. Some people commented that this is not a bug, it is intentional.

My final solution is as follows:
Find $JAVA _home/jre/lib/security/java.security This file and find it inside.
Securerandom.source=file:/dev/random
Or
Securerandom.source=file:/dev/urandom
Revision changed to
Securerandom.source=file:/dev/./urandom

Original Details Address: http://www.roncoo.com/article/detail/125962

Tomcat starts slowly in the CentOS environment