记录报错java线程报错-20250710

20250710记录报错

1、错误原因：java服务导致OOM kill

今天突然后端服务CPU上升、导致服务器告警、监控检测不到服务端口、服务挂机。

2、如何排查：日志

1、立即查看监控

重点：这里主要是去定位发生问题时间

2、随后查看宿主机日志：发现 oom-kill

找到服务问题所在

[root@iZ2ze8pmxwul ~]#vim /var/log/syslog

3、java线程日志（导致复用）

开发查看服务日志：发现线程不够用、java服务默认线程是200个

主要原因：1、线程不够用（由nginx日志找出这个问题）

​ 2、线程复用（上图中两个接口复用一个线程）

注意：这两个接口是干什么用的 、

接口1：后缀为Excel、是上传表格导入数据的 （导入数据需要在内存中解析、也占用内存比较大）
接口2：查询请求、这个查询也是扫描的表比较大、所以就导致内存泄漏OOM。

后续java导致CPU高了直接使用下方命令排查
博客参考：https://blog.csdn.net/notsaltedfish/article/details/80209538
1、查看java应用
	ps aux |grep  java
	
	
2、查看线程：命令找出线程PID    pid-thread
	top -Hp 1849

3、命令将线程 pid 转换成 16 进制 pid-thread-hex
	printf '%x\n' <pid-thread> 

4、命令查看线程信息
	jstack 1849 | grep （16 进制 pid-thread-hex）

4、为什么说线程复用：看nginx日志

java线程上限：后续请求都是等待状态、导致499状态码

499是什么：
nginx 对499的定义是  client has closed connection。这个定义比较模糊，简单来说就是nginx在完成响应之前客户端断开了连接。

客户端（浏览器）——————>nginx/前端html————————>后端java服务

后端线程已经是爆满了、后续请求都要等待了、而前端要响应客户的浏览器、这个时候前端就会设定等待时间、一直等待java接收请求、这个时候java处理不过来了、而前端也等待不及了、前端就主动断开连接、返回错误码499.

三张图：

​ 图1、正常阶段：200

​ 图2、线程复用阶段：导致后续线程等待、报499错误

​ 图3、服务宕机之后：502错误

3、为什么导致OOM ？ 找出问题原因：

1、java默认线程上限是200

线程上限：影响客户体验、导致超出线程的请求都在等待

2、主要原因：宿主机内存不够用

内存超过上限、服务器打满了、然后就OOM-kill

3、java服务导致内存增长、优化代码

Excel导入接口严重影响其它业务

4、解决方案：

1、升级服务器内存配置

增加机器配置、加内存、防止OOM

2、调整java线程

设置最大线程数：server.tomcat.threads.max=400

3、优化代码

拆出导入数据的服务、进行解耦、不能影响其它业务接口。

5、结论：

这就是为什么采用微服务架构去治理服务：

1、接口拆分。（像我们这种情况、导入数据接口、可以直接做成一个java服务、防止影响别的业务数据）

2、服务之间解耦：每个接口都要单独划分业务、避免服务节点宕机重要的业务受到影响。

3、服务参数优化、还是要提前压测一下服务、然后根据业务进行适当的调优。

4、作一些监控、服务链路上的监控、进行接口颗粒度监控告警。