Two depressing exceptions: Java. Lang. stackoverflowerror and java.net. socketexception: broken pipe

After debugging for almost one day, I am tossing and killing me for a bug.

The reason for the bug is that Code When not careful, will:

<textarea cols="50" rows="15" name="code" class="java">Public Boolean isempty () {<br/> return this. queue. isempty (); <br/>}</textarea>
Written:

<textarea cols="50" rows="15" name="code" class="java">Public Boolean isempty () {<br/> return this. isempty (); <br/>}</textarea>
Obviously, A function starts to call itself recursively without limit.
In a short time, the stack of the thread where the function is located will be full, so stackoverflowerror will be thrown.
Once java. Lang. stackoverflowerror is found, it indicatesProgramThere is an endless loop in it, or there are too many recursive layers, so all the stacks allocated by the current thread are used up...


In my program, this java. Lang. stackoverflowerror is an unexpected exception and I didn't catch it. On the contrary, this exception was obtained by Mina. In the Mina framework, once it captures an exception, it will call the exceptioncaught method. By default, this method will disable the session, so the phenomenon is:
If the client extracts the previously used socket from the connection pool for communication, it will report java.net. socketexception: broken pipe.

The reason is that the socket on the server is disabled by the server.
This phenomenon is very similar to the sigpipe signal in Linux C network programming. Although I did not find the correct information, I can probably be sure that the broken pipe exception in Java is caused by sigpipe detection.
A typical scenario of sigpipe generation is that in the client-server architecture, the server proactively closes the socket connection. At this time, the client socket will receive an rst package. If we continue to call the write operation on a socket that has received the RST package, sigpipe will be generated.