物联网平台在做设备模拟测试的时候，发现有设备在上报一段时间后就不再上报数据了，经过排查发现是因为整数越界导致死循环引起的，特此记录下给大家做下参考，以后遇到此类问题可以做参考。
背景
在物联网平台做模拟，配置终端设备的运动轨迹如下，代码自动模拟设备每次扫描的beacon列表，编码然后通过基站发送给平台。
image.png
使用的线程池执行上报逻辑
this.terminalScheduler = new ScheduledThreadPoolExecutor(this.terminalThreads, new NamedThreadFactory("terminalScheduler", true));
定时上报数据
this.terminalScheduler.scheduleAtFixedRate(simulateTask, 0, latency, TimeUnit.MILLISECONDS);
现象
设备前期正常发送数据，过一段时间后就不再发数据。
分析
第一眼反应可能是simulateTask抛异常导致任务中止，查看任务执行代码
public final void run() {
MDC.put(LoggerConstants.TRACE_ID, UuidUtils.randomUuid());
log.info("product={}, mac={}开始执行, 距离上一次过去{}ms", this.getDeviceSimulator().getDeviceContext().getProductKey(), this.getDeviceSimulator().getDeviceContext().getMac(), System.currentTimeMillis() - this.lastRunTime);
this.lastRunTime = System.currentTimeMillis();
try {
this.doRun();
} catch (Throwable e) {
log.error("product={}, mac={}, task执行报错", this.getDeviceSimulator().getDeviceContext().getProductKey(), this.getDeviceSimulator().getDeviceContext().getMac(), e);
}
}
任务执行方法包含在try catch中，即使抛异常也不会导致任务中止，这种情况排除。
然后怀疑延时任务调度有延迟，由于Java自带的线程池ScheduledThreadPoolExecutor很多地方都在用，且设备并发上报比较频繁，Debug起来不是很方便，且即使任务调度延迟但也不应该延迟那么久，这种可能性很低，先暂时不考虑这种方法。
最后查看日志
2023-04-26 21:34:21.300 [deviceSimulator28] INFO bda49cb4ad184a189b53816491c287e2 com.joysuch.iot.performance.engine.engine.TerminalSimulateTask - 终端BLT2-FC 1818FF050211 上报数据, result=
true, 耗时10ms, payload=C811FF0502113060D820406020C009290D404E28B1CE0AC022B52F1E0AC022B75B010000
这是1818FF050211设备最后一次上报数据，线程名deviceSimulator28，突然想到这个线程是不是卡在什么地方了呢？看看后面的日志中这个线程有没有再次出现？查看后面日志果然没有出现这个线程。这个时候解决问题的曙光已经出现了，只有两种可能，第一种可能是线程退出了，第二种可能是线程阻塞在什么地方了。由于模拟任务被try catch了，因此不太可能因为任务有异常导致线程退出，那么很大可能就是第二种情况了。赶紧把JVM的线程栈抓出来
image.png
惊奇的发现在while循环中value竟然是-1，这样会导致while死循环，那value为什么会是负数呢，继续查询上一栈帧，找到问题元凶
Integer majorMinorDiff = (firstScannedBeacon.getMajor() << 16 | firstScannedBeacon.getMinor()) - (scannedBeacon.getMajor() << 16 | scannedBeacon.getMinor());
这行代码是根据BLT协议拼装数据，我们知道beacon的major和minor是2个字节，左移16位就会超过int的最大值产生溢出变成负数了，这样就导致了后面的while死循环。至此问题解决。
总结
通过这个案例，我们可以学到2点：
一是在编写代码和测试的时候要考虑到边界值，不然在开发测试阶段就可能让边界值成为漏网之鱼，等到项目现场就一不小心爆出来了，而通过走查代码很难发现问题。这次问题是发现在开发环境，还可以通过远程Debug来快速定位，如果是在项目现场，排查难度就会变大很多。
二是通过日志来提高排查问题速度，如果日志中没打印线程名或者任务抛了异常我们代码没捕获导致线程退出了，通过日志就不好排查，所以在打日志的时候尽可能打印那些有助于排查问题的日志。
网友评论