經(jīng)過(guò)了半年左右的開(kāi)發(fā)，golang 1.21 在今天早上正式發(fā)布了。

這個(gè)版本中有不少重要的新特性和變更，尤其是在泛型相關(guān)的代碼上。

因?yàn)橛胁簧俅笞儎?dòng)，所以建議等第一個(gè)patch版本也就是1.21.1出來(lái)之后再進(jìn)行升級(jí)，以免遇到一些意外的bug帶來(lái)麻煩。

好了，一起來(lái)看看1.21帶來(lái)的新特性吧。

本文索引

• 新的內(nèi)置函數(shù)
• 類(lèi)型推導(dǎo)更加智能
• panic的行為變化
• modules的變化
• 包初始化順序的改變
• 編譯器和runtime的變化
• 新標(biāo)準(zhǔn)庫(kù)
  • log/slog和testing/slogtest
  • slices和maps
  • cmp
• 已有的標(biāo)準(zhǔn)庫(kù)的變化
  • bytes
  • context
  • crypto/sha256
  • net
  • reflect
  • runtime
  • sync
  • errors
  • unicode
• 平臺(tái)支持變化
• 總結(jié)

新的內(nèi)置函數(shù)

1.21添加了三個(gè)新的內(nèi)置函數(shù)：min、max和clear。

min、max如其字面意思，用了選出一組變量里（數(shù)量大于等于1，只有一個(gè)變量的時(shí)候就返回那個(gè)變量的值）最大的或者最小的值。兩個(gè)函數(shù)定義是這樣的：

func min[T cmp.Ordered](x T, y ...T) T
func max[T cmp.Ordered](x T, y ...T) T

注意那個(gè)類(lèi)型約束，這是新的標(biāo)準(zhǔn)庫(kù)里提供的，原型如下：

type Ordered interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64 |
    ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr |
    ~float32 | ~float64 |
    ~string
}

也就是說(shuō)只有基于所有除了map，chan，slice以及復(fù)數(shù)之外的基本類(lèi)型的變量才能使用這兩個(gè)函數(shù)。或者換句話(huà)說(shuō)，只有可以使用<、>、<=、>=、==和!=進(jìn)行比較的類(lèi)型才可以使用min和max。

有了min和max，可以把許多自己手寫(xiě)的代碼替換成新的內(nèi)置函數(shù)，可以少寫(xiě)一些幫助函數(shù)。而且使用新的內(nèi)置函數(shù)還有一個(gè)好處，在變量個(gè)數(shù)比較少的時(shí)候還有編譯器的優(yōu)化可用，比自己寫(xiě)min函數(shù)性能上要稍好一些。

使用上也很簡(jiǎn)單：

maxIntValue := max(0, 7, 6, 5, 4, 3, 2, 1) // 7 type int
minIntValue := min(8, 7, 6, 5, 4, 3, 2, 1) // 1 type int

目前max和min都不支持slice的解包操作：max(1, numbers...)。

對(duì)于clear來(lái)說(shuō)事情比min和max復(fù)雜。clear只接受slice和map，如果是對(duì)泛型的類(lèi)型參數(shù)使用clear，那么類(lèi)型參數(shù)的type set必須是map或者slice，否則編譯報(bào)錯(cuò)。

clear的定義如下：

func clear[T ~[]Type | ~map[Type]Type1](t T)

對(duì)于參數(shù)是map的情況，clear會(huì)刪除所有map里的元素（不過(guò)由于golang的map本身的特性，map存儲(chǔ)的數(shù)據(jù)會(huì)被正常銷(xiāo)毀，但map已經(jīng)分配的空間不會(huì)釋放）：

func main() {
        m := map[int]int{1:1, 2:2, 3:3, 4:4, 5:5}
        fmt.Println(len(m))  // 5
        clear(m)
        fmt.Println(len(m))  // 0
}

然而對(duì)于slice，它的行為又不同了：會(huì)把slice里所有元素變回零值。看個(gè)例子：

func main() {
        s := make([]int, 0, 100) // 故意給個(gè)大的cap便于觀察
        s = append(s, []int{1, 2, 3, 4, 5}...)
        fmt.Println(s) // [1 2 3 4 5]
        fmt.Println(len(s), cap(s)) // len: 5; cap: 100
        clear(s)
        fmt.Println(s) // [0 0 0 0 0]
        fmt.Println(len(s), cap(s)) // len: 5; cap: 100
}

這個(gè)就比較反直覺(jué)了，畢竟clear首先想到的應(yīng)該是把所有元素刪除。那它的意義是什么呢？對(duì)于map來(lái)說(shuō)意義是很明確的，但對(duì)于slice來(lái)說(shuō)就有點(diǎn)繞彎了：

slice的真實(shí)大小是cap所顯示的那個(gè)大小，如果只是用s := s[:0]來(lái)把所有元素“刪除”，那么這些元素實(shí)際上還是留在內(nèi)存里的，直到s本身被gc回收或者往s里添加新元素把之前的對(duì)象覆蓋掉，否則這些對(duì)象是不會(huì)被回收掉的，這一方面可以提高內(nèi)存的利用率，另一方面也會(huì)帶來(lái)泄露的問(wèn)題（比如存儲(chǔ)的是指針類(lèi)型或者包含指針類(lèi)型的值的時(shí)候，因?yàn)橹羔樳€存在，所以被指向的對(duì)象始終有一個(gè)有效的引用導(dǎo)致無(wú)法被回收），所以golang選擇了折中的辦法：把所有已經(jīng)存在的元素設(shè)置成0值

如果想安全的正常刪除slice的所有元素，有想復(fù)用slice的內(nèi)存，該怎么辦？答案是：

s := make([]T, 0, 100) // 故意給個(gè)大的cap便于觀察
s = append(s, []T{*new(T), *new(T)}...)

clear(s)
s = s[:0]

如果沒(méi)有內(nèi)置函數(shù)clear，那么我們得自己循環(huán)一個(gè)個(gè)賦值處理。而有clear的好處是，編譯器會(huì)直接用memset把slice的內(nèi)存里的數(shù)據(jù)設(shè)置為0，比循環(huán)會(huì)快很多。有興趣的可以看看clear在slice上的實(shí)現(xiàn)：代碼在這 。

類(lèi)型推導(dǎo)更加智能

其實(shí)就是bug修復(fù)，以前類(lèi)似這樣的代碼在某些情況下沒(méi)法正常進(jìn)行推導(dǎo)：

func F[T ~E[], E any](t T, callable func(E))

func generic[E any](e E) {}
F(t, generic) // before go1.21: error; after go1.21: ok

理論上只要能推導(dǎo)出E的類(lèi)型，那么F和generic的所有類(lèi)型參數(shù)都能推導(dǎo)出來(lái)，哪怕generic本身是個(gè)泛型函數(shù)。以前想正常使用就得這么寫(xiě)：F(t, generic[Type])。

所以與其說(shuō)是新特性，不如說(shuō)是對(duì)類(lèi)型推導(dǎo)的bug修復(fù)。

針對(duì)類(lèi)型推導(dǎo)還有其他一些修復(fù)和報(bào)錯(cuò)信息的內(nèi)容優(yōu)化，但這些都沒(méi)上面這個(gè)變化大，所以恕不贅述。

panic的行為變化

1.21開(kāi)始如果goroutine里有panic，那么這個(gè)goroutine里的defer里調(diào)用的recover必然不會(huì)返回nil值。

這導(dǎo)致了一個(gè)問(wèn)題：recover的返回值是傳給panic的參數(shù)的值，panic(nil)這樣的代碼怎么辦？

先要提醒一下，panic(nil)本身是無(wú)意義的，且會(huì)導(dǎo)致recover的調(diào)用方無(wú)法判斷究竟發(fā)生了什么，所以一直是被各類(lèi)linter包括go vet命令警告的。然而這么寫(xiě)語(yǔ)法上完全正確，所以只有警告并不能解決問(wèn)題。

解決辦法是，如果現(xiàn)在使用panic(nil)或者panic(值為nil的接口)，recover會(huì)收到一個(gè)新類(lèi)型的error：*runtime.PanicNilError。

總體上算是解決了問(wèn)題，然而它把有類(lèi)型的但值是nil的接口也給轉(zhuǎn)換了，雖然從最佳實(shí)踐的角度來(lái)講panic一個(gè)空值的接口是不應(yīng)該的，但多少還是會(huì)給使用上帶來(lái)一些麻煩。

所以目前想要禁用這一行為的話(huà)，可以設(shè)置環(huán)境變量：export GODEBUG=panicnil=1。如果go.mod里聲明的go版本小于等于1.20，這個(gè)環(huán)境變量的功能自動(dòng)啟用。

對(duì)于modules的變化，會(huì)在下一節(jié)講解。

modules的變化

最大的變化是現(xiàn)在mod文件里寫(xiě)的go版本號(hào)的意義改變了。

變成了：mod文件里寫(xiě)的go的版本意味著這個(gè)mod最低支持的golang版本是多少。

比如：

module github.com/apocelipes/flatmap

go 1.21.0

意味著這個(gè)modules最低要求go的版本是go1.21.0，而且可以注意到，現(xiàn)在patch版本也算在內(nèi)里，所以一個(gè)聲明為go 1.21.1的modules沒(méi)法被1.21.0版本的go編譯。

這么做的好處是能?chē)?yán)格控制自己的程序和庫(kù)可以在哪些版本的golang上運(yùn)行，且可以推動(dòng)庫(kù)版本和golang本身版本的升級(jí)。

如果嚴(yán)格按照官方要求使用語(yǔ)義版本來(lái)控制自己的modules的話(huà)，這個(gè)改動(dòng)沒(méi)有什么明顯的壞處，唯一的缺點(diǎn)是只有1.21及更高版本的go工具鏈才有這樣的功能。

這個(gè)變更對(duì)go.work文件同樣適用。

包初始化順序的改變

現(xiàn)在按新的順序來(lái)初始化包：

1. 把所有的packages按導(dǎo)入路徑進(jìn)行排序（字符串字典順序）存進(jìn)一個(gè)列表
2. 按要求和順序找到列表里第一個(gè)符合條件的package，要求是這個(gè)package所有的import的包都已經(jīng)完成初始化
3. 初始化這個(gè)找到的包然后把它移出列表，接著重復(fù)第二步
4. 列表為空的時(shí)候初始化流程結(jié)束

這樣做的好處是包的初始化順序終于有明確的標(biāo)準(zhǔn)化的定義了，壞處有兩點(diǎn)：

1. 以前的程序如果依賴(lài)于特定的初始化順序，那么在新版本會(huì)出問(wèn)題
2. 現(xiàn)在可以通過(guò)修改package的導(dǎo)入路徑（主要能改的部分是包的名字）和控制導(dǎo)入的包來(lái)做到讓A包始終在B包之前初始化，因此B包的初始化流程里可以對(duì)A包公開(kāi)出來(lái)的接口或者數(shù)據(jù)進(jìn)行修改，這樣做耦合性很高也不安全，尤其是B包如果是某個(gè)包含惡意代碼的包的話(huà)。

我們能做的只有遵守最佳實(shí)踐：不要依賴(lài)特定的包直接的初始化順序；以及在使用某個(gè)第三方庫(kù)前要仔細(xì)考量。

編譯器和runtime的變化

runtime的變化上，gc一如既往地得到了小幅度優(yōu)化，現(xiàn)在對(duì)于gc壓力較大的程序來(lái)說(shuō)gc延遲和內(nèi)存占用都會(huì)有所減少。

cgo也有優(yōu)化，現(xiàn)在cgo函數(shù)調(diào)用最大可以比原先快一個(gè)數(shù)量級(jí)。

編譯器的變化上比較顯著的是這個(gè)：PGO已經(jīng)可以正式投入生產(chǎn)使用。使用教程。

PGO可以帶來(lái)6%左右的性能提升，1.21憑借PGO和上個(gè)版本的優(yōu)化現(xiàn)在不僅沒(méi)有了泛型帶來(lái)的編譯速度減低，相比以前還有細(xì)微提升。

還有最后一個(gè)變化，這個(gè)和編譯器關(guān)系：現(xiàn)在沒(méi)有被使用的全局的map類(lèi)型的變量（需要達(dá)到一定大小，且初始化的語(yǔ)句中沒(méi)有任何副作用會(huì)產(chǎn)生），現(xiàn)在編譯完成的程序里不會(huì)在包含這個(gè)變量。因?yàn)閙ap本身占用內(nèi)存且初始化需要花費(fèi)一定時(shí)間（map越大花的時(shí)間越多）。這個(gè)好處是很實(shí)在的，既可以減小產(chǎn)生的二進(jìn)制可執(zhí)行文件的大小，又可以提升運(yùn)行性能。但有個(gè)缺點(diǎn)，如果有什么程序要依賴(lài)編譯好的可執(zhí)行文件內(nèi)部的某些數(shù)據(jù)的話(huà)，這個(gè)變更可能會(huì)帶來(lái)麻煩，普通用戶(hù)可以忽略這點(diǎn)。

新標(biāo)準(zhǔn)庫(kù)

這個(gè)版本添加了大把的新標(biāo)準(zhǔn)庫(kù)，一起來(lái)看看。

log/slog和testing/slogtest

官方提供的結(jié)構(gòu)化日志庫(kù)。

可以通過(guò)實(shí)現(xiàn)slog.Handler來(lái)定義自己的日志處理器，可以把日志轉(zhuǎn)換成json等格式。標(biāo)準(zhǔn)庫(kù)自帶了很多預(yù)定義的處理器，比如json的：

logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
logger.Info("hello", "count", 3)
// {"time":"2023-08-09T15:28:26.000000000+09:00","level":"INFO","msg":"hello","count":3}

簡(jiǎn)單得說(shuō)，就是個(gè)簡(jiǎn)化版的zap，如果想使用最基礎(chǔ)的結(jié)構(gòu)化日志的功能，又不想引入zap這樣的庫(kù)，那么slog是個(gè)很好的選擇。

testing/slogtest里有幫助函數(shù)用來(lái)測(cè)試自己實(shí)現(xiàn)的日志處理器是否符合標(biāo)準(zhǔn)庫(kù)的要求。

slices和maps

把golang.org/x/exp/slices和golang.org/x/exp/maps引入了標(biāo)準(zhǔn)庫(kù)。

slices庫(kù)提供了排序、二分查找、拼接、增刪改查等常用功能，sort這個(gè)標(biāo)準(zhǔn)庫(kù)目前可以停止使用用slices來(lái)替代了。

maps提供了常見(jiàn)的對(duì)map的增刪改查拼接合并等功能。

兩個(gè)庫(kù)使用泛型，且針對(duì)golang的slice和map進(jìn)行了細(xì)致入微的優(yōu)化，性能上比自己寫(xiě)的版本有更多優(yōu)勢(shì)，比標(biāo)準(zhǔn)庫(kù)sort更是有數(shù)量級(jí)的碾壓。

這兩個(gè)庫(kù)本來(lái)1.20就該被接收進(jìn)標(biāo)準(zhǔn)庫(kù)了，但因?yàn)樾枰匦略O(shè)計(jì)api和進(jìn)行優(yōu)化，所以拖到1.21了。

cmp

這個(gè)也是早該進(jìn)入標(biāo)準(zhǔn)庫(kù)的，但拖到了現(xiàn)在。隨著slices、maps和新內(nèi)置函數(shù)都進(jìn)入了新版本，這個(gè)庫(kù)想不接收也不行了。

這個(gè)庫(kù)一共有三個(gè)東西：Ordered、Less、Compare。

最重要的是Ordered，它是所有可以使用內(nèi)置運(yùn)算符進(jìn)行比較的類(lèi)型的集合。

Less和Ordered顧名思義用來(lái)比大小的，且只能比Ordered類(lèi)型的大小。

之所以還有單獨(dú)造出這兩個(gè)函數(shù)，是因?yàn)樗麄儗?duì)Nan有檢查，比如：

// Less reports whether x is less than y.
// For floating-point types, a NaN is considered less than any non-NaN,
// and -0.0 is not less than (is equal to) 0.0.
func Less[T Ordered](x, y T) bool {
	return (isNaN(x) && !isNaN(y)) || x < y
}

所以在泛型函數(shù)里不知道要比較的數(shù)據(jù)的類(lèi)型是不是有float的時(shí)候，用cmp里提供的函數(shù)是最安全的。這就是他倆存在的意義。

但如果可以100%確定沒(méi)有float存在，那么就不應(yīng)該用Less等，應(yīng)該直接用運(yùn)算符去比較，因?yàn)榇蠹叶伎吹?，Less和直接比較相比效率是較低的。

已有的標(biāo)準(zhǔn)庫(kù)的變化

因?yàn)槭撬儆[，所以我只挑重點(diǎn)說(shuō)。

bytes

bytes.Buffer添加了AvailableBuffer和Available兩個(gè)方法，分別返回目前可用的buf切片和可用的長(zhǎng)度。主要可以配合strconv.AppendInt來(lái)使用，直接把數(shù)據(jù)寫(xiě)入buffer對(duì)應(yīng)的內(nèi)存里，可以提升性能。不要對(duì)AvailableBuffer返回的切片擴(kuò)容，否則必然踩坑。

context

新的context.WithoutCancel會(huì)把原來(lái)的context.Context復(fù)制一份，并去除cancel函數(shù)，這意味著原先被復(fù)制的上下文取消了這個(gè)新的上下文也將繼續(xù)存在。例子：

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    newCtx := context.WithoutCancel(ctx)
    cancel()
    <-ctx.Done() // ok, ctx has cancled.
    <-newCtx.Done() // error: dead lock!
}

之所以會(huì)死鎖，是因?yàn)?code>newCtx沒(méi)有被取消，Done返回的chan會(huì)永遠(yuǎn)阻塞住。而且更根本的，newCtx無(wú)法被取消。

新增了context.WithDeadlineCause和context.WithTimeoutCause，可以增加超時(shí)上下文被取消時(shí)的信息：

d := time.Now().Add(shortDuration)
ctx, cancel := context.WithDeadline(context.Background(), d, &MyError{"my message"})
cancel()
context.Cause(ctx) // --> &MyError{"my message"}

雖然不如context.WithCancelCause靈活，但也很實(shí)用。

crypto/sha256

現(xiàn)在在x86_64平臺(tái)上計(jì)算sha256會(huì)盡量利用硬件指令（simd和x86_64平臺(tái)的SHA256ROUND等指令），這帶來(lái)了3-4倍的性能提升。

net

現(xiàn)在golang在Linux上已經(jīng)初步支持Multipath TCP。有關(guān)Multipath TCP的信息可以在這查閱：https://www.multipath-tcp.org/

reflect

ValueOf現(xiàn)在會(huì)根據(jù)逃逸分析把值分配在棧上，以前都是直接分配到堆上的。對(duì)于比較小的類(lèi)型來(lái)說(shuō)可以獲得10%以上的性能提升。利好很多使用反射的ORM框架。

新增了Value.Clear，對(duì)應(yīng)第一節(jié)的clear內(nèi)置函數(shù)，如果type不是map或者slice的話(huà)這個(gè)函數(shù)和其他反射的方法一樣會(huì)panic。

runtime

最值得一提的變化是新增了runtime.Pinner。

它的能力是可以讓某個(gè)go的對(duì)象不會(huì)gc回收，一直到Unpin方法被調(diào)用。這個(gè)是為了方便cgo代碼里讓c使用go的對(duì)象而設(shè)計(jì)的。

不要濫用這個(gè)接口，如果想告訴gc某個(gè)對(duì)象暫時(shí)不能回收，應(yīng)該正確使用runtime.KeepAlive。

runtime/trace現(xiàn)在有了很大的性能提升，因此觀察程序行為的時(shí)候開(kāi)銷(xiāo)更小，更接近程序真實(shí)的負(fù)載。

sync

添加了OnceFunc、OnceValue、OnceValues這三個(gè)幫助函數(shù)。主要是為了簡(jiǎn)化代碼。

1.21前：

var initFlag sync.Once

func GetSomeThing() {
    initFlag.Do(func(){
        真正的初始化邏輯
    })
    // 后續(xù)處理
}

現(xiàn)在變成：

var doInit = sync.OnceFunc(func(){
    真正的初始化邏輯
})

func GetSomeThing() {
    doInit()
    // 后續(xù)處理
}

新代碼要簡(jiǎn)單點(diǎn)。

OnceValue、OnceValues是函數(shù)帶返回值的版本，支持一個(gè)和兩個(gè)返回值的函數(shù)。

errors

新增了errors.ErrUnsupported。這個(gè)錯(cuò)誤表示當(dāng)前操作系統(tǒng)、硬件、協(xié)議、或者文件系統(tǒng)不支持某種操作。

目前os，filepath，syscall，io里的一些函數(shù)已經(jīng)會(huì)返回這個(gè)錯(cuò)誤，可以用errors.Is(err, errors.ErrUnsupported)來(lái)檢查。

unicode

升級(jí)到了最新的Unicode 15.0.0。

平臺(tái)支持變化

新增了wasip1支持，這是一個(gè)對(duì)WASI（WebAssembly System Interface）的初步支持。

對(duì)于macOS，go1.21需要macOS 10.15 Catalina及以上版本。

龍芯上golang現(xiàn)在支持將代碼編譯為c的動(dòng)態(tài)和靜態(tài)鏈接庫(kù)，基本上在龍芯上已經(jīng)可以嘗試投入生產(chǎn)環(huán)境了。

總結(jié)

上面就是我認(rèn)為需要關(guān)注一下的go1.21的新特性，不是所有的變化都羅列在其中。

比如實(shí)驗(yàn)性支持的新的for-range語(yǔ)義我就沒(méi)寫(xiě)，這個(gè)還在早期實(shí)驗(yàn)階段，后續(xù)可能會(huì)被砍掉也可能行為上有極大變化，所以現(xiàn)在花精力關(guān)注不是很值得。

如果對(duì)其他變更有興趣，可以看完整的發(fā)版日志。

不過(guò)還是開(kāi)頭說(shuō)的那句話(huà)，先別急著在生產(chǎn)環(huán)境上升級(jí)，可以等到第一個(gè)patch版本出來(lái)了再說(shuō)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-635490.html

到了這里，關(guān)于golang1.21新特性速覽的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！