1.管道chan吞吐极限10,000,000，单次Put,Get耗时大约100ns/op，无论是采用单Go程，还是多Go程并发(并发数:100, 10000, 100000)，耗时均没有变化，Go内核这对chan进行优化。
解决之道：在系统设计时，避免使用管道chan传递主业务数据，避免将业务流程处理流程分割到对个Go程中执行，这样做减少chan传输耗时，和Go程调度耗时，性能会有很大的提升。
案例分析：nsq和nats都是实时消息队列，nsq在客户端端和服务端大量使用chan转发消息，导致性能不佳，只有100,000／s；而nats服务端在分发消息流程中，没有使用chan，只在客户端接收时使用chan，性能可达到1,000,000／s。
2.互斥锁Mutex在单Go程时Lock,Unlock耗时大约20ns/op，但是采用多Go程时，性能急剧下降，并发越大耗时越长，在Go1.5并发数达到1024耗时900ns/op，Go1.6优化到300ns/op，究其原因，是构建在CPU的原子操作之上，抢占过于频繁将导致，消耗大量CPU时钟，进而CPU多核无法并行。
解决之道：采用分区，将需要互斥保护的数据，分成多个固定分区(建议是2的整数倍，如256)，访问时先定位分区(不互斥)，这样就可降低多个Go程竞争1个数据分区的概率。
案例分析：Golang的Go程调度模块，在管理大量的Go程，使用的就是数据分区。
3.select异步操作在单管道时耗时120ns/op，但是随着管道数增加，性能线性下降，每增加1个管道增加100ns/op，究其原因，slelect时当chan数超过1后，Go内部是创建一个Go程，有它每1ms轮训的方式检查每个chan是否可用，而不是采用事件触发。
解决之道：在select中避免使用过多的管道chan分支，或者把无法用到的chan置为nil；解决select超时，避免使用单独的超时管道，应与数据返回管道共享。
案例分析：nsq和nats都是实时消息队列，由于nsq大量使用chan，这就必然导致大量使用select对多chan操作，结果是性能不高。
4.Go调度性能低下，当出现1,000,000Go程时，Go的调度器的性能急剧下降。
解决之道：避免动态创建Go程，服务端收到数据并处理的流程中，避免使用chan传递业务数据，这样会引起Go程调度。
案例分析：nsq和nats都是实时消息队列，由于nsq大量使用chan，这就必然导致在服务过程中，引起Go调度，结果是性能不高。
5.defer性能不高，每次defer耗时100ns，，在一个func内连续出现多次，性能消耗是100ns*n，累计出来浪费的cpu资源很大的。
解决之道：除了需要异常捕获时，必须使用defer；其它资源回收类defer，可以判断失败后，使用goto跳转到资源回收的代码区。
补充：defer 在 go1.8 快了一倍了。runtime: defer is slow · Issue #14939 · golang/go · GitHub
6.内存管理器性能低下，申请16字节的内存，单次消耗30ns，64字节单次消耗70ns，随着申请内存尺寸的增长，耗时会迅速增长。加上GC的性能在1.4, 1.5是都不高，直到1.6, 1.7才得到改善。
解决之道：建议使用pool，单次Put，Get的耗时大约在28ns，在并发情况下可达到18ns，比起每次创建，会节省很多的CPU时钟。
补充： 单纯看 Put, Get 耗时不高，但是 pool 取出来的是 interface{}，需要类型断言成实际类型，放进去的时候，还要把实际类型转换成 interface{}（虽然是自动的），这个转换的过程对于简单类型每次需要 30ns，复杂的结构体时间会长的多，所以这个开销算上的话，用 pool 方案反而会导致性能下降。
出于性能考虑的最佳实践和建议
（1）尽可能的使用:=去初始化声明一个变量（在函数内部）；
（2）尽可能的使用字符代替字符串；
（3）尽可能的使用切片代替数组；
（4）尽可能的使用数组和切片代替映射（详见参考文献15）；
（5）如果只想获取切片中某项值，不需要值的索引，尽可能的使用for range去遍历切片，这比必须查询切片中的每个元素要快一些；
（6）当数组元素是稀疏的（例如有很多0值或者空值nil），使用映射会降低内存消耗；
（7）初始化映射时指定其容量；
（8）当定义一个方法时，使用指针类型作为方法的接受者；
（9）在代码中使用常量或者标志提取常量的值；
（10）尽可能在需要分配大量内存时使用缓存；
（11）使用缓存模板（参考章节15.7）。