JAVA originally used the traditional BIO, why did NIO develop later?
First look at the traditional thread model diagram based on synchronous blocking IO(BIO).
BIO mainly has the following disadvantages:
1. As can be seen from the thread model diagram, this model is very resource-consuming due to the limited number of threads.
Finally, it can't bear the demand of high concurrent connection.
2. Low performance, because of frequent context switching, resulting in low cup utilization.
3. Poor reliability, because all IO operations are synchronous, even business threads, so the IO operations of business threads may be blocked.
This will cause the system to rely too much on the real-time situation of the network and the processing capacity of external components, and the reliability will be greatly reduced.
The above reasons are the important reasons why early high-performance servers chose C/C++ instead of JAVA development.
In order to solve the above problems, NIO was born. The following is the thread model diagram of NIO.
1.NIO adopts the reactor thread model, and each reactor aggregates a multiplexer selector, which can register, monitor and poll at the same time.
There are hundreds of channels, so an IO thread can handle many client connections at the same time. The thread model is optimized as 1: n (n
Or M:N(M is usually the number of cup cores+1)
2. Avoid frequent context switching of IO threads and improve the efficiency of the CUP.
3. All IO operations are asynchronous, and the IO operations of business threads don't have to worry about blocking, so the system reduces the real-time situation of network and external components.
Dependence of processing power
Why not use JDK native NIO directly and choose Netty framework instead?
Let's take a look at the timing diagram of the server and client in JDK NIO.
Server:
Customer:
From the figure, we can see the disadvantages of using JDK local NIO.
The class library and API of 1 NIO is quite complicated. To develop with it, you need to master Selector, ByteBuffer, ServerSocketChannel, SocketChannel and so on very skillfully.
2. You need a lot of extra programming skills to help you use NIO. For example, because NIO involves the reactor thread model, you must be very familiar with multithreading and network programming to write high-quality NIO programs.
3. To have high reliability, the workload and difficulty are very great, because the server needs to face the problems of frequent access and disconnection of clients, network flash, semi-package reading and writing, invalid cache and network congestion, which will seriously affect our reliability and it is quite difficult to solve them by using native NIO.
A well-known bug in 4.4. JDK NIO BUG-epoll null polling, when select returns 0, it will lead to null polling of selector, resulting in CUP 100%. The official said that JDK 1.6 fixed this problem, but in fact it only reduced the probability of occurrence and did not fundamentally solve it.
So why use Netty?
1.API is simple and easy to use, and the development threshold is low.
2. Powerful, preset multiple encoding and decoding functions, and support multiple mainstream protocols.
3. The customization ability is high, and the communication framework can be flexibly extended through ChannelHandler.
4. High performance. Compared with many mainstream NIO frameworks, Netty has the highest comprehensive performance.
5. High stability, and solved the BUG of JDK NIO.
6. Its quality and reliability have been well verified by large-scale commercial application.
What services can Netty provide?
1. Developing asynchronous non-blocking TCP network applications
2. Develop asynchronous non-blocking UDP network applications.
3. Develop asynchronous file transfer program.
4. Develop the server and client of asynchronous HTTP program.
5. Provide a variety of codec integration frameworks, including Google Protobuf, JBoss Marshall, Java serialization, compression codec, XML decoding,
String encoding and decoding, users can use it directly.
6. Providing a variety of codec basic class libraries can facilitate the secondary development of private protocol stack codec framework.
7. The pipeline processing mechanism based on responsibility chain can intercept and customize network events conveniently.
8. All IO operations are asynchronous. Users can actively obtain the results through the Future-Listeren mechanism, or take the initiative to notify after the IO thread finishes the operation.
User business threads do not need to wait synchronously.
9. heartbeat mechanism based on link idle event monitoring.
10. Flow control and shaping
......