新买了一个Macbook Pro . 之前的工程搬家过来, 这天要跑个单元测试。 发现Junit4 一直处于运行中。没有错误信息,没有用例执行结果。遂开始排查原因。
这里插一句,苹果芯片的Mbp还是很好用的,除了性能够用之外,最主要是安静+不热。 这对比我之前的i7版本的真是太明显了。 之前的i7在外接显示器的情况下,风扇狂转,还降频。苹果抛弃Intel还是有道理的。
回正题, 这类比较诡异问题的排查,一般思路就是猜+试 ,但试和猜的逻辑要清晰。本文主旨也是在于思路总结。
文章来源地址https://www.toymoban.com/news/detail-504356.html
一、测试类是不是写的有问题?
很好排查,跑跑其他之前写的测试类, 果然也不好用了。 说明跟具体的测试类无关。
文章来源:https://www.toymoban.com/news/detail-504356.html
二、是工程的问题还是我自身环境的问题?
小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.今后遇到这种一直执行中不报错的情况,应该直接点暂停,读源码 -_-||。
到了这里,关于Junit4 一直处于运行中的排查过程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!