一次"自以为是"的优化

缘起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")。

至此问题解决。

总结

经过这次问题，我也总结了一下，任何你不熟悉的东西，你都要需要经过仔细测试和验证，也不要想当然的认为"权威"的都是正确的。

https://www.cnblogs.com/softidea/p/9725156.html