记录SecureRandom踩坑经历

朱雀 2022-12-25 01:45 317阅读 0赞

### 背景 ###

上周工作中有个问题耽搁了很长时间，打算写个博客记录一下，算是一个小复盘。

#### 问题 ####

我们公司共有三个测试环境，暂且称为test1、test2、test3环境。有一个服务发布在test3环境可以正常使用，没有任何报错，但是发布在test2环境就会报错。代码都是一样的，刚开始是怀疑配置有问题，仔细检查之后没有任何问题。后来借助arthas定位到了问题在于**SecureRandom**。也是因为这个事情，也专门写了一篇博客记录下[arthas的简单实用][arthas]。

#### SecureRandom ####

使用随机数的话，一般会像这样：

public void doSomethingCommon() { 
      Random rand = new Random();  
      ...
    }

但是呢，这样使用的话，sonar会给你一个告警：

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.

大意就是说不能每个方法都创建 Random生成随机数，因为效率太低，应该定义Random单例统一生成。并且明确建议使用SecureRandom.getInstanceStrong() 来初始化，就像这样：

private Random rand = SecureRandom.getInstanceStrong();

ok，照你说的改，改完之后就出现了上面的问题，test3环境是好的，test2就是不行，只有上了arthas才定位到问题所在，执行到 SecureRandom.getInstanceStrong() 方法后就线程就阻塞掉了，这就很拉胯了。

关于SecureRandom，[这篇文章][Link 1]讲的很清楚了，大概是因为SecureRandom在生成随机数的时候，会判断当前服务器环境的一些属性值，鼠标、键盘输入这些都算，所以就和环境有很强的相关性了，如果没有足够的环境属性用于生成随机数，就会一直等待，也就迫使JVM等待了。

源码中显示：

SecureRandom secureRandom = new SecureRandom();

会指定seed = 0，而sonar推荐的方式没有指定这个值，我猜差别应该是在这地方，总之new的方式不会导致阻塞，当然了，这是我猜的。

总之这种因为环境不同导致的问题，排查起来还是很糟心的。首先想吐槽下sonar，也是因为它的扫描和推荐才导致我排查这个了好久，其次呢也算吃一堑长一智，以后遇到这种问题也大概有个思路了，还有就是arthas又熟了一些，活到老学到老哈哈~~

参考资料：  
[使用 SecureRandom 产生随机数采坑记录][Link 1]

[arthas]: https://blog.csdn.net/hz_940611/article/details/110356488
[Link 1]: https://www.cnblogs.com/xiekun/p/11938196.html