heap profile: :  [: ] @ heap/

:  [: ] @ 0x28d9f 0x2a201 0x2a28a 0x2624d 0x26188 0x94ca3 0x94a0b 0x17add6 0x17ae9f 0x1069d3 0xfe911 0xf0a3e 0xf0d22 0x21a70

#    0x2a201    cnew+0xc1    runtime/malloc.goc:

#    0x2a28a    runtime.cnewarray+0x3a            runtime/malloc.goc:

#    0x2624d    makeslice1+0x4d                runtime/slice.c:

#    0x26188    runtime.makeslice+0x98            runtime/slice.c:

#    0x94ca3    bytes.makeSlice+0x63            bytes/buffer.go:

#    0x94a0b    bytes.(*Buffer).ReadFrom+0xcb        bytes/buffer.go:

#    0x17add6    io/ioutil.readAll+0x156            io/ioutil/ioutil.go:

#    0x17ae9f    io/ioutil.ReadAll+0x3f            io/ioutil/ioutil.go:

#    0x1069d3    godoc/vfs.ReadFile+0x133            godoc/vfs/vfs.go:

#    0xfe911    godoc.func·+0x471            godoc/meta.go:

#    0xf0a3e    godoc.(*Corpus).updateMetadata+0x9e        godoc/meta.go:

#    0xf0d22    godoc.(*Corpus).refreshMetadataLoop+0x42    godoc/meta.go:

:  [: ] @ 0x28d9f 0x29059 0x1d252 0x1d450 0x106993 0xf1225 0xe1489 0xfbcad 0x21a70

#    0x1d252    newdefer+0x112                runtime/panic.c:

#    0x1d450    runtime.deferproc+0x10            runtime/panic.c:

#    0x106993    godoc/vfs.ReadFile+0xf3            godoc/vfs/vfs.go:

#    0xf1225    godoc.(*Corpus).parseFile+0x75        godoc/parser.go:

#    0xe1489    godoc.(*treeBuilder).newDirTree+0x8e9    godoc/dirtrees.go:

#    0xfbcad    godoc.func·+0x15d            godoc/dirtrees.go:

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

   }()

}

type X struct {

    buf      []byte

    bufArray []byte // Buf usually does not grow beyond 16 bytes.

}

func MakeX() *X {

    x := &X{}

    // Preinitialize buf with the backing array.

    x.buf = x.bufArray[:]

    return x

}

5. 不包含任何指针的对象(注意 strings,slices,maps 和 chans 包含隐含指针)不会被垃圾回收器扫描到。比如，1GB 的分片实际上不会影响垃圾回收时间。因此如果你删除被频繁使用的对象指针，它会对垃圾回收时间造成影响。一些建议：使用索引替换指针，将对象分割为其中之一不含指针的两部分。

6. 使用释放列表来重用临时对象，减少内存分配。标准库包含的 sync.Pool 类型可以实现垃圾回收期间多次重用同一个对象。然而需要注意的是，对于任何手动内存管理的方案来说，不正确地使用sync.Pool 会导致 use-after-free bug。

你也可以使用Garbage Collector Trace(见后文)来获取更深层次的内存问题。

阻塞分析器

阻塞分析器展示了goroutine在等待同步原语(包括计时器通道)被阻塞的位置。你可以用类似CPU分析器的方法来收集这些信息：通过'go test --blockprofile', net/http/pprof(经由h ttp://myserver:6060:/debug/pprof/block) 或者调用 runtime/pprof.Lookup("block").WriteTo。

值得警示的是，阻塞分析器默认未激活。'go test --blockprofile' 将为你自动激活它。然而，如果你使用net/http/pprof 或者 runtime/pprof，你就需要手动激活它(否则分析器将不会被载入)。通过调用 runtime.SetBlockProfileRate 来激活阻塞分析器。SetBlockProfileRate 控制着由阻塞分析器报告的goroutine阻塞事件的比率。分析器力求采样出每指定微秒数内，一个阻塞事件的阻塞平均数。要使分析器记录每个阻塞事件，将比率设为1。

如果一个函数包含了几个阻塞操作而且并没有哪一个明显地占有阻塞优势，那就在pprof中使用--lines标志。

注意：并非所有的阻塞都是不利的。当一个goroutine阻塞时，底层的工作线程就会简单地转换到另一个goroutine。所以Go并行环境下的阻塞
与非并行环境下的mutex的阻塞是有很大不同的（例如典型的C++或Java线程库，当发生阻塞时会引起线程空载和高昂的线程切换）。为了让你感受一
下，我们来看几个例子。

在
time.Ticker上发生的阻塞通常是可行的，如果一个goroutine阻塞Ticker超过十秒，你将会在profile中看到有十秒的阻塞，这
是很好的。发生在sync.WaitGroup上的阻塞经常也是可以的，例如，一个任务需要十秒，等待WaitGroup完成的goroutine会在

profile中生成十秒的阻塞。发生在sync.Cond上的阻塞可好可坏，取决于情况不同。消费者在通道阻塞表明生产者缓慢或不工作。生产者在通道阻塞，表明消费者缓慢，但这通常也是可以的。在基于通道的信号量发生阻塞，表明了限制在这个信号量上的goroutine的数量。发生在sync.Mutex或sync.RWMutex上的阻塞通常是不利的。你可以在可视化过程中，在pprof中使用--ignore标志来从profile中排除已知的无关阻塞。

goroutine的阻塞会导致两个消极的后果：

1. 程序与处理器之间不成比例，原因是缺乏工作。调度器追踪工具可以帮助确定这种情况。

2. 过多的goroutine阻塞/解除阻塞消耗了CPU时间。CPU分析器可以帮助确定这种情况（在系统组件中找）。

这里是一些通常的建议，可以帮助减少goroutine阻塞：

1. 在生产者--消费者情景中使用充足的缓冲通道。无缓冲的通道实际上限制了程序的并发可用性。

2. 针对于主要为读取的工作量，使用sync.RWMutex而不是sync.Mutex。因为读取操作在sync.RWMutex中从来不会阻塞其它的读取操作。甚至是在实施级别。

3. 在某些情况下，可以通过使用copy-on-write技术来完全移除互斥。如果受保护的数据结构很少被修改，可以为它制作一份副本，然后就可以这样更新它：

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 = 

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 = 

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 =

    }

}

这种技术并不仅限于通道，它还能用于批量更新映射（map）、批量分配等等。

6. 针对freelists，使用sync.Pool代替基于通道的或互斥保护的freelists，因为sync.Pool内部使用智能技术来减少阻塞。

Go协程分析器

Go协程分析器简单地提供给你当前进程中所有活跃的Go协程堆栈。它可以方便地调试负载平衡问题（参考下面的调度器追踪章节），或调试死锁。

这个配置仅仅对运行的程序有意义，所以去测试而不是揭露它. 你可以用net/http/pprof通过http://myserver:6060:/debug/pprof/goroutine来收集配置，并将之形象化为svg/pdf或通过调用runtime/pprof.Lookup("goroutine").WriteTo形象化。但最有用的方式是在你的浏览器中键入http://myserver:6060:/debug/pprof/goroutine?debug=2，它将会给出与程序崩溃时相同的符号化的堆栈。

需要注意的是：Go协程“syscall”将会消耗一个OS线程，而其他的Go协程则不会（除了名为runtime.LockOSThread的Go协程，不幸的是，它在配置中是不可见的）。同样需要注意的是在“IO wait”状态的Go协程同样不会消耗线程，他们停驻在非阻塞的网络轮询器（通常稍后使用epoll/kqueue/GetQueuedCompletionStatus来唤醒Go协程）。

垃圾收集器追踪

除了性能分析工具以外，还有另外几种工具可用——追踪器。它们可以追踪垃圾回收，内存分配和goroutine调度状态。要启用垃圾回收器（GC）追踪你需要将GODEBUG=gctrace=1加入环境变量，再运行程序：

$ GODEBUG=gctrace=1 ./myserver

然后程序在运行中会输出类似结果：

来看看这些数字的意思。每个GC输出一行。第一个数字（"gc9"）是GC的编号（这是从程序开始后的第九个GC），在括号中的数字（"(2)"）是参与GC的工作线程的编号。随后的四个数字（"12+1+744+8 us"）分别是工作线程完成GC的stop-the-world, sweeping, marking和waiting时间，单位是微秒。接下来的两个数字（"2 -> 10 MB"）表示前一个GC过后的存活堆大小和当前GC开始前完整的堆（包括垃圾）的大小。再接下来的三个数字 （"108615 (593983-485368) objects"）是堆中的对象总数（包括垃圾）和和分配的内存总数以及空闲内存总数。后面的三个数字（"4825/3620/0 sweeps"）表示清理阶段（对于前一个GC）：总共有4825个存储器容量，3620立即或在后台清除，0个在stop-the-world阶段清除（剩余的是没有使用的容量）。再后面的四个数字（"0(0) handoff, 6(91) steal"）表示在平行的标志阶段的负载平衡：0个切换操作（0个对象被切换）和六个steal 操作（91个对象被窃取）最后的三个数字（"16/1/0 yields"）表示平行标志阶段的系数：在等候其它线程的过程*有十七个yield操作。

跟踪信息包括内存块地址、大小、类型、执行程序ID和堆栈踪迹。它可能更有助于调试，但也可以给内存分配优化提供非常详细的信息。

调度器追踪

调度器追踪可以提供对 goroutine 调度的动态行为的内视，并且允许调试负载平衡和可扩展性问题。要启用调度器追踪，可以带有环境变量 GODEBUG=schedtrace=1000 来运行程序（这个值的意思是输入的周期，单位 ms，这种情况下是每秒一次）：

$ GODEBUG=schedtrace=1000 ./myserver

程序在运行过程中将会输出类似结果：

f, err := os.Create("heapdump")

 if err != nil { ... }

 debug.WriteHeapDump(f.Fd())