关于Go1.14，你必定想知道的性能提高与新特性

Go官方团队将在今年2月份发布1.14版本。相比较于以前的版本升级，Go1.14在性能提高上作了较大改动，还加入了不少新特性，咱们一块儿来看一下Go1.14都给咱们带来了哪些惊喜吧!

1.性能提高

先列举几个Go1.14在性能提高上作的改进。

1.1 defer性能“异常”牛逼

异常牛逼是有多牛逼呢？咱们能够经过一个简单benchmark看一看。用例以下(defer_test.go):

package main

import (
	"testing"
)

type channel chan int

func NoDefer() {
	ch1 := make(channel, 10)
	close(ch1)
}

func Defer() {
	ch2 := make(channel, 10)
	defer close(ch2)
}

func BenchmarkNoDefer(b *testing.B) {
	for i := 0; i < b.N; i++ {
		NoDefer()
	}
}

func BenchmarkDefer(b *testing.B) {
	for i := 0; i < b.N; i++ {
		Defer()
	}
}
复制代码

咱们分别使用Go1.13版本和Go1.14版本进行测试，关于Go多个版本的管理切换，推荐你们使用gvm，很是的方便。首先使用Go1.13版本，只须要命令:gvm use go1.13；以后运行命令：go test -bench=. -v，结果以下：

goos: darwin
goarch: amd64
pkg: github.com/GuoZhaoran/myWebSites/data/goProject/defer
BenchmarkNoDefer-4   	15759076	        74.5 ns/op
BenchmarkDefer-4     	11046517	       102 ns/op
PASS
ok  	github.com/GuoZhaoran/myWebSites/data/goProject/defer	3.526s
复制代码

能够看到，Go1.13版本调用defer关闭channel的性能开销仍是蛮大的，op几乎差了30ns。切换到go1.14：gvm use go1.14;再次运行命令：go test -bench=. -v，下面的结果必定会亮瞎了小伙伴的双眼：

goos: darwin
goarch: amd64
pkg: github.com/GuoZhaoran/myWebSites/data/goProject/defer
BenchmarkNoDefer
BenchmarkNoDefer-4   	13094874	        80.3 ns/op
BenchmarkDefer
BenchmarkDefer-4     	13227424	        80.4 ns/op
PASS
ok  	github.com/GuoZhaoran/myWebSites/data/goProject/defer	2.328s
复制代码

Go1.14版本使用defer关闭channel几乎0开销！

关于这一改进，官方给出的回应是：Go1.14提升了defer的大多数用法的性能，几乎0开销！defer已经能够用于对性能要求很高的场景了。

关于defer，在Go1.13版本已经作了一些的优化，相较于Go1.12，defer大多数用法性能提高了30%。而Go1.14的这次改进更是激动人心！关于Go1.14对defer优化的原理和细节，笔者尚未收集到参考资料，相信很快就会有大神整理出来，你们能够关注一下。关于Go语言defer的设计原理、Go1.13对defer作了哪些改进，推荐给你们下面几篇文章：

• 深刻理解defer上
• 深刻理解defer实现机制下
• Go1.13 defer性能是如何提升的

1.2 goroutine支持异步抢占

Go语言调度器的性能随着版本迭表明现的愈来愈优异，咱们来了解一下调度器使用的G-M-P模型。先是一些概念：

• G（Goroutine）： goroutine，由关键字go建立
• M（Machine）： 在Go中称为Machine，能够理解为工做线程
• P（Processor） ： 处理器 P 是线程 M 和 Goroutine 之间的中间层(并非CPU)

M必须持有P才能执行G中的代码，P有本身本地的一个运行队列runq，由可运行的G组成，Go语言调度器的工做原理就是处理器P的队列中选择队列头的goroutine 放到线程 M 上执行，下图展现了 线程 M、处理器 P 和 goroutine 的关系。

每一个P维护的G多是不均衡的，调度器还维护了一个全局G队列，当P执行完本地的G任务后，会尝试从全局队列中获取G任务运行(须要加锁)，当P本地队列和全局队列都没有可运行的任务时，会尝试偷取其余P中的G到本地队列运行(任务窃取)。

在Go1.1版本中，调度器还不支持抢占式调度，只能依靠 goroutine 主动让出 CPU 资源，存在很是严重的调度问题：

• 单独的 goroutine 能够一直占用线程运行，不会切换到其余的 goroutine，形成饥饿问题
• 垃圾回收须要暂停整个程序（Stop-the-world，STW），若是没有抢占可能须要等待几分钟的时间，致使整个程序没法工做

Go1.12中编译器在特定时机插入函数，经过函数调用做为入口触发抢占，实现了协做式的抢占式调度。可是这种须要函数调用主动配合的调度方式存在一些边缘状况，就好比说下面的例子：

package main

import (
	"runtime"
	"time"
)

func main() {
	runtime.GOMAXPROCS(1)
	
	go func() {
		for {
		}
	}()
	
	time.Sleep(time.Millisecond)
	println("OK")
}
复制代码

其中建立一个goroutine并挂起， main goroutine 优先调用了 休眠，此时惟一的 P 会转去执行 for 循环所建立的 goroutine，进而 main goroutine 永远不会再被调度。换一句话说在Go1.14以前，上边的代码永远不会输出OK。这是由于Go1.12实现的协做式的抢占式调度是不会使一个没有主动放弃执行权、且不参与任何函数调用的goroutine被抢占。

Go1.14 经过实现了基于信号的真抢占式调度解决了上述问题，这是一个很是大的改动，Go团队对已有的逻辑进行重构并为 goroutine 增长新的状态和字段来支持抢占。这一改动使得Go语言调度器更加健壮，调度性能更加优越，可是还有一些潜在的问题没有被发现，预计未来会在 STW 和栈扫描以外加入更多的抢占点。

关于调度器和Go语言的G-M-P并发模型，都是很是深刻的话题。下边推荐给读者的几篇文章，特别值得学习探索：

• 调度系统设计精要
• The Go Scheduler
• 欧长坤大神的做品《Go语言本来》

1.3 time.Timer定时器性能获得“巨幅”提高

咱们先来看一下官方的benchmark数据吧。数据来源

Changes in the time package benchmarks:

name                      old time/op  new time/op  delta
AfterFunc-12              1.57ms ± 1%  0.07ms ± 1%  -95.42%  (p=0.000 n=10+8)
After-12                  1.63ms ± 3%  0.11ms ± 1%  -93.54%  (p=0.000 n=9+10)
Stop-12                   78.3µs ± 3%  73.6µs ± 3%   -6.01%  (p=0.000 n=9+10)
SimultaneousAfterFunc-12   138µs ± 1%   111µs ± 1%  -19.57%  (p=0.000 n=10+9)
StartStop-12              28.7µs ± 1%  31.5µs ± 5%   +9.64%  (p=0.000 n=10+7)
Reset-12                  6.78µs ± 1%  4.24µs ± 7%  -37.45%  (p=0.000 n=9+10)
Sleep-12                   183µs ± 1%   125µs ± 1%  -31.67%  (p=0.000 n=10+9)
Ticker-12                 5.40ms ± 2%  0.03ms ± 1%  -99.43%  (p=0.000 n=10+10)
Sub-12                     114ns ± 1%   113ns ± 3%     ~     (p=0.069 n=9+10)
Now-12                    37.2ns ± 1%  36.8ns ± 3%     ~     (p=0.287 n=8+8)
NowUnixNano-12            38.1ns ± 2%  37.4ns ± 3%   -1.87%  (p=0.020 n=10+9)
Format-12                  252ns ± 2%   195ns ± 3%  -22.61%  (p=0.000 n=9+10)
FormatNow-12               234ns ± 1%   177ns ± 2%  -24.34%  (p=0.000 n=10+10)
MarshalJSON-12             320ns ± 2%   250ns ± 0%  -21.94%  (p=0.000 n=8+8)
MarshalText-12             320ns ± 2%   245ns ± 2%  -23.30%  (p=0.000 n=9+10)
Parse-12                   206ns ± 2%   208ns ± 4%     ~     (p=0.084 n=10+10)
ParseDuration-12          89.1ns ± 1%  86.6ns ± 3%   -2.78%  (p=0.000 n=10+10)
Hour-12                   4.43ns ± 2%  4.46ns ± 1%     ~     (p=0.324 n=10+8)
Second-12                 4.47ns ± 1%  4.40ns ± 3%     ~     (p=0.145 n=9+10)
Year-12                   14.6ns ± 1%  14.7ns ± 2%     ~     (p=0.112 n=9+9)
Day-12                    20.1ns ± 3%  20.2ns ± 1%     ~     (p=0.404 n=10+9)
复制代码

从基准测试的结果能够看出AfterFunc、After、Ticker这些time包的性能都获得了“巨副”提高。

在Go1.10以前的版本中，Go语言使用一个全局的四叉堆的小顶堆维护全部的timer。

在小顶堆中，父节点比其余四个节点都小，子节点以前没有大小关系。