神奇bug, Timestamp 会四舍五入也会引起 bug .. 

String UUID = java.util.UUID.randomUUID().toString();
long time = System.currentTimeMillis() + 30 * 60 * 1000;
Timestamp outDate = new Timestamp(time);
long outDateLong = time/1000*1000;
user.setValidateUuid(UUID);
user.setOutDate(outDate);
userMapper.updateByPrimaryKey(user);

这段代码有问题吗? 

 

其实是有的, time / 1000 * 1000 之后, time 相对于失去了 尾数后面3个数字, 也就是 直接截断了. 但是, outDate 并没有, outDate 保存的mysql 数据库里面的时候, 也会截断吗?  如果也是截断, 那么就不会有任何问题. 但是, 经测试 实际不是的, 它会四舍五入 ..

如果time 末尾三位数小于500, 那么也没有问题, 如果大于, 就出现bug了, 后面如果再次从数据库获取 outDate, 那么其毫秒值会 不等于outDateLong  ,  刚好出现几率为 0.5 的bug 啊!!   ( 当然, 如果不关心outDateLong , 其实也没有什么问题, 谁会去关心那个秒级的四舍五入呢?)

 

 

改成下面的样子就好了..

String UUID = java.util.UUID.randomUUID().toString();
long time = System.currentTimeMillis() + 30 * 60 * 1000;
long outDateLong = time/1000*1000;
Timestamp outDate = new Timestamp(outDateLong);
user.setValidateUuid(UUID);
user.setOutDate(outDate);
userMapper.updateByPrimaryKey(user);

..

 

相关文章:

  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2022-01-05
猜你喜欢
  • 2022-12-23
  • 2021-12-29
  • 2021-06-09
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2021-09-04
相关资源
相似解决方案