Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to build the Netty development environment in traditional BIO programming. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

1.1 traditional BIO programming

The basic model of network programming is the Client/Server model, that is, the two processes communicate with each other, in which the server provides location information (bound IP address and listening port), the client initiates a connection request to the address monitored by the server through the connection operation, and establishes the connection through the three-way handshake. if the connection is established successfully, the two sides can communicate through the network socket (Socket).

In the development based on the traditional synchronous blocking model, ServerSocket is responsible for binding the IP address and starting the listening port; Socket is responsible for initiating the connection operation. After the connection is successful, the two sides communicate synchronously through the input and output streams.

1.1.1 BIO communication model diagram

First of all, we are familiar with the server communication model of BIO through the communication model diagram shown in figure 2-1:

In the server with BIO communication model, an independent Acceptor thread is usually responsible for listening to the client's connection. After receiving the client connection request, it creates a new thread for each client to process the link. After the processing is completed, it returns the response to the client through the output stream, and the thread is destroyed. This is a typical one-request-reply communication model.

Figure 1-1 synchronous blocking 1 stroke 0 server communication model (1 client 1 thread)

The biggest problem of this model is the lack of flexible scalability. When the concurrent access volume of the client increases, the number of threads on the server is proportional to the number of concurrent visits on the client at 1:1. Because threads are very valuable system resources of the Java virtual machine, when the number of threads expands, the performance of the system will decline sharply, as the concurrent access volume continues to increase. Problems such as thread stack overflow and failure to create new threads will occur in the system, which will eventually lead to process downtime or deadlock, and can not provide external services.

1.2 pseudo-asynchronous Ihamo programming

In order to solve the problem that a link faced by synchronous blocking Istroke O needs a thread, its thread model was later optimized. The back end handles requests from multiple clients through a thread pool, forming a proportional relationship between the number of clients M: the maximum number of threads N in the thread pool, in which M can be much larger than N, and thread resources can be flexibly deployed through the thread pool to set the maximum thread value. Prevent thread exhaustion due to massive concurrent access.

Next, combined with the connection model diagram and the source code, we analyze the pseudo-asynchronous Imax O to see if it can solve the problem faced by the synchronous blocking Imax O.

1.2.1 pseudo-asynchronous Istroke O model diagram

Using thread pools and task queues, we can implement a pseudo-asynchronous Imax O communication framework, whose model diagram is shown in figure 1-2.

When a new client is connected, the Socket of the client is encapsulated as a Task (the task implements the java.lang.Runnable interface) and delivered to the thread pool at the back end for processing. The thread pool of JDK maintains a message queue and N active threads to process the tasks in the message queue. Because the thread pool can set the size of the message queue and the maximum number of threads, its resource consumption is controllable, no matter how many clients access concurrently, it will not cause resource exhaustion and downtime.

Figure 1-2 pseudo-asynchronous Istroke 0 server communication model (M: n)

In fact, pseudo-asynchronous Iripple O is only a simple optimization of the previous Imax O threading model, and it can not fundamentally solve the problem of communication thread blocking caused by synchronous Iripple O. Let's briefly analyze the cascade failure that will be caused if the response time of the other party is too long.

1. The processing on the server side is slow, and it takes 60 seconds to return the reply message, which usually requires only 10ms.

two。 The thread with pseudo-asynchronous IWeiO is reading the response of the failed service node, and because the read input stream is blocked, it will be blocked synchronously for 60s.

3. If all available threads are blocked by the failed server, all subsequent Icano messages will be queued in the queue.

4. Because the thread pool is implemented with a blocking queue, subsequent queuing operations will be blocked when the queue is full.

5. Because there is only one Acctor thread in the front end to receive client access, after it is blocked by the synchronous blocking queue of the thread pool, the new client request message will be rejected and the client will have a large number of connection timeouts.

6. Because almost all connections time out, the caller will assume that the system has crashed and cannot receive new request messages.

1.3 NIO programming

Before we introduce NIO programming, we need to clarify a concept: what exactly is the abbreviation of NIO?

Some people call it NewI/O, because it is new to the previous Imap O class library, so it is called NewI/O, which is its official name. However, because the old Non-block O class library is blocking Non-block O, the goal of the New I hand O class library is to make the NIO support non-blocking IAccord O, so more people like to call it non-blocking iUnip O (non-blocking iUnip O). Because the non-blocking iUnip O is more able to reflect the characteristics of non-blocking iUnip O, the NIO used in this paper all refers to non-blocking iUnip O.

Corresponding to the Socket class and the ServerSocket class, NIO also provides two different socket channel implementations of SocketChannel and ServerSocketChannel. Both of these new channels support both blocking and non-blocking modes. Blocking mode is very simple to use, but its performance and reliability are poor, while non-blocking mode is just the opposite. Generally speaking, developers can choose the appropriate mode according to their own needs. Generally speaking, applications with low load and low concurrency can choose synchronous blocking IBO to reduce programming complexity, but for network applications with high load and high concurrency, they need to use NIO's non-blocking mode for development.

1.4 AIO programming

NIO2.0 introduces the new concept of asynchronous channel and provides the implementation of asynchronous file channel and asynchronous socket channel. The asynchronous channel provides two ways to obtain the operation result:

The result of an asynchronous operation is represented by the java.util.concurrent.Future class

Pass in a java.nio.channels when performing an asynchronous operation

The implementation class of the CompletionHandler interface serves as a callback for the completion of the operation.

The asynchronous socket channel of NIO2.0 is the real asynchronous non-blocking Imax O, which corresponds to the event-driven Imax O (AIO) in UNIX network programming. It can read and write asynchronously without polling the registered channel through a multiplexer (Selector), thus simplifying the programming model of NIO.

1.5 comparison of several Icano models

Due to the great differences in threading model, API and so on, the usage of different Icano models is also very different.

Since the previous sections have focused on the API and usage of these I-picks, this section will focus on the functional comparison of these I-picks. As shown in Table 2-1.

Table 1-1 comparison of the functions and characteristics of several Istroke O models

1.6 introduction of the mainstream NIO framework in the industry

With the development of mobile Internet and the arrival of big data era, large-scale distributed service framework and distributed flow computing framework have become the mainstream of architectures. the communication between distributed service nodes is often in the form of internal connections, such as FaceBook's Thrift protocol. In order to improve the communication throughput and performance between nodes, the mainstream internal communication frameworks use NIO framework. For large companies, teams with deep technology accumulation may use self-developed NIO framework to meet personalized or industry-specific needs, but most architects will choose the industry mainstream NIO framework for asynchronous communication development.

At present, there are two main NIO frameworks in the industry: Mina and Netty, both of which use ApacheLICENSE-2.0 for open source. The difference is that Mina is the official NIO framework of the Apache Foundation. Netty used to be the NIO framework of Jboss. Later, it applied for the netty.io domain name independently from Jboss, broke away from Jboss, and reconstructed the version, resulting in the upward compatibility of API.

Mina and Netty also have a history. The architect of the original version of Mina was TrustinLee. Later, for a variety of reasons, TrustinLee left the Mina community to join the Netty team, redesigned and developed Netty. Many readers will find the shadow of Mina in Netty, the architectural ideas of the two frameworks also have a lot of similarities, and even some code are very similar, this is the reason.

At present, Mina and Netty are widely used, and many open source frameworks use both as the underlying NIO framework. For example, Avro, the communication component of Hadoop, uses Netty as the underlying communication framework.

Openfire uses Mina as the underlying communication framework, which is more active than the Mina,Netty community and has a wider range of applications.

1.7 Why choose Netty

1.7.1 reasons for not choosing Java Native NIO programming

Now let's summarize why developers are not recommended to develop directly using JDK's NIO class library for the following reasons.

1. NIO's class library and API are complicated and troublesome to use, so you need to be proficient in Selector, ServerSocketChannel, SocketChannel, ByteBuffer and so on.

two。 Additional skills are required, such as familiarity with Java multithreaded programming. This is because NIO programming involves Reactor mode, and you must be very familiar with multithreading and network programming in order to write high-quality NIO programs.

3. The reliability ability is made up, the workload and difficulty are very large. For example, the client faces some problems, such as disconnection and reconnection, network flash disconnection, half-packet read and write, failure cache, network congestion and abnormal code flow, and so on. The characteristic of NIO programming is that the function development is relatively easy, but the workload and difficulty of reliability capability complement are very large.

4. JDK NIO's BUG, such as the infamous epoll bug, causes Selector empty polling, resulting in CPU 100%. Officials claim that the problem was fixed in the JDK1.6 version of update18, but the problem persisted until the JDK1.7 version, except that the probability of the BUG was reduced, and it was not fundamentally resolved. The BUG and the list of questions related to the BUG can be found in the link below.

Http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933

Http://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719

For the above reasons, in most scenarios, it is not recommended to use JDK's NIO library directly unless you are proficient in NIO programming or have special requirements. In most business scenarios, we can use the NIO framework Netty for NIO programming, which can be used as both a client and a server, and at the same time

Support for UDP and asynchronous file transfer, very powerful.

1.7.2 reasons for choosing Netty

Netty is one of the most popular NIO frameworks in the industry, and its robustness, function, performance, customizability and scalability are second to none among similar frameworks. It has been verified by hundreds of commercial projects, such as Hadoop's RPC framework avro uses Netty as the underlying communication framework; many other mainstream RPC frameworks in the industry also use Netty to build high-performance asynchronous communication capabilities.

Through the analysis of Netty, we summarize its advantages as follows:

API is easy to use and has low development threshold.

Powerful, preset a variety of codec functions, support a variety of mainstream protocols

The customization ability is strong, and the communication framework can be flexibly extended through ChannelHandler

High performance. Compared with other mainstream NIO frameworks in the industry, Netty has the best overall performance.

Mature and stable, Netty fixes all the discovered JDK NIO BUG, and business developers no longer need to worry about NIO's BUG

The community is active, the iteration cycle of the version is short, and the BUG found can be repaired in time. At the same time, more new features will be added.

After a large-scale commercial application test, the quality has been verified. It has been successfully used in many industries, such as the Internet, big data, online games, enterprise applications, telecommunications software and so on, which proves that it can fully meet the business applications of different industries.

Because of these advantages, Netty has gradually become the preferred framework for Java NIO programming.

The architecture diagram of Netty is shown below.

1.8 Construction of Netty development environment

First of all, assume that you have installed JDK1.7 on this machine, configured JDK's environment variable path, and downloaded and started the IDE tool Eclipse correctly. If you are a Java beginner and have never built a Java development environment on this machine, it is recommended that you first choose a book or course on the basics of Java.

If you are used to using other IDE tools for Java development, such as NetBeans IDE, you can also run the starter routines in this section. However, you need to modify and adjust the configuration according to the IDE you actually use. This book uniformly uses eclipse-jee-kepler-SR1-win32 as a Java development tool.

1.8.1 download Netty Class Library

Visit Netty's official website http://netty.io/, and select to download the 4.1.5.Final package from the "Downloads" tab, including the source code, compiled class library and Java Doc,18.1M. The decompressed package is shown below.

At this point, you will find that it contains the .jar package and source code of each module, because we use Netty directly as a binary class library, so you only need to get netty-all-4.1.5.Final.jar.

1.8.2 Construction of development project

Import netty-all-4.1.5.Final.jar into the lib directory of the Java project (the lib directory needs to be built by yourself), and right-click netty

-all-4.1.5.Final.jar, in the pop-up menu, select add .jar package to Build Path to complete the construction of the Netty development environment.

This is the end of the article on "how to build the Netty development environment in traditional BIO programming". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.