测试踩坑——JAVA13位时间戳处理，别小瞧了“毫秒“老弟

One Tester

于 2022-02-09 14:42:42 发布

阅读量2.7k

点赞数 3

分类专栏：测试踩坑系列文章标签： java 测试工程师

本文链接：https://blog.csdn.net/qq_37688023/article/details/120924000

版权

测试踩坑系列专栏收录该内容

1 篇文章 0 订阅

订阅专栏

测试踩坑——JAVA13位时间戳处理，别小瞧了"毫秒"老弟！

您好，我是博主 One Tester ，感谢您阅读本文！如果此文对您有所帮助，请毫不犹豫的一键三连吧，小伙伴们有想看的欢迎积极留言。测试相关博客链接已存放在改链接下：汇总目录

一、BUG现象

BUG现象：进入页面，显示的下周还有剩余的流量额度，但是将营销时间选择在下周的时间里，点击 “完成创建”按钮进行任务创建的时候，却提示“任务渠道余额不足”（这里只要时间范围内有剩余，就能创建）。
在这里插入图片描述
场景描述：

页面查询时：传入当前时间，计算出本周时间范围和下周时间范围，然后根据范围计算出相关数据
创建任务时：传入选择的营销时间，计算出运营时间当周时间范围和下周时间范围，然后根据范围计算出相关数据。

二、BUG原因及修复

问题原因：开发写了两个方法，入参都为Date时间。一个计算入参对应周的开始时间，另一个计算对应周的结束时间，但是计算对应周开始时间中存在问题。

创建任务时，选择时间只是年月日，所以最后传递过去的13位时间戳，后三位的毫秒数肯定是0。
进入创建任务界面，查询时，由于传递的是当前时间，对应的13位时间戳的后三位肯定不为0。

导致的问题：由于两种场景计算出来的时间不一致，而对应查询数据的SQL就会不一致（mysql中between是前闭后闭区间[]）。

创建任务（正常情况）: market_time BETWEEN ‘2021-06-21 00:00:00’ AND ‘2021-06-27 23:59:59.999’
查询信息（异常情况）：market_time BETWEEN ‘2021-06-21 00:00:00.387’ AND ‘2021-06-27 23:59:59.999’

而如果存在运营时间是周一的数据，就会导致两个sql查询出来数据必然不一致的情况。
在这里插入图片描述

开发原先计算当前时间本周的时间范围开始时间的代码如下：

public static Date getMondayOfCurrentWeek(Date date) {
    Calendar cal = Calendar.getInstance();
    cal.setTime(date);
    int dayOfWeek = cal.get(Calendar.DAY_OF_WEEK) - 1;
    if (cal.get(Calendar.DAY_OF_WEEK) == Calendar.SUNDAY) {
        dayOfWeek = 7;
    }
    cal.add(Calendar.DATE, 1 - dayOfWeek);
    return clearTime(cal.getTime());
}

代码修复：将clearTime方法中，将毫秒级别的时间也设置为0
在这里插入图片描述

三、排查过程——Debug没细看后的迷惑操作

迷惑操作:正常情况而言，这个时间戳的问题，正常Debug就能发现问题所在。But，我当时debug时，硬生生就是没有展开看那个时间戳（就这样被蒙蔽了双眼…），只看到两种场景显示的开始时间和结束时间对应的年月日-时分秒都一样(如下图)，当时就懵了，这代码没问题啊，这时间也没问题，这怎么可能有问题，难道中邪了…最后想只能捞一下这两种情况对应的sql看下有啥区别。
在这里插入图片描述

3.1 使用tcpdump，获取对应cap数据包

使用CRT或Xsehll工具，连接上这个SQL 所属域。
通过以下命令，可以监听对应的tcp流数据并将cap数据文件下载到本地。
注意点1：为了避免监听的tcp数据量中包含太多的mysql相关的数据，导致后面不好找到对应的数据。可以将Debug远程服务，将断点打在需要查看的SQL前后各一个，到第一个断点时，使用tcpdump命令开始监听，到第二个断点时，结束监听并生成文件
注意点2：CRT软件一般会设置默认下载路径，可能sz命令时不会出现选择将文件下载到那个目录下的选项。

对应命令：
```
sudo su - root
yum install tcpdump
tcpdump -i eth0 -s0 -w ~/123.cap
sz 123.cap
```