What are some good resources explaining how non-blocking IO works under the hood?

Question

We all have learned from trial and error that multiple blocking threads do not scale well, and that we should switch to using NIO where we see possible. Yet, there are not as many resources explaining why non-blocking is better by giving an under-the-hood example of how it actually works.

Answer 1

We all have learned from trial and error that multiple blocking threads do not scale well,

This was true 10 years ago, however in general, using blocking IO and NIO works well enough. Unless you have a very large number of connections and a service which does very little, you can support up to 1000 connections on a modern server comfortably. Don't forget servers are faster now, have much more cores, and people expect servers to do more work. ie the bottleneck is in the application not the IO.

we should switch to using NIO where we see possible.

The main benefit is reduced thread over head. As I mentioned this is not as high as it was when NIO was introduced more than ten years ago.

NIO is much harder to work with so I would suggest only using it if you really need to.

there are not as many resources explaining why non-blocking is better

The explanation is; you use less threads, thus you have a lower overhead. This only matters if the work each thread does is very little.

Note: It is often assumed that NIO mean non-blocking when actually the default behaviour of all the Channels in NIO is blocking. In fact in NIO, only TCP can be configured to be non-blocking. This is the exception rather than the rule.

Note2: the fastest way to handle a small number of connections is to use blocking NIO.

Finally, another benefit of using NIO is reduced copying of data if you use "direct" or native buffers. However, again you need to be doing bulk transfers of data, as soon as you start reading/writing the data in a byte by byte manner eg as text, this overhead swamps the gains you might have made.

by giving an under-the-hood example of how it actually works.

Most of the under the hood differences are either, not as much as you might imagine, or handled entirely by the operating system and thus obscured from Java or even the JVM.