目录
- 01 踩到的坑
- 02 time.duration的真实面目
- 03 问题解决
- 04 time.duration编程实践
- 05 总结
01 踩到的坑
先来说说在项目中踩到的使用time.duration类型的坑。我们的背景是要做一个延时任务。延时任务就是指将一个任务延迟到一定的时间后再执行，所以就需要根据延时时间计算出该任务要执行的时间。我们这里的延时时间以毫秒为单位，当时我们定义的是500毫秒。即设置了一个全局的变量interval time.duration。 即interval = 500 * time.milliseconds。然后就通过以下公式来计算要
执行的时间了：
可执行时间=当前时间+延迟时间可执行时间=当前时间 + 延迟时间可执行时间=当前时间+延迟时间
由以上公式可得到我们的一个任务的可执行时间为 time.now().unixmilli() + int64(interval) 。大家看这里有什么问题吗？
问题在于计算的结果值不是在当前的毫秒数上增加了500，而是增加了500000000,多了6个零。这是为什么呢？
02 time.duration的真实面目
我们从源码中找到答案。我们从time包中看到time.duration的定义：
// a duration represents the elapsed time between two instants
// as an int64 nanosecond count. the representation limits the
// largest representable duration to approximately 290 years.
type duration int64
由源码可知，duration本质上是一个int64的类型。从注释可知，代表的是两个时间点之间持续的纳秒数 。 所以这里有两点信息 ：一是该类型代表的是一段持续时间，二是该类型的基本单位是纳秒。 这里我先重点关注基本单位是纳秒这点。我们再来看几个常量的定义：
const ( nanosecond duration = 1 microsecond = 1000 * nanosecond millisecond = 1000 * microsecond second = 1000 * millisecond minute = 60 * second hour = 60 * minute )
一个单位的duration是代表1纳秒。 而time.micorsecond、time.millisecond、time.second、time.minute、time.hour的单位实际上都是纳秒。也就是说我们使用到的time.millisecond实际上是1000000纳秒。所以就有了interval=500*time.millisecond=500 * 1000000 = 500000000，然后在计算延时后的执行时间时两个单位不一样造成计算出来的值不是预期的增加500毫秒的结果。
03 问题解决
知道了time.duration类型的基本单位是代表纳秒之后，我们就可以很好的解决了。就是统一单位。
我们也发现，在time包中对于time.duration类型的对象有转换成秒、毫秒等对应的函数。如下：
所以我们直接获取即可：
可执行时间 := time.now().unixmilli() + interval.millisecond()
04 time.duration编程实践
上面是我在编码时因为没搞懂time.duration类型的本质含义猜到的一个坑。那么我们在实际编码时在定义和持续时间有关的变量时应该使用int类型还是time.duration类型呢？
我的建议是大家尽量用time.duration类型。为什么呢？第一个原因是和标准库类型统一，不用做过多的转换。因为我们观察可以发现，无论是开源程序，还是go的标准库，凡是和持续时间相关的变量类型都是使用的time.duration，这样类型统一我们来看几个例子。
示例一：context.withtimeout
func withtimeout(parent context, timeout time.duration) (context, cancelfunc) {
return withdeadline(parent, time.now().add(timeout))
}
我们看到，context包中的withtimeout函数中的timeout的类型是time.duration。
示例二：time.sleep
func sleep(d duration)
time包中的sleep函数的d参数也是duration类型。
示例三：time.newticker
func newticker(d duration) *ticker
如果我们自己的程序中相关变量使用的也是time.duration类型，那么在调用标准库函数时就不用进行类型转化了。
第二个原因就是该类型在语义上就明确了time.duration类型值的基本单位是纳秒。这样在函数调用过程中就不用进行单位换算了。我们看下面以连接redis的示例是如何进行类型转换的。
我们在连接redis的时候，一般都会设置读写超时时间以及定义redis的地址，我们有如下配置：
type config struct {
addr string
readtimeout int64 //以秒为单位
}
我们使用包github.com/go-redis/redis/v8包来连接redis。我们看到
func newredisclient(conf config) *redis.client {
opt := redis.options{
addr: conf.addr,
readtimeout: conf.readtimeout * time.second
}
client := redis.newclient(opt)
return client
}
我们知道redis.options中的readtimeout的类型是time.duration。 那么，如果我们在config配置文件中定义的int64类型以秒为单位的话，则在newredisclient中给redis.options中的readtimeout赋值时，需要做如下转换：
conf.readtimeout * time.second
那如果我们在config中定义的readtimeout的代表的是毫秒的话，那么在newredisclient函数中就需要做如下转换：
conf.readtimeout * time.millisecond
那在config结构体中的readtimeout所代表的含义是秒还是毫秒还是其他的由谁来保证呢，只能是人为的进行保证。而如果使用time.duration类型就是由系统类型来保证的，因为go的标准库定义的该类型就是代表纳秒数。
05 总结
本文从在实际编程中遇到的问题出发，了解到time.duration类型实际代表的是持续的纳秒数。同时又分析了使用time.duration类型的好处。在项目中，如果遇到和持续时间相关的变量的定义，也建议大家尽量使用time.duration类型。
到此这篇关于记一次go语言使用time.duration类型踩过的坑的文章就介绍到这了,更多相关go time.duration内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
