linux shell 脚本参数 file:/dev/./urandom 和 2＞&1 释疑

最新推荐文章于 2025-08-18 20:50:22 发布

原创最新推荐文章于 2025-08-18 20:50:22 发布 · 1.3k 阅读

0 ·

CC 4.0 BY-SA版权

Linux系统运维专栏收录该内容

45 篇文章

订阅专栏

本文详细解释了Linux Shell脚本中-Djava.security.egd=file:/dev/./urandom参数的作用，该参数用于加速SecureRandom的随机数生成，尤其是在Tomcat启动时。文章还介绍了2>&1的用法，说明了如何将标准错误输出重定向到标准输出，并解释了为何通常将其放置在命令末尾。

linux shell 脚本参数 -Djava.security.egd=file:/dev/./urandom 释疑

参考文章

Tomcat 启动时 SecureRandom 非常慢解决办法,亲测有效
https://www.cnblogs.com/hangxinggreat/p/9891330.html

脚本解释

原始启动脚本 run.sh

run.sh 
cd /root/swy-syncdata
../jdk1.8.0_161/bin/java -Djava.security.egd=file:/dev/./urandom -Dsecurerandom.source=file:/dev/./urandom -jar swy-syncdata-1.0.jar  >> swy-syncdata.log 2>&1

格式化后的脚本 run.sh

cd /root/swy-syncdata ../jdk1.8.0_161/bin/java 
                      -Djava.security.egd=file:/dev/./urandom 
					  -Dsecurerandom.source=file:/dev/./urandom 
					  -jar swy-syncdata-1.0.jar  >> swy-syncdata.log 2>&1

SecureRandom在java各种组件中使用广泛，可以可靠的产生随机数。但在大量产生随机数的场景下，性能会较低。
这时可以使用"-Djava.security.egd=file:/dev/./urandom"
加快随机数产生过程。

file:/dev/./urandom 参数的解释

文章中说，实例化该对象使用了253秒，导致整个应用启动了275秒之久。

org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of
SecureRandom instance for session ID generation using [SHA1PRNG] took [253,251] milliseconds.

SecureRandom 这个 jre 的工具类的问题。那为什么 SecureRandom generateSeed 这么慢，甚至挂在 Linux 操作系统呢？

Tomcat 7/8 都使用 org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 类产生安全随机类 SecureRandom 的实例作为会话 ID。

Tomcat 使用 SHA1PRNG 算法是基于 SHA-1 算法实现且保密性较强的伪随机数生成器。

在 SHA1PRNG 中，有一个种子产生器，它根据配置执行各种操作。

Linux 中的随机数可以从两个特殊的文件中产生，一个是 /dev/urandom，另外一个是 /dev/random。他们产生随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特，然后将这些比特作为字节流返回。熵池就是当前系统的环境噪音，熵指的是一个系统的混乱程度，系统噪音可以通过很多参数来评估，如内存的使用，文件的使用量，不同类型的进程数量等等。如果当前环境噪音变化的不是很剧烈或者当前环境噪音很小，比如刚开机的时候，而当前需要大量的随机比特，这时产生的随机数的随机效果就不是很好了。

这就是为什么会有 /dev/urandom 和 /dev/random 这两种不同的文件，后者在不能产生新的随机数时会阻塞程序，而前者不会（ublock），当然产生的随机数效果就不太好了，这对加密解密这样的应用来说就不是一种很好的选择。/dev/random 会阻塞当前的程序，直到根据熵池产生新的随机字节之后才返回，所以使用 /dev/random 比使用 /dev/urandom 产生大量随机数的速度要慢。

SecureRandom generateSeed 使用 /dev/random 生成种子。但是 /dev/random 是一个阻塞数字生成器，如果它没有足够的随机数据提供，它就一直等，这迫使 JVM 等待。键盘和鼠标输入以及磁盘活动可以产生所需的随机性或熵。但在一个服务器缺乏这样的活动，可能会出现问题。

shell 2>&1 知识点

A.首先了解下1和2在Linux中代表什么

在Linux系统中0 1 2是一个文件描述符

名称	代码	操作符	Java中表示	Linux 下文件描述符（Debian 为例)
标准输入(stdin)	0	< 或 <<	System.in	/dev/stdin -> /proc/self/fd/0 -> /dev/pts/0
标准输出(stdout)	1	>, >>, 1> 或 1>>	System.out	/dev/stdout -> /proc/self/fd/1 -> /dev/pts/0
标准错误输出(stderr)	2	2> 或 2>>	System.err	/dev/stderr -> /proc/self/fd/2 -> /dev/pts/0

从上表看的出来，我们平时使用的
echo "hello" > t.log
其实也可以写成
echo "hello" 1> t.log

B.关于2>&1的含义

（关于输入/输出重定向本文就不细说了，不懂的可以参考这里，主要是要了解> < << >> <& >& 这6个符号的使用）

1、含义：将标准错误输出重定向到标准输出

2、符号>&是一个整体，不可分开，分开后就不是上述含义了。
比如有些人可能会这么想：2是标准错误输入，1是标准输出，>是重定向符号，那么"将标准错误输出重定向到标准输出"是不是就应该写成"2>1"就行了？是这样吗？
如果是尝试过，你就知道2>1的写法其实是将标准错误输出重定向到名为"1"的文件里去了

3、写成2&>1也是不可以的

C.为什么2>&1要放在后面

考虑如下一条shell命令

nohup java -jar app.jar >log 2>&1 &

(最后一个&表示把条命令放到后台执行，不是本文重点，不懂的可以自行Google)

为什么2>&1一定要写到>log后面，才表示标准错误输出和标准输出都定向到log中？

我们不妨把1和2都理解是一个指针,然后来看上面的语句就是这样的：

本来1----->屏幕 （1指向屏幕）
执行>log后， 1----->log (1指向log)
执行2>&1后， 2----->1 (2指向1，而1指向log,因此2也指向了log)

再来分析下

nohup java -jar app.jar 2>&1 >log &

本来1----->屏幕 （1指向屏幕）
执行2>&1后， 2----->1 (2指向1，而1指向屏幕,因此2也指向了屏幕)
执行>log后， 1----->log (1指向log，2还是指向屏幕)

所以这就不是我们想要的结果。