linux 下 tomcat 运行报错 Broken pipe

最新推荐文章于 2025-03-08 21:42:15 发布

tang_jian_dong

最新推荐文章于 2025-03-08 21:42:15 发布

阅读量1.4k

点赞数

原文链接：https://www.cnblogs.com/yaowen/p/9726453.html

版权

本文介绍了解决Linux环境下Tomcat服务器频繁崩溃的方法，通过设置环境变量_JAVA_SR_SIGNUM为12来避免高并发时JVM的信号处理问题，同时提供了深入理解信号(SIGSEGV, SIGUSR2)及优化Java应用的建议。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

转载： https://www.cnblogs.com/yaowen/p/9726453.html

执行如下命令：

 export _JAVA_SR_SIGNUM=12

说明：

有可能是linux的线程机制会产生JVM出错的问题，特别是在连接高峰期间经常出现这样的问题，tomcat在linux下也出现类似情况。
　　解决办法是在环境变量中设置： _JAVA_SR_SIGNUM = 12 基本就可以解决。

在WIN环境变量中设置： _JAVA_SR_SIGNUM=12, 若Linux下用 export _JAVA_SR_SIGNUM=12, 基本就可以解决. 
　　sun的解释：
　　－－posted by: cooper 
　　Below is a clipping from Sun on working around JVM crashes under high 
　　thread counts in the JVM 1.3 for Linux 
　　On Linux, use a larger signal number for hotspot thread 
　　suspension/resumption handler. The signal number being used is 
　　specified by environment variable _JAVA_SR_SIGNUM. Setting it to a 
　　number larger than SIGSEGV (11) will solve the PRoblem. A good number 
　　to use is 12, which is SIGUSR2. Using signal 16 to work around the 
　　problem might have potential problems. So on tcsh, "setenv 
　　_JAVA_SR_SIGNUM 12" can solve the problem.

这个异常是由于以下几个原因造成。

1、客户端再发起请求后没有等服务器端相应完，点击了stop按钮，导致服务器端接收到取消请求。通常情况下是不会有这么无聊的用户，出现这种情况可能是由于用户提交了请求，服务器端相应缓慢，比如业务逻辑有问题等原因，导致页面过了很久也没有刷新出来，用户就有可能取消或重新发起请求。

2、Tomcat服务器在接受用户请求的时候，有其自身的处理能力，线程、服务器等各个资源限制，超出Tomcat承载范围的请求，就会被tomcat停掉，也可能产生该错误。

3、linux的线程机制会产生JVM出错的问题，特别是在连接高峰期间经常出现这样的问题，tomcat在linux下也出现类似情况。
Java代码

1.sun的解释：
2.－－posted by: cooper
3.Below is a clipping from Sun on working around JVM crashes under high
4.thread counts in the JVM 1.3 for Linux
5.
6.On Linux, use a larger signal number for hotspot thread
7.suspension/resumption handler. The signal number being used is
8.specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
9.number larger than SIGSEGV (11) will solve the problem. A good number
10.to use is 12, which is SIGUSR2. Using signal 16 to work around the
11.problem might have potential problems. So on tcsh, "setenv
12._JAVA_SR_SIGNUM 12" can solve the problem.
sun的解释：
－－posted by: cooper
Below is a clipping from Sun on working around JVM crashes under high
thread counts in the JVM 1.3 for Linux
On Linux, use a larger signal number for hotspot thread
suspension/resumption handler. The signal number being used is
specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
number larger than SIGSEGV (11) will solve the problem. A good number
to use is 12, which is SIGUSR2. Using signal 16 to work around the
problem might have potential problems. So on tcsh, "setenv
_JAVA_SR_SIGNUM 12" can solve the problem.

复制代码

“_JAVA_SR_SIGNUM=12”等号两边必须没有空格，等号是半角

资料:
Broken pipe产生的原因通常是当管道读端没有在读，而管道的写端继续有线程在写，就会造成管道中断。（由于管道是单向通信的） SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址，没有物理内存对应该地址。以下是UNIX的信号解释： 11 / SIGSEGV: Unerlaubter Zugriff auf Hauptspeicher (Adressfehler). 12 / SIGUSER2: User-defined Signal 2 (POSIX). 把_JAVA_SR_SIGNUM改成12只是将信号至成user-defined，让它不报出来而已，不能解决问题。建议采取的方式：
1．资源没有完全释放，用完后要至NULL 值（JAVA的GC没那么完善）
2．数据库连接顺序关闭！（RS，PS，CONN）
3．优化JAVA虚拟机加入相应的内存参数！
4．不要在数据库中获取大段文本（即一个栏位的值不要太大）
5． JAVA 不推荐用String 获取大量信息。（容易造成内存泄露，建议用StringBuffer）
6．页面重复提交
7．尽量将METHOD移到JAVA中，在JSP中所有的方法都看做全局变量，编译执行本身就有很多问题。
8．如果是查询功能，尽可能的使用非XA(事务)。
9．尽量用较新较稳定版本的JDK，低版本的JVM本身也有很多BUG，比如1。5的垃圾回收比起1。2，1。3一定是非常明显的进步。
10． LINUX系统本身没有这么稳定，有些问题无法避免的~~：）