管你 JDK 照旧 Linux,我 Netty 稳坐垂纶台!

发布日期:2022-06-18 17:02    点击次数:51

管你 JDK 照旧 Linux,我 Netty 稳坐垂纶台!

你好,我是yes。

今天聊的亦然一个须生常谭的问题了:JDK Selector 的空轮询 bug。

今天来浮浅的扒一下,这玩意巧合能回顾到 06 年,况兼基于这个 BUG 咱们再发散下,望望能给咱们什么启发。

回顾

最近我不是一直在写 Netty 系列嘛,我想谈到 Netty ,凡是你在网上看过相干贵府,那敬佩会提到 JDK NIO 在 Linux 系统下空轮询的 bug,即是调用 Selector.select(timeout),即使没事件发生,也不会膺惩 timeout 本领,而是立马 return,这么的空轮询导致 CPU 100%。

产生这个 bug 毛糙的原因我讲下:结合倏得中断,poll 和 epoll 会被 POLLHUP 或者 POLLERR 事件叫醒,于是 Selector 就被叫醒了,可是 JDK Selector 一看,没事件(JDK只界说了CONNECT、READ、WRITE、ACCEPT这几个事件)需要处理啊?

然后就又轮回了....没事件要处理啊,然后就又轮回了....没事件要处理啊,然后就又轮回了....

如斯往来,空轮询使得 CPU 100%。

这个 BUG 真算是个老通书了,我查了查 JDK 的 bug 库,毛糙 13 年 3 月份之后就没提相干的 bug 了,而且按照官方的说法这也和 Linux 版块关联,于今应该没这问题了?(我不细目)。

咱们来总结一下 bug 库的历史。

我查了下最早提到 Selector(底层用的是 poll 或者 epoll) 在 Linux 不会膺惩的 BUG 是在 06 年 3 月 24 日。

不错看到,这 Resolved 的日历有点长,隔了一年,也即是 06 提的 07 年才说斥地了,不外本日是给了个惩办决策的:

惩办决策浮浅狡滑,即是把抽风不膺惩的 Selector 删了,然后创建个新的,拔旗易帜。(有本领浮浅狡滑的即是最佳的)

我再往后找了找 Selector 的 bug ,发现 08 年还有 bug(不是说斥地了吗?),况兼处理的日历是 13 年!最终后果是无法斥地,相干的是 JDK 6 版块。

同 13 年还有雷同的 bug ,不外是在 JDK 7 版块上,最终 resolution 是不美满的斥地!

从这个处理本领和后果来看,我个人推测 JDK 对此 bug 的格调是无望的,认为这是 Linux 自己的 bug 导致的表象(同为形貌员民风性地甩)。

从 JDK-6670302 的评价就不错看出:

毛糙的风趣即是:升级下 Linux 内核版块(2.4版块有这个问题)就好了,2.6 版块发布也曾 4 年了都,这个斥地也没啥必要了,需求很小。

这其实不错泄露。

站在 JDK 开发者的角度来看:我这代码在 windows 下启动的好好的,到你 Linux 就不行了?嗯?我的问题?Linux 为什么给我这么祸患其妙的事件?你中断叫醒了个什么玩意?

可是站 Linux 开发者角度来看就不雷同了:嗯?甩锅给我?明明是你写代码没斟酌到这种罕见情况,搁着跟我甩锅呢?

那站咱们 Java 开发而言:你搁着跟我搁那呢?有 bug 还搁这甩,我管你 JDK 什么情况,你就得给我修!(我信托 JDK 开发者亦然这么看 Linux 开发者的)

哈哈哈,真不真确?

总之,我个人合计这个 bug 之是以会被网上的著作拿出来反复鞭尸.

一是,因为 netty 通过弧线救国的方法,确乎幸免了阿谁本领段部署在 Linux 的讹诈径直用 Java Selector 产生的空轮询 bug,是以在其时谈到 Netty 就值得拿这个说事儿。

二是,天地著作一大抄嘛,懂的都懂。

对了,天然我查 bug 库发现背面确乎都没再有雷同的bug,可是网上有著作说在 JDK8 照旧重现了这个 bug!

和洽:https://juejin.cn/post/6844903491505242119

啧啧,俗语说得好,靠人不如靠己,gogo亚洲肉体艺术欣赏图片Netty 即是靠己来惩办这个 bug,也即是上头提到的浮浅狡滑的惩办办法!

Netty :空轮回是吧,我数数你轮回几次,唯有到达一定次数,我就认为你产生 bug 了,于是我就重建一个 Selector,毁灭往时阿谁也曾抽风了的 Selector!这么我管你 JDK 照旧 Linux 会不会处理,我这波即是稳坐垂纶台!

这即是 Netty 的惩办办法~是以也不可说是 Netty 斥地了 JDK NIO 的 bug ,它仅仅弧线救国,变相幸免了这个 bug 停止。

这其实能给咱们日常的开发提供少量头绪,有本领求人不如求己,关于二方、三方的接口照旧报以质疑的格调去看待,不要过度的信托他们,相等是三方的接口,一定要做好对方挂掉或者复返奇怪后果的准备。

我之前对接某大厂的接口,复返值就悄然无声的变了,莫得任何公告和奉告,即是那种你认为不可能会变的值。比如一个复返城市名的接口,精深复返叫杭州市,它祸患其妙变了个杭州市(常用)。天然我仅仅举个例子哈,具体是啥不便捷说。

还有之前对接过另一个大厂的接口,那本领他们的就业简直属于要挂的情况,复返的贼慢,频繁超时,这种我照旧有教师的,最先就我配置了接口超时恭候反应本领是 3s,而对方就业有问题,通常都跳跃了 3s,导致咱们拉不到数据。

然后我向对方提了工单,对方果然让我把超时恭候本领挫折到 10s,我听得都傻了,精深复返 100ms 的接口,让我设个 10s,这是让我随着他们的就业沿路挂是吗。

碰到这种情况可千万别听对方的,你得猜测这即是在拖垮你的讹诈,你配置的超时恭候的本领越久,线程被占用本领就的越长,那其他被的申请不就没线程去向理了嘛,然后申请就堆积了,最终你的讹诈就全部崩盘了。

也亏对方想得出来这种修起,碰到这种雷同的情况,要是你个人拿捏不准,实时找你共事或者指令询查下,别傻傻的听他的就改了。

你望望所谓的大厂的接口也都这么,一言以蔽之,对待二方、三方接口,要多加个心眼,一定要做好判空、左迁等等情况。

我发现存些新同学就很不心爱判空,因为合计多写一个 if 很丑陋,啧啧,年青照旧太年青了,没遭受过毒打!

是以,你们碰到三方最恶心的场景是什么?拿到留言区给众人乐呵乐呵?

好了,今天就扯到这儿~

 

我是yes,从少量点到亿点点,咱们下篇见~

 





Powered by 曰批全过程免费视频在线观看网站 @2013-2022 RSS地图 HTML地图