Tomcat服务随机自动重启，请求排查原因及检测方向

JVM触发SIGSEGV（段错误）并导致Tomcat进程被ABRT信号终止，核心原因集中在本地代码层的内存非法访问，结合环境信息，可能的诱因包括：

• JDK 1.8.0_333存在已知的native层bug，该版本属于较旧的补丁版本，部分内存管理相关的问题尚未修复
• Tomcat启用的APR/native组件与JDK版本存在兼容性冲突
• 某Web应用（尤其是ALARMCFG）依赖的第三方JNI库存在内存泄漏或非法内存访问问题
• 系统物理内存硬件故障、OS内存管理异常，或systemd配置的资源限制触发内存访问错误

• 启用核心转储定位崩溃点
  修改Tomcat的systemd服务配置文件（如/etc/systemd/system/tomcat.service），添加LimitCORE=infinity，执行systemctl daemon-reload && systemctl restart tomcat。待下次崩溃后，使用gdb $JAVA_HOME/bin/java core.<进程ID>分析核心转储文件，获取精确的native代码调用栈，直接定位崩溃来源。
• 升级JDK至最新补丁版本
  JDK 1.8.0_333已发布多年，官方已修复大量native层bug，建议升级至JDK 1.8的最新稳定补丁版本（如1.8.0_401），验证崩溃是否消失。
• 排查Tomcat Native组件
  查看catalina.out中是否有APR based Apache Tomcat Native library的加载日志，若启用了APR，临时修改conf/server.xml中的Connector协议为默认NIO（移除protocol="org.apache.coyote.http11.Http11AprProtocol"），重启服务后观察是否仍出现重启。
• 隔离排查Web应用
  逐个移除部署的Web应用（优先移除ALARMCFG），每次移除后运行1-2天，若崩溃停止则定位到对应应用，进一步排查该应用的JNI依赖或native调用逻辑。
• 系统层面检测
  • 运行memtest86+检测物理内存是否存在硬件故障；
  • 查看/var/log/messages和dmesg输出，排查是否有OOM killer触发、内存页错误等系统级异常；
  • 检查Tomcat的systemd配置，确认LimitAS、LimitRSS等资源限制参数未设置过低，导致JVM内存不足触发异常。
• 深挖hs_err_pid日志
  重点分析hs_err_pid文件中的Current Thread、Native Library Information和Stack Trace部分，确认崩溃发生在JDK原生库还是第三方native库，针对性查找对应库的已知bug或修复方案。

内容的提问来源于stack exchange，提问作者thomson