故事的背景:
笔者最近在做一个类SNS的项目,其中使用了MongoDB进行Feed信息存储,并使用定时器删除过期信息。
定时器的时间变量为60天,设定
之所以这么写常量,完全是为了代码的易读易维护。
故事的发生:
在项目上线的某天,突然发现,2周前的数据丢失了,遍历了程序,没发现逻辑问题,甚至开始当心MongoDB造成的数据丢失(业内也是发生过的)。 笔者当时纠结啊~~
但第二天又发现数据的丢失是持续而且有规律的,于是,焦点便集中到了“定时删除任务”。左查右查没发现问题,只能一步一步的进行跟踪调试。。。。
故事的结局:
很难令人想象,问题就出现在msgInvalidDue这个long型常量上。按道理它的值应该是5184000000L的(表示60天的时间),但是它实际值却是 889032704(大约10天时间),why???? 居然是int在计算过程中的溢出~~~~太隐晦的bug了~~正确的写法
任意一个常量上加L,转long型就OK了,坑爹哇~~~这回真是阴沟里翻船了~~
笔者最近在做一个类SNS的项目,其中使用了MongoDB进行Feed信息存储,并使用定时器删除过期信息。
定时器的时间变量为60天,设定
- private long msgInvalidDue = 60 * 24 * 3600 * 1000;
之所以这么写常量,完全是为了代码的易读易维护。
故事的发生:
在项目上线的某天,突然发现,2周前的数据丢失了,遍历了程序,没发现逻辑问题,甚至开始当心MongoDB造成的数据丢失(业内也是发生过的)。 笔者当时纠结啊~~
但第二天又发现数据的丢失是持续而且有规律的,于是,焦点便集中到了“定时删除任务”。左查右查没发现问题,只能一步一步的进行跟踪调试。。。。
故事的结局:
很难令人想象,问题就出现在msgInvalidDue这个long型常量上。按道理它的值应该是5184000000L的(表示60天的时间),但是它实际值却是 889032704(大约10天时间),why???? 居然是int在计算过程中的溢出~~~~太隐晦的bug了~~正确的写法
- private long msgInvalidDue = 60 * 24 * 3600L * 1000;
任意一个常量上加L,转long型就OK了,坑爹哇~~~这回真是阴沟里翻船了~~