Netty：Unable to load the library netty_transport_native_epoll_x86_64

一、前言

最近在开发过程中发现一个很有意思的问题。在一次应用部署之后就突然无法启动了。于是习惯性的其翻日志，居然发现Netty报错：Unable to load the library netty_transport_native_epoll_x86_64。接着一番骚操作之后发现居然不是这个问题导致的引用无法启动。接下来我就和大家分享一下整个骚操作过程，以及Netty这错误到底是什么玩意。

二、过程分析

事情是这样的，最近在和同事一起开发一个需求。然后一次重启应用之后突然发现无法启动了。根据经验判断应该是程序抛异常了。于是习惯性的去撸了一把启动日志。于是就发现了Netty报错：Unable to load the library netty_transport_native_epoll_x86_64。

看到上述错误第一反应就是这个问题导致了程序无法启动。然后开始自行分析异常，貌似是一个什么Netty的二级制包无法加载。于是尝试重新打包重新发代码，重新发完代码重启之后发现还是这个问题。于是检查发现最近没有修改过pom依赖，也没有修改过设计netty的代码。于是初步估计应该是docker镜像的问题。然后尝试在其他环境启动该应用，发现报同样的错。此时就有些凌乱了（What happed）。

接着开始重新看日志，发现后面有一个业务错误，是同时新增的一个依赖没有注入到Spring，导致依赖注入失败。从而导致应用启动异常。于是解决了该业务问题，重新打包启动引用发现OK了。启动之后，再次去看日志，发现Netty的错误日志仍然存在。于是我就懵逼了，这是什么骚操作？？？

三、Netty报错是什么玩意

出现上诉问题后，本着刨根问底的精神，google了下该错误。终于在github找到了该问题的根本原因。github地址为：https://github.com/netty/netty/issues/7319。

根据该外国友人的描述这个netty的日志只有在debug下才会出现（看上述截图，该日志确实是一个debug日志）。且只是一个提示，在后面会有一个对应so包加载成功的日志。于是我在日志中搜索，果然在上述日志的后面看到加载成功的日志。

那么根据描述，这里涉及到的逻辑大概是：netty在默认的某个路径加载epoll的so包失败，于是打印了个debug的Exception作为提示。然后获取自动切换到其他包路径加载，最后加载成功。

那么问题来了？我们普通都是通过Debug一些业务信息，而不会打印错误信息。为什么这里一个Debug日志还要打印成Error形式，还包含了Exception的线程栈信息。我们可以看到上面的外国友人也提出了质疑："scary" stacktrace is logged if users are running with debug logging, and they wonder if there is an error。这个吓人的栈信息只有在用户开启debug日志才打印，这样会不会让人误以为是一个错误（的确在上述案例中，该日志最初也误导了楼主。楼主以为该日志导致了系统启动失败，把楼主引向了错误的方向）。

针对这个疑问，netty的源码维护者@normanmaurer（之前楼主在github参与讨论过一个关于netty的伪共享代码问题也是该大牛回复的。）也做了如下回复。

该回复的大概意思就是：这个日志打印出来只是为了方便调试，使用者开启debug日志就应该接受debug日志比较noisy，如果觉得这个日志比较noisy，可以关闭netty的debug日志。

所以：Netty的Unable to load the library netty_transport_native_epoll_x86_64这个日志并不是一个错误，而只是一个调试日志而已。要么忽略，要么关闭netty的debug日志。

四、惯例

如果你对本文有任何疑问或者高见，欢迎添加公众号共同交流探讨（添加公众号lifeofcoder可以获得”Java高级架构“上10G的视频和图文资料哦）。

 

 

 

 

本文地址：https://blog.csdn.net/hilaryfrank/article/details/110490618