編者注：Java nio 空輪詢bug也就是Java nio在Linux系統下的epoll空輪詢問題。

epoll機制是Linux下一種高效的IO複用方式，相較於select和poll機制來說。其高效的原因是將基於事件的fd放到核心中來完成，在核心中基於紅黑樹+連結串列資料結構來實現，連結串列存放有事件發生的fd集合，然後在呼叫epoll_wait時返回給應用程式，由應用程式來處理這些fd事件。

使用IO複用，Linux下一般預設就是epoll，Java NIO在Linux下預設也是epoll機制，但是JDK中epoll的實現卻是有漏洞的，其中最有名的java nio epoll bug就是即使是關注的select輪詢事件返回數量為0，NIO照樣不斷的從select本應該阻塞的Selector.select()/Selector.select(timeout)

中wake up出來，導致CPU 100%問題。如下圖所示：

那麼產生這個問題的原因是什麼的？其實在 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6670302 上已經說明的很清楚了，比如下面是bug復現的一個場景：

A DESCRIPTION OF THE PROBLEM :
The NIO selector wakes up infinitely in this situation..
0. server waits for connection
1. client connects and write message
2. server accepts and register OP_READ
3. server reads message and remove OP_READ from interest op set
4. client close the connection
5. server write message (without any reading.. surely OP_READ is not set)
6. server's select wakes up infinitely with return value 0
 

上面的場景描述的問題就是連接出現了RST，因為poll和epoll對於突然中斷的連線socket會對返回的eventSet事件集合置為POLLHUP或者POLLERR，eventSet事件集合發生了變化，這就導致Selector會被喚醒，進而導致CPU 100%問題。根本原因就是JDK沒有處理好這種情況，比如SelectionKey中就沒定義有異常事件的型別。

class SelectionKey {
    public static final int OP_READ = 1 << 0;
    public static final int OP_WRITE = 1 << 2;
    public static final int OP_CONNECT = 1 << 3;
    public static final int OP_ACCEPT = 1 << 4;
}
 

既然nio epoll bug存在，那麼能不能規避呢？答案是有的，比如netty就很巧妙的規避了這個問題，它的處理機制就是如果發生了這種情況，並且發生次數超過了SELECTOR_AUTO_REBUILD_THRESHOLD（預設512），則呼叫rebuildSelector()進行Selecttor重建，這樣就不用管之前發生了異常情況的那個連線了。因為重建也是根據SelectionKey事件對應的連線來重新註冊的。

該問題最早在 Java 6 發現，隨後很多版本聲稱解決了該問題，但實際上只是降低了該 bug 的出現頻率，目前從網上搜索到的資料顯示，Java 8 還是存在該問題（當 Thrift 遇到 JDK Epoll Bug）。

最後一起來分析下，nio epoll bug不是linux epoll的問題，而是JDK自己實現epoll時沒有考慮這種情況，或者說因為其他系統不存在這個問題，Java為了封裝（比如SelectionKey 中的4個事件型別）的統一而沒去處理？

這裡思考下，如果想要從java nio層面上來解決這個問題，該如何做呢？

一種是nio事件型別SelectionKey新加一種"錯誤"型別，比如針對linux epoll中的epollhup和epollerr，如果出現這種事件，建議程式直接close socket，但這種方式相對來說對於目前的nio SelectionKey改動有點大，因為SelectionKey的定義目前是針對所有jdk平臺的；還有一種是針對jdk nio 對epoll的封裝中，對於epoll的epollhup和epollerr事件，epoll封裝內部直接處理，比如close socket，但是這種方案也有一點尷尬的是，可能上層應用程式碼還保留有出現問題的socket引用，這時最好是應用程式能夠感知這種情況來處理比較好。

Java nio空轉問題由來已久，一般程式中是通過新建Selector的方式來遮蔽掉了JDK5/6的這個問題，因此，對於開發者來講，還是儘量將JDK的版本更新到最新，或者使用NIO框架如Netty，Grizzly等進行研發，以免出更多的問題。

推薦閱讀

• Netty 入門，這一篇文章就夠了
• Netty 啟動流程解析
• Netty 處理連線那些事
• Java常見幾種動態代理的對比
• 程式設計師必看| mockito原理淺析
• Eureka 原理分析
• MQ初窺門徑【面試必看的Kafka和RocketMQ儲存區別】
• java lambda 深入淺出

歡迎小夥伴關注【TopCoder】閱讀更多精彩好文。

相關推薦