SNMP4J请求交换机mac表,在Object.wait(long ms)方法卡死

本文探讨了一定时任务通过SNMP协议获取交换机MAC表时,因网络问题导致线程长时间阻塞的现象。通过Arthas工具分析、抓包和问题交换机操作,发现是交换机mac表过大引发的持续请求。最终运维手动清空表后问题解决,揭示了非程序性问题的解决过程。

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

背景:定时任务使用SNMP协议定时获取交换机的mac表并入库。
现象:SNMP4j源码等待交换机响应时调用了Object的wait(long timeout)方法,时间设置为12秒,但是在wait方法这里阻塞了最多十几个小时以上。

1. 使用arthas查看卡死的线程

arthas查看卡死的线程

2. 使用arthas查看线程调用栈

在这里插入图片描述

3. 调用栈最终阻塞代码的位置截图

在这里插入图片描述
waitMillis应该是固定的12s,并没有很大,所以线程预期应该在12s时中止等待状态,除非一直在接收数据。
但这个线程到从凌晨现在已经阻塞了十几个小时,不应该是java的原生wait方法出问题,所以应该是程序正在接受数据接收了十几个小时。
当天晚上开始运行定时任务,次日在服务器上抓包:

tcpdump -i eno2 -xx host xxxx -w ./dump1.pcap

得知程序确实一直在接受和发送snmp报文,但实际总报文(开头提到的mac表)并没有很大。
解决方法:让运维人员手动清空问题交换机的mac表。问题得到解决
结果并不是程序的问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值