网站售价,南平企业网站建设,滨江网站建设制作,嘉兴百度快照优化排名问题描述#xff1a;
为了获取唯一值#xff0c;经常会依赖产生随机数来保证唯一性。在获取随机数时#xff0c;如果使用错误的方法#xff0c;会比较低效。
可以参考以下代码#xff1a;
public static String geneRundomNo(){Random rnew Random();int numr.nextInt(…问题描述
为了获取唯一值经常会依赖产生随机数来保证唯一性。在获取随机数时如果使用错误的方法会比较低效。
可以参考以下代码
public static String geneRundomNo(){Random rnew Random();int numr.nextInt(100000);return num;
}此时使用静态代码扫描工具会出现以下提示 Save and re-use this “Random”. 原因分析
可以看下来自静态代码扫描工具的说明 Creating a new Random object each time a random value is needed is inefficient and may produce numbers which are not random depending on the JDK. For better efficiency and randomness, create a single Random, then store, and reuse it. The Random() constructor tries to set the seed with a distinct value every time. However there is no guarantee that the seed will be random or even uniformly distributed. Some JDK will use the current time as seed, which makes the generated numbers not random at all. This rule finds cases where a new Random is created each time a method is invoked and assigned to a local random variable. 简单的说就是每次需要一个随机值时创建一个新的Random对象是低效的并且可能会根据JDK的版本不同产生非随机的数字。 解决方案
首先看下静态代码扫描工具给出的建议。
private Random rand SecureRandom.getInstanceStrong(); // SecureRandom is preferred to Randompublic void doSomethingCommon() {int rValue this.rand.nextInt();//...如果按照这个建议执行那么会产生2个问题
1、按照上述方式引入还需要解决构建函数的问题。
当引入java.security.SecureRandom后需要解决构造函数问题。 可以通过以下方式解决
private static Random rand;
static {try {rand SecureRandom.getInstanceStrong();} catch (NoSuchAlgorithmException e) {e.printStackTrace();}
}2、使用SecureRandom.getInstanceStrong()会导致线程阻塞问题这个问题也是最严重的。
原因不同的系统环境执行的底层代码不相同在linux系统中是通过底层NativePRNG方法通过/dev/random方式读取随机数/dev/random方式受系统环境的影响容易造成线程阻塞在windows系统中通过generateSeed的native方法读取不会阻塞线程。具体的分析过程可以参考《SecureRandom.getInstanceStrong()引发的线程阻塞问题分析》。这篇文章写的非常详细了。
解决方案使用new SecureRandom()替换SecureRandom.getInstanceStrong()。 请注意这种解决方案是伪随机。
其他相关知识点
以下内容摘自文章《SecureRandom 引发的线程阻塞》 SecureRandom本身并不是伪随机算法的实现而是使用了其他类提供的算法来获取伪随机数。 如果简单的new一个SecureRandom对象的话在不同的操作平台会获取到不同的算法windows默认是SHA1PRNG,Linux的话是NativePRNG。 Linux下的NativePRNG如果调用generateSeed()方法这个方法会读取Linux系统的/dev/random文件这个文件在JAVA_HOME/jre/lib/securiy/java.security里面有默认定义。而/dev/random文件是动态生成的如果没有数据就会阻塞。也就造成了第一个现象。 可以使用-Djava.security.egdfile:/dev/./urandom 这个文件名多个u强制使用/dev/urandom这个文件避免阻塞现象。中间加个点的解释是因为某个JDK BUGSO那个帖子有链接。 如果使用SecureRandom.getInstanceStrong()这种方法初始化SecureRandom对象的话,会使用NativePRNGBlocking这个算法而NativePRNGBlocking算法的特性如下 NativePRNGBlocking uses /dev/random for all of the following operations: Initial seeding: This initializes an internal SHA1PRNG instance using 20 bytes from /dev/random Calls to nextBytes(), nextInt(), etc.: This provides the XOR of the output from the internal SHA1PRNG instance (see above) and data read from /dev/random Calls to getSeed(): This provides data read from /dev/random 可见这个算法完全依赖/dev/random所以当这个文件随机数不够的时候自然会导致卡顿了。 如果使用NativePRNGBlocking算法的话4中的系统参数失效 一般使用SecureRandom不需要设置Seed不需要设置算法使用默认的甚至一个静态的即可如果有需求的话可以在运行一段时间后setSeed一下
参考文章《一文详解安全随机数》这篇文章详细介绍了如何使用安全随机数。 如果这篇博客对大家有所帮助我希望能得到各位的免费点赞和收藏作为对我的鼓励和支持。 同时也请大家在评论区留下您宝贵的意见和建议我将非常欢迎。 感谢大家的支持、评论和收藏
