你好，我是yes。

今天聊的也是一個老生常談的問題了：JDK Selector 的空輪詢 bug。

今天來簡單的扒一下，這玩意大概能追溯到 06 年，并且基于這個 BUG 我們再發(fā)散下，看看能給我們什么啟發(fā)。

追溯

最近我不是一直在寫 Netty 系列嘛，我想談到 Netty ，但凡你在網(wǎng)上看過相關(guān)資料，那肯定會提到 JDK NIO 在 Linux 系統(tǒng)下空輪詢的 bug，就是調(diào)用 Selector.select(timeout)，即使沒事件發(fā)生，也不會阻塞 timeout 時間，而是立馬 return，這樣的空輪詢導致 CPU 100%。

產(chǎn)生這個 bug 大致的原因我講下：連接突然中斷，poll 和 epoll 會被 POLLHUP 或者 POLLERR 事件喚醒，于是 Selector 就被喚醒了，但是 JDK Selector 一看，沒事件(JDK只定義了CONNECT、READ、WRITE、ACCEPT這幾個事件)需要處理啊?

然后就又循環(huán)了....沒事件要處理啊，然后就又循環(huán)了....沒事件要處理啊，然后就又循環(huán)了....

如此往復，空輪詢使得 CPU 100%。

這個 BUG 真算是個老黃歷了，我查了查 JDK 的 bug 庫，大致 13 年 3 月份之后就沒提相關(guān)的 bug 了，而且按照官方的說法這也和 Linux 版本有關(guān)，至今應該沒這問題了?(我不確定)。

我們來回顧一下 bug 庫的歷史。

我查了下最早提到 Selector(底層用的是 poll 或者 epoll) 在 Linux 不會阻塞的 BUG 是在 06 年 3 月 24 日。

可以看到，這 Resolved 的日期有點長，隔了一年，也就是 06 提的 07 年才說修復了，不過當天是給了個解決方案的：

解決方案簡單粗暴，就是把抽風不阻塞的 Selector 刪了，然后創(chuàng)建個新的，取而代之。(有時候簡單粗暴的就是最好的)

我再往后找了找 Selector 的 bug ，發(fā)現(xiàn) 08 年還有 bug(不是說修復了嗎?)，并且處理的日期是 13 年!最終結(jié)果是無法修復，相關(guān)的是 JDK 6 版本。

同 13 年還有類似的 bug ，不過是在 JDK 7 版本上，最終 resolution 是不完整的修復!

從這個處理時間和結(jié)果來看，我個人推斷 JDK 對此 bug 的態(tài)度是消極的，認為這是 Linux 自身的 bug 導致的現(xiàn)象(同為程序員習慣性地甩)。

從 JDK-6670302 的評價就可以看出：

大致的意思就是：升級下 Linux 內(nèi)核版本(2.4版本有這個問題)就好了，2.6 版本發(fā)布已經(jīng) 4 年了都，這個修復也沒啥必要了，需求很小。

這其實可以理解。

站在 JDK 開發(fā)者的角度來看：我這代碼在 windows 下運行的好好的，到你 Linux 就不行了?嗯?我的問題?Linux 為什么給我這樣莫名其妙的事件?你中斷喚醒了個什么玩意?

但是站 Linux 開發(fā)者角度來看就不一樣了：嗯?甩鍋給我?明明是你寫代碼沒考慮到這種特殊情況，擱著跟我甩鍋呢?

那站我們 Java 開發(fā)而言：你擱著跟我擱那呢?有 bug 還擱這甩，我管你 JDK 什么情況，你就得給我修!(我相信 JDK 開發(fā)者也是這樣看 Linux 開發(fā)者的)

哈哈哈，真不真實?

總之，我個人覺得這個 bug 之所以會被網(wǎng)上的文章拿出來反復鞭尸.

一是，因為 netty 通過曲線救國的方式，確實避免了那個時間段部署在 Linux 的應用直接用 Java Selector 產(chǎn)生的空輪詢 bug，所以在當時談到 Netty 就值得拿這個說事兒。

二是，天下文章一大抄嘛，懂的都懂。

對了，雖然我查 bug 庫發(fā)現(xiàn)后面確實都沒再有類似的bug，但是網(wǎng)上有文章說在 JDK8 還是重現(xiàn)了這個 bug!

鏈接：https://juejin.cn/post/6844903491505242119

嘖嘖，俗話說得好，靠人不如靠己，Netty 就是靠己來解決這個 bug，也就是上面提到的簡單粗暴的解決辦法!

Netty ：空循環(huán)是吧，我數(shù)數(shù)你循環(huán)幾次，只要到達一定次數(shù)，我就認為你產(chǎn)生 bug 了，于是我就重建一個 Selector，廢棄以前那個已經(jīng)抽風了的 Selector!這樣我管你 JDK 還是 Linux 會不會處理，我這波就是穩(wěn)坐釣魚臺!

這就是 Netty 的解決辦法~所以也不能說是 Netty 修復了 JDK NIO 的 bug ，它只是曲線救國，變相避免了這個 bug 罷了。

這其實能給我們?nèi)粘５拈_發(fā)提供一點思路，有時候求人不如求己，對于二方、三方的接口還是報以質(zhì)疑的態(tài)度去看待，不要過度的相信他們，特別是三方的接口，一定要做好對方掛掉或者返回奇怪結(jié)果的準備。

我之前對接某大廠的接口，返回值就無聲無息的變了，沒有任何公告和通知，就是那種你認為不可能會變的值。比如一個返回城市名的接口，正常返回叫杭州市，它莫名其妙變了個杭州市(常用)。當然我只是舉個例子哈，具體是啥不方便說。

還有之前對接過另一個大廠的接口，那時候他們的服務幾乎屬于要掛的情況，返回的賊慢，經(jīng)常超時，這種我還是有經(jīng)驗的，起初就我設置了接口超時等待響應時間是 3s，而對方服務有問題，往往都超過了 3s，導致我們拉不到數(shù)據(jù)。

然后我向?qū)Ψ教崃斯危瑢Ψ骄谷蛔屛野殉瑫r等待時間調(diào)整到 10s，我聽得都傻了，正常返回 100ms 的接口，讓我設個 10s，這是讓我跟著他們的服務一起掛是嗎。

遇到這種情況可千萬別聽對方的，你得想到這就是在拖垮你的應用，你設置的超時等待的時間越久，線程被占用時間就的越長，那其他被的請求不就沒線程去處理了嘛，然后請求就堆積了，最終你的應用就全部崩盤了。

也虧對方想得出來這種回復，遇到這種類似的情況，如果你個人拿捏不準，及時找你同事或者領(lǐng)導討論下，別傻傻的聽他的就改了。

你看看所謂的大廠的接口也都這樣，總而言之，對待二方、三方接口，要多加個心眼，一定要做好判空、降級等等情況。

我發(fā)現(xiàn)有些新同學就很不喜歡判空，因為覺得多寫一個 if 很丑陋，嘖嘖，年輕還是太年輕了，沒遭受過毒打!

所以，你們遇到三方最惡心的場景是什么?拿到留言區(qū)給大家樂呵樂呵?

好了，今天就扯到這兒~

我是yes，從一點點到億點點，我們下篇見~