媒介

前几天在测试情形遇到一个很是稀疏的与 dubbo 相干的题目，过后我在网上搜刮了一圈并没有发明相同的帖子或文章，于是便有了这篇。

但愿对还未遇到或正在遇到的伴侣有所辅佐。

征象

征象是这样的，有一天测试在测试情形从头陈设一个 dubbo 应用的时辰发明应用“启动不起来”。

但过几个小时辰之后又能本身逐步规复，并可以或许对外提供 dubbo 处事。

但着实颠末我后续排查发明刚开始着实并不是启动不起来，而是启动速率很是迟钝，以是当应用长时刻启动后才会对外提供处事。

而这个速率慢到居然要耗费 2 个小时。

导致的一个功效是测试完全不敢在测试情形发版验证了，每验证一个成果修复一个 bug 就得等上两个小时，这谁受得了😂。

并且颠末多次调查，确实每次都是耗费两小时阁下应用才气启动起来。

实行办理

最后测试顶不住了，只能让我这个“事情陈诉撰写专家”来看看。

当我得知这个题目的征象时着实完全没当一回事：

都不消想，这不就是主线程阻塞了嘛，先看看是否在初始化的时辰数据库、Zookeeper 之类的连不上导致阻塞了-------来之多次事情处理赏罚的履历汇报我。

于是我把这事打回给测试让他先找运维排查下，不到万不得已不要影响我 Touch fish🐳。

第二天一早看到测试同窗的微信头像跳动时我都已经筹备接管又一句 “跪拜大佬👍” 的回覆时，却收到 “收集统统正常，没人动过，再不办理就要停工了🤬”。

好吧，忽悠不外去了。

起首这类题目的排查偏向应该不会错，就是主线程阻塞了，至于是啥导致的阻塞就不能像之前那样瞎猜了。

我将应用重启后用 jstack pid 将线程快照打印到终端，直接拉到最后看看 main 线程到底在干啥。

前屡次的快照都是很正常：

加载 Spring ---->毗连 Zookeeper ---> 毗连 Redis，都是依次执行下来没有阻塞。

隔了一段后应用确实还没起来，我再次 jstack 后获得如下信息：

翻源码

我一向等了十几分钟再多次 jstack 获得的快照获得的信息都是一样的。

如图所示可见主线程是卡在了 dubbo 的某个要领 ServiceConfig.java 的 303 行中。

于是我找到此处的源码：

简朴来嗣魅这里的逻辑就是要获取本机的 IP 将其注册到 Zookeeper 顶用于其他处事挪用。

再往下跟就如仓库中一样是卡在了 Inet4AddressImpl.getLocalHostName 处。

但这是一个 native 要领，我们应用也基础过问干与不了，最终的征象就是挪用这个当处所法很是耗时。

于是这题目貌似也阻塞在这儿了，没有太多步伐。

最终办理

既然这是一个 native 要领，那声名和应用自己没有啥相关（确实也是这样，这个题目是溘然间呈现的。）

那是否是处事器自己的题目呢，想到在 native 要领里是获取本机的 hostname，那是否和这个 hostname 有相关呢。

这是在我本身的阿里云处事器上测试，真正的测试情形不是这个名字。

拿随处事器 hostname 后再实行 ping 这个 hostname，稀疏的征象产生了：

呼吁刚开始会卡住一段时刻（或许几十秒），然后才会输出 hostname 对应的 ip 以及对应的耽误。

而当我直接 ping 这个 ip 时却能快速相应后头的输出。

最后我实行在 /etc/hosts 设置文件中插手了对应的 host 设置：

xx.xx.xx.xx(ip) hostname 

再次 ping hostname 的结果就和直接 ping ip 一样了。

于是我再次重启应用，统统都正常了。

总结

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!