Open source software supply chain lighting plan, waiting for you>>>

Java.net.socketexception: broken pipe blog classification: exception

java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
	at java.io.DataOutputStream.flush(DataOutputStream.java:106)
	at peer.UploadThread$SendToPeerThread.run(UploadThread.java:179)
	at java.lang.Thread.run(Thread.java:680)

A lot of information has been searched on the Internet, and it is said that this error is due to the connection limit of Linux/Unix, or multiple threads reading and writing the same socket

The network structure of UNIX/Linux is slightly different from that of windows, at least in Java network programming (no research, but I have encountered the same problem!) Java.net.socket xception:Broken pipe The reason for this exception is that you use multiple threads to read/write to a socket channel at the same time (Windows environment does not have this problem). In short, Unix/Linux cannot read and write to a socket channel at the same time. In addition, I have tried to use synchronization control to prevent reading and writing to the same socket channel, but it only reduces the probability of the exception (it is definitely not the problem of synchronization control). This problem will not occur after sending and receiving a delay. Of course, applications can not tolerate such processing efficiency and performance. At last, I changed the whole network communication to the non blocking mode of new IO, dealing with multiple channels in a single thread. There is no such problem, and it seems that the system throughput is higher than before

3：

Java.net.socketexception: broken pipe at java.net.socketoutstream.socketwrite0 (native method) generally appears on the Linux server. Due to network instability or server overload, the pipeline reader is not reading, and the pipeline writer continues to have threads writing, which will cause pipeline interruption（ SIGSEGV (segment fault) means that the address corresponding to the pointer is invalid and there is no corresponding address in physical memory. The following is the UNIX signal explanation: 11/SIGSEGV: unlaubert zugriff auf hauptspeicher (adressfehler). 12/siguser2: user defined signal 2 (POSIX)_ JAVA_ SR_ Changing Signum to 12 just turns the signal to user defined so that it doesn’t report. It can’t solve the problem. Suggested ways: 1. Resources are not completely released, after use to null value (Java GC is not so perfect) 2. Database connection sequence closed（ RS, PS, Conn) 3. Optimize Java virtual machine and add corresponding memory parameters! 4. Don’t get large pieces of text in the database (that is, the value of a field should not be too large). 5. Java does not recommend using string to get a lot of information（ It is easy to cause memory leakage, so it is recommended to use StringBuffer) 6. Repeat page submission 7. Try to move method to Java. All methods in JSP are regarded as global variables, so there are many problems in compilation and execution. 8. For the query function, try to use non Xa (transaction). 9. Try to use the newer and more stable version of JDK. The lower version of JVM has many bugs, such as 1. 5 is better than 1. 2，1。 It must be very obvious progress. 10. Linux system itself is not so stable, some problems can not be avoided ~ ~:)