記一次go語言使用time.Duration類型踩過的坑
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內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！