01 踩到的坑

先來說說在項(xiàng)目中踩到的使用time.Duration類型的坑。我們的背景是要做一個(gè)延時(shí)任務(wù)。延時(shí)任務(wù)就是指將一個(gè)任務(wù)延遲到一定的時(shí)間后再執(zhí)行，所以就需要根據(jù)延時(shí)時(shí)間計(jì)算出該任務(wù)要執(zhí)行的時(shí)間。我們這里的延時(shí)時(shí)間以毫秒為單位，當(dāng)時(shí)我們定義的是500毫秒。即設(shè)置了一個(gè)全局的變量interval time.Duration。 即interval = 500 * time.Milliseconds。然后就通過以下公式來計(jì)算要

執(zhí)行的時(shí)間了：

可執(zhí)行時(shí)間=當(dāng)前時(shí)間+延遲時(shí)間可執(zhí)行時(shí)間=當(dāng)前時(shí)間 + 延遲時(shí)間可執(zhí)行時(shí)間=當(dāng)前時(shí)間+延遲時(shí)間

由以上公式可得到我們的一個(gè)任務(wù)的可執(zhí)行時(shí)間為 time.Now().UnixMilli() + int64(interval) 。大家看這里有什么問題嗎？
問題在于計(jì)算的結(jié)果值不是在當(dāng)前的毫秒數(shù)上增加了500，而是增加了500000000,多了6個(gè)零。這是為什么呢？

02 time.Duration的真實(shí)面目

我們從源碼中找到答案。我們從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本質(zhì)上是一個(gè)int64的類型。從注釋可知，代表的是兩個(gè)時(shí)間點(diǎn)之間持續(xù)的納秒數(shù) 。 所以這里有兩點(diǎn)信息 ：一是該類型代表的是一段持續(xù)時(shí)間，二是該類型的基本單位是納秒。 這里我先重點(diǎn)關(guān)注基本單位是納秒這點(diǎn)。我們?cè)賮砜磶讉€(gè)常量的定義：

const (
? ? Nanosecond ?Duration = 1
? ? Microsecond ? ? ? ? ?= 1000 * Nanosecond
? ? Millisecond ? ? ? ? ?= 1000 * Microsecond
? ? Second ? ? ? ? ? ? ? = 1000 * Millisecond
? ? Minute ? ? ? ? ? ? ? = 60 * Second
? ? Hour ? ? ? ? ? ? ? ? = 60 * Minute
)

一個(gè)單位的Duration是代表1納秒。 而time.Micorsecond、time.Millisecond、time.Second、time.Minute、time.Hour的單位實(shí)際上都是納秒。也就是說我們使用到的time.Millisecond實(shí)際上是1000000納秒。所以就有了interval=500*time.Millisecond=500 * 1000000 = 500000000，然后在計(jì)算延時(shí)后的執(zhí)行時(shí)間時(shí)兩個(gè)單位不一樣造成計(jì)算出來的值不是預(yù)期的增加500毫秒的結(jié)果。

03 問題解決

知道了time.Duration類型的基本單位是代表納秒之后，我們就可以很好的解決了。就是統(tǒng)一單位。
我們也發(fā)現(xiàn)，在time包中對(duì)于time.Duration類型的對(duì)象有轉(zhuǎn)換成秒、毫秒等對(duì)應(yīng)的函數(shù)。如下：

所以我們直接獲取即可：

可執(zhí)行時(shí)間 := time.Now().UnixMilli() + interval.Millisecond()

04 time.Duration編程實(shí)踐

上面是我在編碼時(shí)因?yàn)闆]搞懂time.Duration類型的本質(zhì)含義猜到的一個(gè)坑。那么我們?cè)趯?shí)際編碼時(shí)在定義和持續(xù)時(shí)間有關(guān)的變量時(shí)應(yīng)該使用int類型還是time.Duration類型呢？
我的建議是大家盡量用time.Duration類型。為什么呢？第一個(gè)原因是和標(biāo)準(zhǔn)庫(kù)類型統(tǒng)一，不用做過多的轉(zhuǎn)換。因?yàn)槲覀冇^察可以發(fā)現(xiàn)，無論是開源程序，還是go的標(biāo)準(zhǔn)庫(kù)，凡是和持續(xù)時(shí)間相關(guān)的變量類型都是使用的time.Duration，這樣類型統(tǒng)一我們來看幾個(gè)例子。

示例一：context.WithTimeout

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
? ? return WithDeadline(parent, time.Now().Add(timeout))
}

我們看到，context包中的WithTimeout函數(shù)中的timeout的類型是time.Duration。

示例二：time.Sleep

func Sleep(d Duration)

time包中的Sleep函數(shù)的d參數(shù)也是Duration類型。

示例三：time.NewTicker

func NewTicker(d Duration) *Ticker

如果我們自己的程序中相關(guān)變量使用的也是time.Duration類型，那么在調(diào)用標(biāo)準(zhǔn)庫(kù)函數(shù)時(shí)就不用進(jìn)行類型轉(zhuǎn)化了。

第二個(gè)原因就是該類型在語義上就明確了time.Duration類型值的基本單位是納秒。這樣在函數(shù)調(diào)用過程中就不用進(jìn)行單位換算了。我們看下面以連接redis的示例是如何進(jìn)行類型轉(zhuǎn)換的。

我們?cè)谶B接redis的時(shí)候，一般都會(huì)設(shè)置讀寫超時(shí)時(shí)間以及定義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。 那么，如果我們?cè)赾onfig配置文件中定義的int64類型以秒為單位的話，則在NewRedisClient中給redis.Options中的ReadTimeout賦值時(shí)，需要做如下轉(zhuǎn)換：

conf.ReadTimeout * time.Second

那如果我們?cè)赾onfig中定義的ReadTimeout的代表的是毫秒的話，那么在NewRedisClient函數(shù)中就需要做如下轉(zhuǎn)換：

conf.ReadTimeout * time.Millisecond

那在config結(jié)構(gòu)體中的ReadTimeout所代表的含義是秒還是毫秒還是其他的由誰來保證呢，只能是人為的進(jìn)行保證。而如果使用time.Duration類型就是由系統(tǒng)類型來保證的，因?yàn)間o的標(biāo)準(zhǔn)庫(kù)定義的該類型就是代表納秒數(shù)。

05 總結(jié)

本文從在實(shí)際編程中遇到的問題出發(fā)，了解到time.Duration類型實(shí)際代表的是持續(xù)的納秒數(shù)。同時(shí)又分析了使用time.Duration類型的好處。在項(xiàng)目中，如果遇到和持續(xù)時(shí)間相關(guān)的變量的定義，也建議大家盡量使用time.Duration類型。

到此這篇關(guān)于記一次go語言使用time.Duration類型踩過的坑的文章就介紹到這了,更多相關(guān)go time.Duration內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論