1. 其余语言关于接口的设计都是实现类服务于接口,而Golang彷佛是方法为主接口为辅,能够先考虑实体再考虑接口。服务器
2. select和switch是类似的,case之间是互斥的。因此超时可在一个一秒超时的timeout goroutine中设置一个sleep(1e9),参数单位是纳秒,而后用一个case <-timeout去捕捉超时,这样就会顺利跳出select,再也不去等待其余的goroutine。函数
是否能够将总的计算时间降到接近原来的1/N呢?答案是不必定。若是掐秒表(正常点的话,应该用7.8节中介绍的Benchmark方法),会发现总的执行时间没有明显缩短。再去观察CPU运行状态,你会发现尽管咱们有16个CPU核心,但在计算过程当中其实只有一个CPU核心处于繁忙状态,
这是会让不少Go语言初学者迷惑的问题。线程官方的答案是,这是当前版本的Go编译器还不能很智能地去发现和利用多核的优点。虽然咱们确实建立了多个goroutine,而且从运行状态看这些goroutine也都在并行运行,但实际上全部这些goroutine都运行在同一个CPU核心上,在一个goroutine获得时间片执行的时候,其余goroutine都会处于等待状态。从这一点能够看出,虽然goroutine简化了咱们写并行代码的过程,但实际上总体运行效率并不真正高于单线程程序。设计
在Go语言升级到默认支持多CPU的某个版本以前,咱们能够先经过设置环境变量GOMAXPROCS的值来控制使用多少个CPU核心。具体操做方法是经过直接设置环境变量GOMAXPROCS的值,或者在代码中启动goroutine以前先调用如下这个语句以设置使用16个CPU核心:runtime.GOMAXPROCS(16)接口
到底应该设置多少个CPU核心呢,其实runtime包中还提供了另一个函数NumCPU()来获取核心数。能够看到,Go语言其实已经感知到全部的环境信息,下一版本中彻底能够利用这些信息将goroutine调度到全部CPU核心上,从而最大化地利用服务器的多核计算能力。抛弃GOMAXPROCS只是个时间问题。编译器