It is well known that some support for Java NIO and NIO2 has been added in recent versions of Java, while one of the most celebrated strengths of the NodeJS technology stack is its high-performance IO, so today we will discuss the underlying technologies that support these technologies.
One question to ask before we begin is:
Why didn’t NodeJS and Java NIO2 appear earlier?
Answer: PERSONALLY think is the bottom support technology is not mature.
So what are the underlying technologies? Yes, I think many of you have guessed, operating system technology. The two concepts proposed in this paper, Java NIO2 and NodeJS, are all user-mode technologies or application-layer technologies without exception, and these application-layer technologies run on the OS. At the same time, with the progress of the operating system, the programming model that can be supported is more and more rich. It’s fair to say that both technologies have evolved to take advantage of the benefits of operating system advances. Generally speaking, the first technology to benefit from this dividend must be CC++, because OS advances provide most of the latest system calls, and CC++ is the most convenient to use these system calls, but also the most complex. In order for other platforms to achieve the same performance, they have to evolve, encapsulate, and make those bonuses available to users, and once that platform stagnates, it’s time for that platform to die. The more convenient encapsulation is for the user, the more user-friendly it is, and the more people are likely to use it. While many people can quickly write code for these platforms, they often miss the point because they don’t fundamentally understand the motivations and principles behind these technologies. The technologies discussed below are the underlying technologies related to these two technologies.
The following five IO models are essential to any OS design.
1., blocking I/O
, (2) from the I/O
Multiplexing (select, poll and epoll)
·4. Signal Driven I/O (SIGIO)
·5. Asynchronous I/O (the POSIX aiO_ functions)
As shown in the figure, this IO model has the advantage of simple programming and is one of the earliest IO models supported by OS. Its disadvantage is that system call blocks user dynamic thread execution, resulting in CPU time waste and low IO efficiency.
As shown, an improvement to this IO model is that THE IO is non-blocking, but requires long polling, which also wastes CPU clock cycles.
As shown in the figure, this IO model is the most stable IO model available in today’s OS. Most mainstream applications are built on this IO model, such as NodeJS, but these platforms often add a layer of encapsulation on top of this model to support AIO directly.
As shown in the figure, it is recorded that this IO model is rarely adopted by designers due to its lack of performance advantages compared with Model 3 and unstable system support.
As shown, the IO model is the most perfect AIO, programming model is the most simple, but very few supporters can perfect model of OS, online data show that Linux is do these efforts, once the OS progress on this aspect, programming framework, platform and programming model may still need to be greatly simplified.
Although this model is rarely supported by the OS, it does not mean that the AIO model does not exist today. Many frameworks do this, emulating AIO in user mode, allowing users to focus more on the business logic code.
Synchronous and asynchronous are for application and kernel interaction. Waiting until the data is read and then returning is synchronous, directly returning is asynchronous. Blocking and non-blocking are for processes and threads. In blocking mode, the reading or writing thread waits, while in non-blocking mode, the reading or writing thread immediately returns a status value.
