Selector's understanding

For NIO This estimate was a concern several years ago, known as non-blocking, thread pool, buffer pool, io mode select,poll,epoll, and even epoll in Et,lt.

But recently had time to actually see the source of the Netty, only to find that the original selector can be so used, in my impression that a service in fact a selector enough, and its own understanding of selector is not very deep, today on the big talk about their own understanding of it.

The JVM encapsulates many features of the operating system, which is difficult to understand, selector my understanding is a handle, more like a tree, the application layer to do things to bind to this tree, the corresponding things change, the operating system will change the state of the bottom, Then through the method of Java Select, we can get the change of the connection. In fact, this block can not be limited to the network, Libevent pipeline model is also through the selector notice.

such as in the network after binding the address, you can bind the current ServerSocket to selector above, when there is a new connection, will change the state of ServerSocket, select can get a connection socket, Then the socket is to read the data, the socket is bound to the selector and interested in the reading of the network. This is similar to writing, which completes the communication of the network message.

In the Netty, the boss and the worker (I see the version of the lower 3.) The boss will only bind the connected SELECOTR, and the data read and write are bound to other selector above, This gives full play to the multi-core advantage. Each boss or worker thread will have its own selector, and the EPOLLCPU utilization of Linux is handled.

Selector's understanding