缘起Sonar-lint
事情起因于公司要求对代码质量的提升，所以在代码提交到git仓库之前，首先要使用Sonar-lint来扫描一下代码，将比较严重的问题修改之后才能提交到git仓库中。
其中有段代码有使用随机数的功能，原来的代码如下：
public static Integer getNo(){
Random random = new Random();
return random.nextInt(899999)+100000;
}
经过扫描之后，提示了这样一段内容：
问题.png
大致的意思就是：
你每次用Random都创建一个新的，效率是很低下的，且这种产生的随机数是依赖于JDK的非随机数，效率和随机性都得不到保障。最好的方法就是只创建一个变量，大家公用它。
看到这里，也没啥好说的，那就改呗，放到类变量里就行了呗。
可是再继续往下看的时候，一句话引起了我的注意：
源头.png
这句话很好理解了，使用SecureRandom 要优于Random。好吧，你说的都对，听你的，就这样改。
代码改好之后，本地测试了一下，没有问题，收工！
问题来了
发布到测试环境（linux），跑了一个基本功能，调用一个接口（获取验证码）。
5秒钟过去了...
30秒过去了...
1分钟过去了...
咦？？什么情况？？？
小手微微有些颤抖（其实还好啦，甚至有点小兴奋，毕竟测试环境嘛！）。。
jps找到这个进程
jstack <pid> >> stack.txt
打开stack.txt，根据包名查找线程，找到了下面这样一些内容：
"http-nio-8779-exec-1" #30 daemon prio=5 os_prio=0 tid=0x00007f93d68f9800 nid=0x3b29 runnable [0x00007f93567af000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424)
at sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:525)
at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:544)
- locked <0x00000000c082fd58> (a java.lang.Object)
at sun.security.provider.NativePRNG$RandomIO.access$400(NativePRNG.java:331)
at sun.security.provider.NativePRNG$Blocking.engineNextBytes(NativePRNG.java:268)
at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
at java.security.SecureRandom.next(SecureRandom.java:491)
at java.util.Random.nextInt(Random.java:390)
at com.xzl.common.utils.BusinessNoUtils.randomInt(BusinessNoUtils.java:37)
at com.xzl.auth.service.impl.LoginServiceImpl.getLoginSmsCode(LoginServiceImpl.java:118)
这个线程一直是Running状态，这不正常，仔细定位到代码可以看到主要是执行获取随机数的地方，而这个地方恰恰就是我们刚才改的地方。
OK，到了这里，已经定位到导致阻塞的问题了，就是获取随机数导致的。
But Why？？？
寻找答案
网上关于这个问题还是比较容易找到的，说明大家遇到这个问题的概率还是比较高的。
主要原因是不同的平台使用的默认的算法不一样。
在JDK默认路径下：
jdk/jre/lib/securiyt/java/security
有这样一个配置
securerandom.strongAlgorithms=
在本机的windows平台下配置的算法是：
securerandom.strongAlgorithms=Windows-PRNG:SunMSCAPI,SHA1PRNG:SUN
而在测试环境的linux平台下配置的算法是：
securerandom.strongAlgorithms=NativePRNGBlocking:SUN
虽然不是特别明白算法的具体意义，但是我看到了linux平台下算法名称里有Blocking这个单词。
这不就是阻塞的意思的吗？？？
根据网上提供的解决方案，修改配置为：
securerandom.strongAlgorithms=NativePRNGNonBlocking
测试一下，果然没问题了。
可是问题还是没解决啊，我总不能每次部署到不同的服务器上都去修改这个配置文件吧。
这个文件是jdk系统文件，修改它或重新指定一个路径都比较麻烦，最好能通过系统环境变量来设置，可这个变量不能通过-Dxxx.xx来配置。只能修改代码，将代码改成
SecureRandom.getInstance("NativePRNGNonBlocking")。
至此问题解决。
总结
经过这次问题，我也总结了一下，任何你不熟悉的东西，你都要需要经过仔细测试和验证，也不要想当然的认为"权威"的都是正确的。
网友评论