代码编写艺术之硬编码：系统时间是硬编码

最新推荐文章于 2021-03-02 06:04:59 发布

tenebaul

最新推荐文章于 2021-03-02 06:04:59 发布

阅读量732

点赞数

文章标签：系统时间硬编码

本文链接：https://blog.csdn.net/tenebaul/article/details/34985997

版权

讨论到一个关于系统时间的问题。简单分享下我的观点：
1、 System.currentTimeMillis(), new java.util.Date(),Calendar.getInstance() 尽量不要分布在代码的各个角落，而用一个静态类SystemClock管理起来。
2、例如：Class SystemClock {
Long currentTimeMillis() {
Return System.currentTimeMills();
}
……
}
一切使用System.currentTimeMills()的地方，都换成SystemClock. currentTimeMills();
3、这样做的坏处？太矫情了，多走了个套路。但代价并非很大。
4、这样做的好处？可以让系统运行在你想要的任何一个时间点，而不需要依赖计算机系统时间。比如的应用场景：
a) 电商的支付交易都是要对账的，所有交易都有个“交易日”的概念，但这个交易日都是可以人为控制的，有必要时可以把23:00的交易都换成第二天的。
b) 安全设计时很多签名有过期时间，比如有的过期时间是10分钟。但测试联调的时候，没必要真的傻等10分钟，而需要一个能干预应用的当前时间的机制。
c) 便于“昨日重现”：系统很多优化的工作一般是离线的，但是有些优化需要尽可能真实的数据请求。比如并发测试，既要构造尽可能多的访问量，更难的是要模拟出真实线上环境的“资源竞争”，因为并不是所有的并发都存在同一资源的竞争，现实生产环境的并发竞争情况往往很难模拟。有个简单的办法就是把历史的Nginx access log读取并解析Mock成一个HTTP请求，让应用逻辑直接处理，此时需要做的一个工作是“系统当前运行时间=access log的打印时间”，具体实现是从access log解析出一个HTTP，把这个HTTP请求的请求时间绑定到ThreadLocal容器里，SystemClock. currentTimeMillis()时从ThreadLocal容器里面获取，这样所有的代码都不用修改，唯一需要变更的是SystemClock类。