Junit4 一直处于运行中的排查过程

  新买了一个Macbook Pro . 之前的工程搬家过来, 这天要跑个单元测试。 发现Junit4 一直处于运行中。没有错误信息,没有用例执行结果。遂开始排查原因。

  这里插一句,苹果芯片的Mbp还是很好用的,除了性能够用之外,最主要是安静+不热。 这对比我之前的i7版本的真是太明显了。 之前的i7在外接显示器的情况下,风扇狂转,还降频。苹果抛弃Intel还是有道理的。

  回正题, 这类比较诡异问题的排查,一般思路就是猜+试 ,但试和猜的逻辑要清晰。本文主旨也是在于思路总结。

 

  一、测试类是不是写的有问题?

  很好排查,跑跑其他之前写的测试类, 果然也不好用了。 说明跟具体的测试类无关。

  

  二、是工程的问题还是我自身环境的问题?

  小X, 我这儿为啥跑不了单元测试了。 你试试能跑了。 小X: “我这里可以跑,没问题”。 可见应该跟我的环境配置有关。 

  ——持续在执行中,且没有错误,并且与个体环境有关。 如果有经验的同学,很容易想到,这可能说明,测试过程在正常执行,只是非常缓慢。环境相关的性能问题,往往与网络有关。

  

  三、化简工程后,是否正常工作?

  实际项目的工程往往比较复杂, 管理的Bean动辄,几百上千。 这些Bean可能有各种初始化方法, 阻塞了程序的启动,导致了Junit 卡在Spring上下文建立的过程中。测试过程就无法开始运行。

  因此,缩小扫描路径范围, 对一个依赖其他Bean较少的Bean做单元测试。 发现执行正常。

  ——这说明应该确实是卡在了某些Bean的创建过程中

 

  四、缩小范围

  从上面的试验结果很容易想到,如果逐步将Beans加入到扫描路径,就可以定位出具体是哪个Bean引起的阻塞问题。经过尝试发现,工程用到了dubbo,其中的 provider service 越少,@Test执行的越快,当多到一定程度时,

  就会表现为,一直处于运行中的状态了。

  ——这里已经可以定位到,导致问题的表面原因了。猜测可能是dubbo与注册中心的网络通信过程,造成的影响。

  

  五、 源码调试

  开源的好处是,源码之前了无秘密,但通常源码也没那么容易看懂 o(* ̄︶ ̄*)o。 跟了一段执行过程的源码,暂时没有发现明确的原因

  ——源码面前了无秘密肯定是真理,耐心跟一定会发现原因的。

  

  六、柳暗花明

  跟源码跟的不耐烦之际,觉得这么调有点费劲。想在忙碌的过程中直接调试器暂停执行,也许会断到引起阻塞的问题代码附近。于是,重新调试执行测试,在等待一段超出正常范围的时间后,按下调制器的暂停。

  通过调用栈往上找找,果然是在dubbo的包内。观察了下附近有一个非常可疑的。

InetAddress.getLocalHost().getHostAddress()

  ChatGpt了下,Gpt说:
  注意:在生产环境中,反复调用 InetAddress.getLocalHost().getHostAddress() 是不推荐的,因为这可能是一个耗时的操作。通常,获取本地IP地址是一个一次性的任务,应该在应用程序启动时执行,并缓存结果以供后续使用。

  然后阅读了附近的源码,发现dubbo当取得prodiver 的hostip 是 127.0.0.1 或者 localhost 时。会调用这个方法, 取得一个网络上的IP。(例如192.168.1.X之类)。

  尝试将prodiver 的 host 从 127.0.0.1  配置为 网络IP后, 问题解决。

 

  总结:

  问题的原因是当provider host配置为 127.0.0.1 时,会调用耗时操作。 当provider 提供的service 很多时。就会成倍放大这个耗时操作的时间。这个原因跟猜测,以及经验,现象都是能相互验证的。

 

  宝贵经验:

  1. InetAddress.getLocalHost().getHostAddress()  是一个耗时操作,在某些网络环境下可能非常慢。

  2.今后遇到这种一直执行中不报错的情况,应该直接点暂停,读源码 -_-||。

  

  

 

posted @ 2023-06-28 11:50  锅叔  阅读(283)  评论(0编辑  收藏  举报