What Java nio bug in the end is empty polling

Editor's Note: Java nio empty polling bug that is Java nio epoll empty polling question in the Linux system.

Linux epoll mechanism is an efficient IO multiplexing method, compared to the mechanism for the select and poll. Which is efficient in that event into fd-based kernel accomplished based on red-black tree + linked list data structure implemented in the kernel, the list of events stored fd has set, and then returns to the calling application when epoll_wait, by the application to handle these events fd.

Use IO multiplexing, general default under Linux is epoll, Java NIO default mechanism in Linux is epoll, epoll but the JDK implementation is flawed, the most famous java nio epoll bug is even a concern of select polling returns the number of events is 0, NIO still continue to be blocked from select this Selector.select()/Selector.select(timeout)up out of the wake, leading to 100% of the issue CPU. As shown below:

So what's the cause of this problem is? In fact, https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6670302 the already explained very clearly, for example, the following scenario is a reproducible 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

Problem scenario described above is connected to the emergence of RST, because poll and epoll event for eventSet sudden interruption of connection socket will return a collection set to POLLHUP or POLLERR, eventSet set of events has changed, which led Selector will wake up, leading to CPU 100% problem. Fundamental reason is that JDK did not deal with this situation, such as in SelectionKey there is no definition of the type of abnormal events.

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;
}

Since nio epoll bug exists, it can not circumvent it? The answer is yes, such netty very cleverly circumvent this problem, its processing mechanism is that if this happens, and the number of occurrences exceeds the SELECTOR_AUTO_REBUILD_THRESHOLD (default 512), call the rebuildSelector () were Selecttor reconstruction, so It occurred before do not have control of abnormalities that are connected. Because the reconstruction is based on SelectionKey event corresponding connection to re-register.

The problem was first discovered at 6 Java, then many versions claiming to solve the problem, but in fact only reduce the frequency of occurrence of the bug, the current from the Internet to search for information display, Java 8 there is still the problem ( when Thrift encountered JDK Bug epoll ).

Finally together under analysis, problem nio epoll bug is not a linux epoll, but when JDK epoll not consider themselves to achieve this situation, or because other systems do not have this problem, Java for packaging (such as SelectionKey in four types of events ) unity and not to deal with?

Under this thinking, if you want to level up from java nio solve this problem, how to do it?

One is the type of event SelectionKey nio add new kind of "error" type, such as for linux epoll in epollhup and epollerr, if such an event occurs, the proposed program directly close socket, but relatively speaking this way for the current nio SelectionKey changes a little big, because SelectionKey definition jdk currently is for all platforms; for there is a jdk nio packages for epoll, epoll for the epollhup and epollerr events, internal epoll package deal directly with such close socket, but this program is also a little embarrassed that it may retain the upper application code also cited problems with the socket, then the best application is able to perceive this situation be handled better.

Java nio idling long-standing problem, the general procedure is to block out the problem JDK5 / 6 by way of the new Selector, therefore, for developers in terms of, or try to update to the latest version of the JDK, or use the NIO framework as Netty, Grizzly and other research and development, in order to avoid more problems.

Recommended Reading

Welcome to a small partner concerned [TopCoder] Read more exciting good text.

What Java nio bug in the end is empty polling

Guess you like