导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:335
阅读量:1127881
访问量:114658
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
博文->>首页 博主的更多博文>>
生产事故之SecureRandom
Tags : SecureRandom,生产事故发表时间: 2019-11-30 01:24:32
写在前面--每个人都是在不断碰壁中获得成长,bug的逼格越高, 成长速度越快。

        本人上周亲手写下了一个牛逼的bug,直接导致的结果是,晚上12点升级后台接口以后,第二天早上7点多开始,所有的app页面出现卡顿,白屏。公司研发老总,迅速召集公司运维大佬,产品大佬,研发大佬奔赴公司解决bug。所有人,开始手忙脚乱,查看线上日志,抓包,阿尔萨斯监听 接口耗时。各个大神,各种手段,各显才能。。。经过三个小时的排查,最终用jstack 命令查看线程数,发现整个服务,线程不断攀升至400多,且绝大多数空闲线程一直处于等待状态,没有执行任何任务。吊诡的地方就在这里,紧急着,进入线程号里面,发现打印了如下堆栈信息:

   http-nio-8080-exec-177" #441 daemon prio=5 os_prio=0 tid=0x00002ae00812e800 nid=0x6183 waiting for monitor entry [0x00002ae042f6b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:543)
        - waiting to lock <0x0000000700ad0ca0> (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.yunshi.xy.service.impl.XyContentPVServiceImpl.addV2RandomNum(XyContentPVServiceImpl.java:559)
        at com.yunshi.xy.service.thread.ActionLogPvThread.run(ActionLogPvThread.java:69)
        at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:2038)
        at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
        at org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor.execute(ThreadPoolTaskExecutor.java:314)
        at com.yunshi.xy.web.api.XyToCQueryApiController.addActionLogByPv(XyToCQueryApiController.java:2974)
        at com.yunshi.xy.web.api.XyToCQueryApiController
FastClassBySpringCGLIB
FastClassBySpringCGLIB
6446a859.invoke(<generated>)
        at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
        at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:749)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
        at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:56)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175)
        at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:56)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:93)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
        at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
        at com.yunshi.xy.web.api.XyToCQueryApiController
EnhancerBySpringCGLIB
EnhancerBySpringCGLIB
8e41f2ae.addActionLogByPv(<generated>)
        at sun.reflect.GeneratedMethodAccessor140.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:892)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797)
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1039)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:942)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1005)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:897)

 

当我看到SecureRandom这个关键字时,恍然大悟,这不是前几天通过solar进行代码检测时,刚刚修改的类吗?发生了什么?

线程安全?线程阻塞?有关线程的各个关键词在大脑里一闪而过。。。于是迅速恢复代码成原先的Random r = new Random()重新构建服务,app恢复正常,卧槽。。。。。。。。。什么鬼

         首先去看soloar代码检测给出的建议是这样的:

Noncompliant Code Example
public void doSomethingCommon() {
  Random rand = new Random();  // Noncompliant; new instance created with each invocation
  int rValue = rand.nextInt();
  //...
Compliant Solution
private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom is preferred to Random
 
public void doSomethingCommon() {
  int rValue = this.rand.nextInt();
  //...
当时未进行更多的思考,直接把SecureRandom.getInstanceStrong();写在了方法内,引发了线程阻塞

 

今天再一次查SecureRandom.getInstanceStrong();这个方法时,才发现如下问题:

SecureRandom.getInstanceStrong(); 是jdk1.8里新增的加强版随机数实现

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

 

1,如果是tomcat 环境,有如下解决方式

可以通过配置JRE使用非阻塞的Entropy Source: 
在catalina.sh中加入这么一行:-Djava.security.egd=file:/dev/./urandom 即可。 
加入后再启动Tomcat,整个启动耗时下降到Server startup in 20130 ms。 
这种方案是在修改随机数获取方式,那这里urandom是啥呢?

/dev/random的一个副本是/dev/urandom(“unblocked”,非阻塞的随机数发生器[4]),它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞,但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器,不建议用于生成高强度长期密码。 - - - wikipedia

在JVM环境中解决 
打开$JAVA_PATH/jre/lib/security/java.security这个文件,找到下面的内容:

securerandom.source=file:/dev/random
替换成

securerandom.source=file:/dev/./urandom
 

2 springboot项目,网上发现很多朋友启动时加了启动参数:

-Djava.security.egd=file:/dev/./urandom

但是没有起作用

去查 NativePRNG$Blocking的代码,看到它的文档描述:

A NativePRNG-like class that uses /dev/random for both seed and random material. Note that it does not respect the egd properties, since we have no way of knowing what those qualities are.

奇怪怎么-Djava.security.egd=file:/dev/./urandom参数没起作用,仍使用/dev/random作为随机数的熵池,时间久或调用频繁的话熵池很容易不够用而导致阻塞;于是看了一下 SecureRandom.getInstanceStrong()的文档:

Returns a SecureRandom object that was selected by using the algorithms/providers specified in the securerandom.strongAlgorithms Security property.

原来有自己的算法,在 jre/lib/security/java.security 文件里,默认定义为:

securerandom.strongAlgorithms=NativePRNGBlocking:SUN
如果修改算法值为NativePRNGNonBlocking:SUN的话,会采用NativePRNG$NonBlocking里的逻辑,用/dev/urandom作为熵池,不会遇到阻塞问题。但这个文件是jdk系统文件,修改它或重新指定一个路径都有些麻烦,最好能通过系统环境变量来设置,可这个变量不像securerandom.source属性可以通过系统环境变量-Djava.security.egd=xxx来配置,找半天就是没有对应的系统环境变量。只好修改代码,不采用SecureRandom.getInstanceStrong这个新方法,改成了SecureRandom.getInstance("NativePRNGNonBlocking")。

 

整理一下知识点(转载自:https://www.iteye.com/blog/wwwcomy-2342229)

1.SecureRandom本身并不是伪随机算法的实现,而是使用了其他类提供的算法来获取伪随机数。 

2.如果简单的new一个SecureRandom对象的话,在不同的操作平台会获取到不同的算法,windows默认是SHA1PRNG,Linux的话是NativePRNG。 

3. Linux下的NativePRNG,如果调用generateSeed()方法,这个方法会读取Linux系统的/dev/random文件,这个文件在JAVA_HOME/jre/lib/securiy/java.security里面有默认定义。而/dev/random文件是动态生成的,如果没有数据,就会阻塞。也就造成了第一个现象。 

4.可以使用-Djava.security.egd=file:/dev/./urandom (这个文件名多个u)强制使用/dev/urandom这个文件,避免阻塞现象。中间加个点的解释是因为某个JDK BUG,SO那个帖子有链接。 

5.如果使用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,所以当这个文件随机数不够的时候,自然会导致卡顿了。 
6.如果使用NativePRNGBlocking算法的话,4中的系统参数失效!!!(这个是从http://hongjiang.info/java8-nativeprng-blocking/看到的) 
7.一般使用SecureRandom不需要设置Seed,不需要设置算法,使用默认的,甚至一个静态的即可,如果有需求的话可以在运行一段时间后setSeed一下

文章参考

1:tp://hongjiang.info/java8-nativeprng-blocking/

2:https://blog.csdn.net/bigtree_3721/article/details/85085413

3:https://blog.csdn.net/upshi/article/details/54907464


————————————————
版权声明:本文为CSDN博主「guorun18」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/guorun18/article/details/101226799
打赏
打赏
关注公众号
公众号
类别:Java| 阅读(409)| 赞 (0)
评论
暂无评论!
发表评论
昵  称:

验证码:

内  容:

    同时赞一个 赞