Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

The principle of Selector Mechanism of Java NIO Class Library

2025-04-02 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

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

This article mainly explains "the principle of Selector mechanism of Java NIO class library". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn the principle of the Selector mechanism of the Java NIO class library.

I. Preface

Since the version of J2SE 1.4, JDK has released a new Imax O class library, referred to as NIO, which not only introduces a new and efficient Imax O mechanism, but also introduces the asynchronous mode of multiplexing. The package of NIO mainly contains several abstract data types:

◆ Buffer: a linear table structure that contains data and is used for reading and writing. It also provides a special class for memory-mapped files' Iswap O operations.

◆ Charset: it provides operations for mapping Unicode strings to byte sequences and inverse mapping.

◆ Channels: includes socket,file and pipe pipes, all of which are full-duplex channels.

◆ Selector: multiple asynchronous Istroke O operations are concentrated in one or more threads (which can be thought of as the object-oriented version of the select () function in Unix).

When my college classmate Zhao Kun was using the NIO class library to write relevant network programs, he found some abnormal RuntimeException in Java. The abnormal error message made him start some investigation on the Selector of NIO. When Zhao Kun shared some conjectures and investigations about some of the underlying mechanisms of Selector, we thought it was very interesting, so after a series of investigations with Zhao Kun, we found a lot of interesting things, which led to this article. That's why the author of this article signed both of us.

First of all, Zhao Kun and I are essentially developers from Unix/Linux/C/C++. For Java, this is not our strong point. This article is essentially out of curiosity about Java's Selector, because on the surface, Selector seems to have done something that surprises those of us who come from Selector.

Let me tell you this story.

Second, the beginning of the story: let C++ programmers write Java programs!

No serious memory problems, a large number of rich SDK class libraries, super-easy cross-platform, except for some complaints on performance, C++ programmers will never find Java a very difficult thing. Of course, for the long-term accustomed to using the operating system API (system call System Call), the method of comparing "alternative" operating system resources in Java may feel a little confused, but it remains the same, you only need to have a certain understanding of the object-oriented design pattern, and it won't take long for Java's SDK class library to play as much as you like.

When using Java to design related network programs, the framework that comes to mind at first is multiplexing for those who are born in Cplink +. When they think of multiplexing, they can immediately think of select, poll, and epoll system calls under Unix/Linux. As a result, you are bound to feel friendly when you see the Selector class in Java's NIO. After a little reference to the SDK manual and related routines, a multiplexing framework was presented and a unit test was done at hand. there was no problem, and everything was the same as before. Then tell the brothers that the framework is done, and then we will develop and unit test on Windows, and then integrate the test on the running environment Unix. And secretly thought, cross-platform is good, development activities can be cross-platform.

However, the good times don't last long, and as there is more code, the logic becomes more and more complex. The good framework unexpectedly starts to have an exception in the unit test run on Windows. Looking at the function stack in which the Java runs the exception, the exception is thrown by Selector.open (), and the error message is Unable to establish loopback connection.

"Selector.open () unexpectedly reported an loopback connection error, why not? there is no socket connection for loopback when open. How can you report this error?"

Of course, programs that have been using C _ Java + for a long time will be very familiar with the calls to the operating system. Although all the system calls made by Java's virtual machines are gone, programmers of C _ + must be much more sensitive than those of _ programs.

Third, start the investigation: why is Java so "stupid"!

As a result, the old bird of CumberCraft + downloaded Process Explorer from SystemInternals to see what kind of Loopback Connection it was. Sure enough, I opened the java to run the process and found some TCP/IP links that connect to my own localhost. Then another question arises, "Why? why do you have a connection between yourself and yourself? I don't have a connection to myself in my program. How can I have such a link? and my own port number is actually some strange port."

The problem is becoming more and more strange. Is this all Selector.open () doing something weird? Does Selector.open () want to create a link that connects to itself? Write a program to see:

Import java.nio.channels.Selector; import java.lang.RuntimeException; import java.lang.Thread; public class TestSelector {private static final int MAXSIZE=5; public static final void main (String argc []) {Selector [] sels = new Selector [MAXSIZE]; try {for (int I = 0; I < MAXSIZE; + + I) {sels [I] = Selector.open (); / / sels [I] .close ();} Thread.sleep (30000);} catch (Exception ex) {throw new RuntimeException (ex);}

The program does nothing but Selector.open () five times and then take a 30-second break so that I can use the Process Explorer tool to view the progress. There is no problem with compiling the program. When you run it, you can see the following dialog box in Process Explorer: (unexpectedly, there are 10 connections, we can know from the connection port that they are connected to each other, such as: * connected to the second one, and the second to the second *)

Can not help but admire our Java ah, not to mention whether this is a stupid thing. At the very least, it is certain that Java can catch up with some worms in terms of consuming valuable system resources.

If you don't believe it, try changing the value of MAXSIZE in the above program to 65535, and you will soon find that your program has this error: (about 2000 Selector.open () running on my XP machine)

Exception in thread "main" java.lang.RuntimeException: java.io.IOException: Unable to establish loopback connectionat Test.main (Test.java:18) Caused by: java.io.IOException: Unable to establish loopback connectionat sun.nio.ch.PipeImpl$Initializer.run (Unknown Source) at java.security.AccessController.doPrivileged (Native Method) at sun.nio.ch.PipeImpl. (Unknown Source) at sun.nio.ch.SelectorProviderImpl.openPipe (Unknown Source) at java.nio.channels.Pipe.open (Unknown Source) at sun.nio.ch. WindowsSelectorImpl. (Unknown Source) at sun.nio.ch.WindowsSelectorProvider.openSelector (Unknown Source) at java.nio.channels.Selector.open (Unknown Source) at Test.main (Test.java:15) Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect at sun.nio.ch.Net.connect (Native Method) at sun.nio.ch.SocketChannelImpl.connect (Unknown Source) at java.nio.channels.SocketChannel.open (Unknown Source). 9 more

Fourth, continue to investigate: so cross-platform

Of course, no one writes as many Selector.open () as we do, but it just gives us an idea of what Java is doing behind everyone's back. The above "stupid connections" are on the Windows platform, and if nothing happens, they should be pretty much the same under Unix/Linux.

So we put the above program under Linux and ran. Using the netstat command, you don't see yourself connecting to your own Socket. Seems to be using a different mechanism on Linux than Windows?!

If you don't set up your own TCP connection to Linux, then the file descriptor and port will be saved, right? that is to say, if we call 65535 Selector.open (), there should be no exception.

Unfortunately, in the implementation of running the program, the error is still reported: (about 400 Selector.open (), not as good as Windows)

Exception in thread "main" java.lang.RuntimeException: java.io.IOException: Too many open filesat Test1.main (Test1.java:19) Caused by: java.io.IOException: Too many open filesat sun.nio.ch.IOUtil.initPipe (Native Method) at sun.nio.ch.EPollSelectorImpl. (EPollSelectorImpl.java:49) at sun.nio.ch.EPollSelectorProvider.openSelector (EPollSelectorProvider.java:18) at java.nio.channels.Selector.open (Selector.java:209) at Test1.main (Test1.java:15)

We found that the exception error was "Too many open files", so I came up with the idea of using the lsof command to view the open file.

See that there are some pipe files, a total of 5 pairs, 10 (of course, pipes are always in pairs). This is shown in the following figure.

It can be seen that Selector.open () is not connected with TCP under Linux, but with a pipe pipeline. It seems that this pipe channel is also given to itself. Therefore, we can draw the following conclusions:

1) under Windows, Selector.open () will set up two TCP links with itself. Consumes not only two TCP connections and ports, but also file descriptors.

2) under Linux, Selector.open () will build two pipelines by itself and by itself. It also consumes the file descriptors of both systems.

It is estimated that under Windows, Sun's JVM chooses TCP connections over Pipe, either because of performance problems or because of resource problems. It is possible that the performance of pipes under Windows is slower than that of TCP links, or it is possible that pipes under Windows consume more resources than TCP links. The details of these implementations need to be explored at a deeper level.

At this point, I believe you have a deeper understanding of "the principle of the Selector mechanism of the Java NIO class library". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report