本文说的是解决过程，可直接点击本行略过探查内容，跳到最后的解决办法！！

现象：

1、WEBLOGIC安装在 CENTOS openSUSE 等LINUX或者UNIX机器上，无论是虚拟机或者PC或者服务器

2、创建简单domain，启动后，第一次进入控制台输入用户密码后出现管理界面，每次访问控制台速度均正常。

3、重启weblogic server，访问控制台，输入用户密码后，无法出现管理界面，可能等待5-10分钟，甚至更长。

尝试：

1、捕捉 Thread dump 未发现异常

2、编写建档应用部署，重启weblogic server 后，应用可正常访问，无异常，说明问题在Admin console上

3、重启SERVER服务器（操作系统）后，启动weblogic正常

4、startWeblogic.sh 脚本 中JAVA_OPTIONS中开启-verbose:gc ，再次重启weblogic server，输入用户密码访问控制台 ，未发现gc大量收集阻塞

5、startWeblogic.sh 脚本 中JAVA_OPTIONS中开启-verbose:class ，再次重启weblogic server，输入用户密码访问控制台 ，观察如下：

[Loaded com.bea.console.utils.CSRFUtils from file:/home/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/consoleapp/webapp/WEB-INF/lib/console.jar]
[Loaded com.bea.security.utils.random.AbstractRandomData from file:/home/weblogic/Oracle/Middleware/modules/com.bea.core.common.security.utils_1.0.0.0_6-0-3-0.jar]
[Loaded com.bea.security.utils.random.SecureRandomData from file:/home/weblogic/Oracle/Middleware/modules/com.bea.core.common.security.utils_1.0.0.0_6-0-3-0.jar]
[Loaded java.security.ProviderException from /opt/jdk1.6.0_21/jre/lib/rt.jar]

HANG.....5-10分钟

[Loaded weblogic.transaction.internal.ServerCheckpoint from file:/home/weblogic/Oracle/Middleware/modules/com.bea.core.transaction_2.6.1.0.jar]
[Loaded sun.security.provider.NativePRNG$RandomIO$1 from /opt/jdk1.6.0_21/jre/lib/rt.jar]
[Loaded weblogic.utils.Hex from file:/home/weblogic/Oracle/Middleware/modules/com.bea.core.utils_1.8.0.0.jar]
[Loaded weblogic.management.mbeanservers.internal.JMXConnectorSubjectForwarder$35 from file:/home/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.jar]
[Loaded weblogic.management.jmx.mbeanserver.WLSMBeanServerInterceptorBase$8 from file:/home/weblogic/Oracle/Middleware/modules/com.bea.core.management.jmx_1.4.0.0.jar]
[Loaded com.sun.jmx.mbeanserver.Repository$ObjectNamePattern from /opt/jdk1.6.0_21/jre/lib/rt.jar]
[Loaded weblogic.management.mbeanservers.domainruntime.internal.FederatedMBeanServerInterceptor$1 from file:/home/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.jar]
[Loaded org.apache.taglibs.standard.tag.common.fmt.ParamSupport from file:/home/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/consoleapp/APP-INF/lib/standard.jar]
......

在输入用户密码后，控制台输出停止，等待5-10分钟后，继续。那么之前操作的值得怀疑的地方是加载了com.bea.console.utils.CSRFUtils、com.bea.security.utils.random.AbstractRandomData、com.bea.security.utils.random.SecureRandomData、java.security.ProviderException4个类，这4个类在控制台日志后面都跟有包名。

拿到包后，解压，反编译。大概逻辑就是为了避免CSRF（Cross-site request forgery），需要产生一个随机实例以提供随机字节、整数、长整数等

这里使用随机数的代码是：AbstractRandomData 类中 的

this.random = SecureRandom.getInstance("SHA1PRNG");

然后再用random.nextXxxx()。

之前不觉得这句有问题，后来查了JDK才知道。这个是使用系统的随机数设备（PRNG：伪随机序列发生器  pseudo-random number generator），当调用nextXxx方法时，系统提供一个随机数使用。

正点来了

linux或者部分unix系统提供随机数设备是/dev/random 和/dev/urandom ，两个有区别，urandom安全性没有random高，但random需要时间间隔生成随机数。jdk默认调用random。

再后来，终于在weblogic的官方文档中 Monitoring and Troubleshooting 找到了 Avoiding JVM Delays Caused By Random Number Generation 这样一个标题。摘录如下：

The library used for random number generation in Sun's JVM relies on /dev/random by default for UNIX platforms. This can potentially block the Oracle WebLogic Communication Services process because on some operating systems /dev/random waits for a certain amount of "noise" to be generated on the host machine before returning a result. Although /dev/random is more secure, Oracle recommends using /dev/urandom if the default JVM configuration delays Oracle WebLogic Communication Services startup. To determine if your operating system exhibits this behavior, try displaying a portion of the file from a shell prompt: head -n 1 /dev/random Open the $JAVA_HOME/jre/lib/security/java.security file in a text editor. Change the line: securerandom.source=file:/dev/random to read: securerandom.source=file:/dev/urandom Save your change and exit the text editor.

其中说到：可通过 head -n 1 /devrandom 查看是否你的系统会出现伪随机数提供等待。OK就这个，试了一下，果然，在服务器第一次启动后，这个可以快速提供一个值，但当再次调用时发生等待。

解决办法：

永久：oracle 说修改 $JAVA_HOME/jre/lib/security/java.security  文件，替换securerandom.source=file:/dev/random 为 securerandom.source=file:/dev/urandom。对所有使用JVM的应用生效。（这个永久的方法，这里面有个问题，就是设置时候实际应该设置为securerandom.source=file:/dev/./urandom，否则不生效）

DOMAIN临时：修改startWeblogic.sh文件，JAVA_OPTIONS="${SAVE_JAVA_OPTIONS} -Djava.security.egd=file:/dev/./urandom"

后继的SecureRandom 测试学习

编写JAVA类如下，运行测试，第一次正常，第二次等待，重启服务器后第一次又正常。启动加入参数 -Djava.security.egd=file:/dev/./urandom 正常

java -Djava.security.egd=file:/dev/./urandom Test

源码如下：

import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.security.Security;

public class Test {
        public static void main(String[] args) {
                try {
                        System.out.println("Begin to get SecureRandom Instance.");
                        SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
                        System.out.println("SR is ready for use....");
                        System.out.println("Next double is :" + sr.nextDouble());

                } catch (NoSuchAlgorithmException e) {
                        e.printStackTrace();
                }
        }
}

结束语：

唉，这些可能影响应用的东西应该在安装文档之前就应该执行的检查啊，希望甲骨文这个地方效仿IBM ，安装文档执行检查，安装包提供preInstallCheck脚本，以避免异常。