让我们假设你有一golang 程序，想改善其性能。有几种工具可以帮我们完成这个任务。这些工具可以帮我们识别程序中的热点(cpu,io,memory), 热点即是那些需要我们集中精力于其上，能显著改善改善性能的地方。然而，另外一种结果也是可能的，工具帮我们识别出程序里的多种性能缺陷。比如，每次查询数据库，你都准备sql 语句，然而，你可以在程序启动时，只准备一次。另一个例子，一个O(n^2)的算法莫名其妙的溜进，某些存在O(n) 算法的地方。为了识别出这些情况，你需要合理检查程序剖析所看到的结果。比如第一个例子中，有显著的时间花费在sql 语句准备阶段，这就是一个危险的信号。
了解多种关于性能的边界因素也是重要的。比如，你的程序使用100Mbps网络链路通信，它已经使用了链路90Mbps以上的带宽，那你的程序就没有太多性能改善空间。对于磁盘io，内存消耗，计算性任务也存在类似的情况。这些情况，铭记在心，接着我们可以查看可用的工具。
注意：工具之间会相互干扰，比如，精准的内存剖析会偏差cpu剖析，goroutine阻塞剖析影响调度器的追踪等，隔离地使用工具能够获得更精确的信息。以下阐述基于golang 1.3。
cpu 剖析器
go运行时内置cpu profiler，它可以显示哪些函数消耗了多少的百分比cpu时间，有三种方式可以访问它：
1.最简单的是go test 命令-cpuprofile标志，例如，以下命令：
$ go test -run=none -bench=ClientServerParallel4 -cpuprofile=cprof net/http
剖析给定的benchmark，把cpu profile 信息写入‘cprof' 文件
接着:
$ go tool pprof --text http.test cprof
打印最热点的函数列表，有几种可用输出格式，最有用的几个：--text,--web,--list.运行 'go tool pprof' 获取完整列表
2.net/http/pprof 包，这个方案对于网络服务应用十分理想，你仅需导入net/http/pprof,就可使用下面命令profile：
go tool pprof --text mybin http://myserver:6060:/debug/pprof/profile
3.手动profile 采集，需要引入runtime/pprof,在main函数添加下述代码：
if *flagCpuprofile != "" {
f, err := os.Create(*flagCpuprofile)
if err != nil {
log.Fatal(err)
}
pprof.StartCPUProfile(f)
defer pprof.StopCPUProfile()
}
剖析信息会写入指定的文件，与第一个选项同样方式可视化它。这里有一个使用--web 选项可视化的例子：
你可以使用--list=funcname 选项查阅单个函数，列如以下profile 显示时间append 函数时间花费：
. . 93: func (bp *buffer) WriteRune(r rune) error {
. . 94: if r < utf8.RuneSelf {
5 5 95: *bp = append(*bp, byte(r))
. . 96: return nil
. . 97: }
. . 98:
. . 99: b := *bp
. . 100: n := len(b)
. . 101: for n+utf8.UTFMax > cap(b) {
. . 102: b = append(b, 0)
. . 103: }
. . 104: w := utf8.EncodeRune(b[n:n+utf8.UTFMax], r)
. . 105: *bp = b[:n+w]
. . 106: return nil
. . 107: }
当剖析器不能解开调用栈时，使用三个特殊条目使用：GC，System，ExternalCode。GC 表示花费在垃圾回收的时间；System表示花费在goroutine 调度器，栈管理及其他辅助运行时代码的时间；ExternalCode，表示花费在调用本地动态库时间。这里有一些关于如何解释profile结果的提示：
如果你看到大量时间花费在runtime.mallocgc 函数，程序可能做了过多的小内存分配。profile能告诉你这些分配来自哪里。
如果大量时间花费在channel，sync.Mutex,其他的同步原语，或者系统组件，程序可能遭受资源争用。考虑以下从新组织代码结构，消除最常访问的共享资源。常用的技术包括分片/分区， 局部缓冲/聚集， 写时拷贝等。
如果大量时间花费在syscall.Read/Write, 程序可能产生了太多小数据量读写操作，可考虑使用bufio 包裹os.File or net.Conn。
如果大量时间花费在GC 组件，要么是程序分配了太多的临时对象，要么是堆内存太小，导致垃圾收集操作运行频繁。
注意：在当前的darwin 平台，cpu profiler 不能正确工作 darwin 不能正常工作；window 平台需要安装cygwin，perl，graphviz，用来生成svg/web profile；在linux平台，你也可使用perf system profiler，它不能解开go stack，但可剖析解开cgo/swig 代码和内核代码。
memory profiler
内存剖析器显示哪些函数分配堆内存，你可以采集它，使用’go test --memprofile', 或者net/http/ppro经由 http://myserver:6060:/debug/pprof/heap 或者调用 runtime/pprof.WriteHeapProfile。
你可以仅仅可视化profile 收集过程中的活跃分配(传递 --inuse_space 标志，默认),或者自程序启动以来的所有分配(--alloc_space )。
你可以显示分配了多少字节或者多少个对象(--inuse/alloc_space or --inuse/alloc_objects )。多次剖析过程中，profiler 趋向于采样更大的对象。了解大对象影响内存消耗和gc 时间，大量小分配影响执行速度也在某种程度影响gc时间。对象可以是持久或临时的生命周期。如果在程序启动时，你有几个大的持久对象分配，它们很可能被采集到。这些对象影响内存消耗和gc时间，但不影响正常的执行速度。另一方面，如果你有大量短生命周期对象，那么profile过程中，它们几乎不能被呈现。但它们对执行速度有显著影响，因为它们被分配释放很频繁。
一般情况是，如果你要减少内存消耗，考虑使用--inuse_space 选项的profile；如果是想要改善执行速度，使用--alloc_objects 选项profile。有几个选项可以用来控制报告的粒度，--function函数级别(默认),--lines,--files,--adrresses,行级，文件级，指令地址级。
优化通常是应用特定的，以下是一些常用建议：
1.合并对象进入更大的对象。例如，使用bytes.Buffer替代*bytes.Buffer,作为结构体成员，这个能减少内存分配次数，减轻gc压力。
2.那些脱离它们声明作用域的局部变量，被提升的堆内存分配。编译器通常不能判定几个这样变量有相同的生命周期，所以要单独分配它们。可以把下面代码：
for k, v := range m {
k, v := k, v // copy for capturing by the goroutine
go func() {
// use k and v
}()
}
替换为：
for k, v := range m {
x := struct{ k, v string }{k, v} // copy for capturing by the goroutine
go func() {
// use x.k and x.v
}()
}
使用一次分配代替两次，但对代码可读性有消极影响，所以适度使用。
3.一个合并分配的特例，如果你了解使用中slice典型大小，slice的底层数组可以使用预分配。
type X struct {
buf []byte
bufArray [16]byte // Buf usually does not grow beyond 16 bytes.
}
func MakeX() *X {
x := &X{}
// Preinitialize buf with the backing array.
x.buf = x.bufArray[:0]
return x
}
4.使用占用空间小的数据类型， 比如，使用 int8 替代 int。
5.那些不包含任何指针的对象(注意：string,slice,map,chan 包含隐式指针),不会被垃圾收集器扫描。比如 1Gb byte slice 不会影响gc time，从活跃使用的对象中移除指针，能对gc time 产生正面影响。一些可能方式：使用索引替代指针，分割对象成两部分，其中一部分没有任何指针。
6.使用freelist 重用临时对象，减少分配次数。标准库包含的sync.Pool 类型允许在gc 之间多次重用同一个对象。不过要意识到，就像任何手动内存管理模式一样，不正确地使用sync.Pool 可以导致 use-after-free bug。
Blocking Profile
goroutine 阻塞 profiler展示goroutine 阻塞等待同步原语(包括定时器channel)，出现在代码中哪些地方。你可以使用‘go test --blockprofile', net/http/pprof 经由 http://myserver:6060:/debug/pprof/block，或者调用 runtime/pprof.Lookup("block").WriteTo
阻塞剖析器默认没有被开启，’go test --blockprofile‘ 会为你自动开启，但是使用net/http/pprof, runtime/pprof,需要你手动开启。调用runtime.SetBlockProfileRate，开启阻塞剖析器，SetBlockProfileRate 控制blocking profile 中阻塞时间的报告粒度。
如果一个函数包含多个阻塞操作，了解到那个操作导致阻塞，就变得不太明晰，如此可以使用--lines 标志辨别。
注意并不是所有的阻塞都是不好的。当一个goroutine阻塞，底层工作线程会切换到另一个goroutine。这样以来，协作的go环境的阻塞与非协作系统互斥器上的阻塞，就有着显著差异。(c++, java 线程库里，阻塞会导致线程空闲，和昂贵的线程上下文切换)
在time.Ticker 上阻塞通常没什么问题。如果一个goroutine在一个ticker上阻塞10 s，阻塞剖析中也会看到10s阻塞。在sync.WaitGroup 上阻塞，大多也没什么问题。例如，一个任务花费10s，goroutine在waitgroup等待，记账10s。在sync.Cond 上阻塞是好是坏，取决于具体情况。消费者阻塞在channel 上，暗示生产者的慢速，或者缺少可以做的工作。生产者阻塞在channel 上，暗示消费者的慢速，通常这也不是个问题。阻塞于channel基于的信号量，显示有多少goroutine被卡在信号量上。阻塞于sync.Mutex, sync,RWMutex, 一般不太好。你可以使用--ignore 排除那些不感兴趣的阻塞事件。
goroutine的阻塞产生两种消极后果：
1. 程序不能与处理器线性比例伸缩。
2. 过多的goroutine阻塞与解阻塞，消耗太多cpu时间。
以下是一些提示帮助减少goroutine阻塞：
1. 在匹配生产者，消费者模型代码中，使用充足缓冲的 buffer channel，无缓冲channel实质上限制了程序的并行度。
2. 在有很多读取操作， 很少修改数据操作的场景，使用sync.RWMutex 代替 sync.Mutex。读者之间不会相互阻塞。
3. 某些场景甚至可以通过使用写时拷贝技术完全移除mutex。如果被保护的数据结构修改的 不太频繁，制造一份拷贝是可行的：
type Config struct {
Routes map[string]net.Addr
Backends []net.Addr
}
var config unsafe.Pointer // actual type is *Config
// Worker goroutines use this function to obtain the current config.
func CurrentConfig() *Config {
return (*Config)(atomic.LoadPointer(&config))
}
// Background goroutine periodically creates a new Config object
// as sets it as current using this function.
func UpdateConfig(cfg *Config) {
atomic.StorePointer(&config, unsafe.Pointer(cfg))
}
这个模式防止写者在更新操作时阻塞了读者的活动。
4.分区是另外一种常用的在易变数据结构上减少争用/阻塞的技术。下面是一个怎么分区一个hashmap 的示例：
type Partition struct {
sync.RWMutex
m map[string]string
}
const partCount = 64
var m [partCount]Partition
func Find(k string) string {
idx := hash(k) % partCount
part := &m[idx]
part.RLock()
v := part.m[k]
part.RUnlock()
return v
}
5. 局部缓冲和批量更新可以帮助减少不可分区的数据结构上争用。
const CacheSize = 16
type Cache struct {
buf [CacheSize]int
pos int
}
func Send(c chan [CacheSize]int, cache *Cache, value int) {
cache.buf[cache.pos] = value
cache.pos++
if cache.pos == CacheSize {
c <- cache.buf
cache.pos = 0
}
}
这个技术并不限于channel上，可以用在批量更新map， 批量分配内存。
6. 使用sync.Pool 的freelist ，而非基于channel，或mutex 保护的 freelist。sync.Pool 内部用了一些聪明技术减少阻塞。
Goroutine Profiler
goroutine 剖析器仅是让你看到进程所有活跃goroutine的当前堆栈，这个对于调试负载均衡及死锁问题，十分方便。
goroutine profile 仅对运行中的应用程序，显得合理，所以go test 命令做不到这点。你可以使用 net/http/pprof 经由 http://myserver:6060:/debug/pprof/goroutine 或者调用 runtime/pprof.Lookup("goroutine").WriteTo 。但是最有用的方法是在浏览器里键入 http://myserver:6060:/debug/pprof/goroutine?debug=2， 你会看到类似程序崩溃时的堆栈追踪。注意显示 “syscall" 状态的goroutine 消费os 线程，其他goroutine不会。”io wait“ 状态的goroutine 也不消费os 线程，它们停靠在非阻塞的网络轮询器上。
