1 内存优化
1.1 小对象合并成结构体一次分配，减小内存分配次数
作过C/C++的同窗可能知道，小对象在堆上频繁地申请释放，会形成内存碎片（有的叫空洞），致使分配大的对象时没法申请到连续的内存空间，通常建议是采用内存池。Go runtime底层也采用内存池，但每一个span大小为4k，同时维护一个cache。cache有一个0到n的list数组，list数组的每一个单元挂载的是一个链表，链表的每一个节点就是一块可用的内存，同一链表中的全部节点内存块都是大小相等的；可是不一样链表的内存大小是不等的，也就是说list数组的一个单元存储的是一类固定大小的内存块，不一样单元里存储的内存块大小是不等的。这就说明cache缓存的是不一样类大小的内存对象，固然想申请的内存大小最接近于哪类缓存内存块时，就分配哪类内存块。当cache不够再向spanalloc中分配。html
建议：小对象合并成结构体一次分配，示意以下：c++
for k, v := range m {
k, v := k, v // copy for capturing by the goroutine
go func() {
// using k & v
}()
}
替换为：golang
for k, v := range m {
x := struct {k , v string} {k, v} // copy for capturing by the goroutine
go func() {
// using x.k & x.v
}()
}
1.2 缓存区内容一次分配足够大小空间，并适当复用
在协议编解码时，须要频繁地操做[]byte，可使用bytes.Buffer或其它byte缓存区对象。编程
建议：bytes.Buffert等经过预先分配足够大的内存，避免当Grow时动态申请内存，这样能够减小内存分配次数。同时对于byte缓存区对象考虑适当地复用。api
1.3 slice和map采make建立时，预估大小指定容量
slice和map与数组不同，不存在固定空间大小，能够根据增长元素来动态扩容。数组
slice初始会指定一个数组，当对slice进行append等操做时，当容量不够时，会自动扩容：缓存
- 若是新的大小是当前大小2倍以上，则容量增涨为新的大小；
- 否而循环如下操做：若是当前容量小于1024，按2倍增长；不然每次按当前容量1/4增涨，直到增涨的容量超过或等新大小。
map的扩容比较复杂，每次扩容会增长到上次容量的2倍。它的结构体中有一个buckets和oldbuckets，用于实现增量扩容：性能优化
- 正常状况下，直接使用buckets，oldbuckets为空；
- 若是正在扩容，则oldbuckets不为空，buckets是oldbuckets的2倍，
建议：初始化时预估大小指定容量网络
m := make(map[string]string, 100) s := make([]string, 0, 100) // 注意：对于slice make时，第二个参数是初始大小，第三个参数才是容量
1.4 长调用栈避免申请较多的临时对象
goroutine的调用栈默认大小是4K（1.7修改成2K），它采用连续栈机制，当栈空间不够时，Go runtime会不动扩容：多线程
- 当栈空间不够时，按2倍增长，原有栈的变量崆直接copy到新的栈空间，变量指针指向新的空间地址；
- 退栈会释放栈空间的占用，GC时发现栈空间占用不到1/4时，则栈空间减小一半。
好比栈的最终大小2M，则极端状况下，就会有10次的扩栈操做，这会带来性能降低。
建议：
- 控制调用栈和函数的复杂度，不要在一个goroutine作完全部逻辑；
- 如查的确须要长调用栈，而考虑goroutine池化，避免频繁建立goroutine带来栈空间的变化。
1.5 避免频繁建立临时对象
Go在GC时会引起stop the world，即整个状况暂停。虽1.7版本已大幅优化GC性能，1.8甚至量坏状况下GC为100us。但暂停时间仍是取决于临时对象的个数，临时对象数量越多，暂停时间可能越长，并消耗CPU。
建议：GC优化方式是尽量地减小临时对象的个数：
- 尽可能使用局部变量
- 所多个局部变量合并一个大的结构体或数组，减小扫描对象的次数，一次回尽量多的内存。
2 并发优化
2.1 高并发的任务处理使用goroutine池
goroutine虽轻量，但对于高并发的轻量任务处理，频繁来建立goroutine来执行，执行效率并不会过高效：
- 过多的goroutine建立，会影响go runtime对goroutine调度，以及GC消耗；
- 高并时若出现调用异常阻塞积压，大量的goroutine短期积压可能致使程序崩溃。
2.2 避免高并发调用同步系统接口
goroutine的实现，是经过同步来模拟异步操做。在以下操做操做不会阻塞go runtime的线程调度：
- 网络IO
- 锁
- channel
- time.sleep
- 基于底层系统异步调用的Syscall
下面阻塞会建立新的调度线程：
- 本地IO调用
- 基于底层系统同步调用的Syscall
- CGo方式调用C语言动态库中的调用IO或其它阻塞
网络IO能够基于epoll的异步机制（或kqueue等异步机制），但对于一些系统函数并无提供异步机制。例如常见的posix api中，对文件的操做就是同步操做。虽有开源的fileepoll来模拟异步文件操做。但Go的Syscall仍是依赖底层的操做系统的API。系统API没有异步，Go也作不了异步化处理。
建议：把涉及到同步调用的goroutine，隔离到可控的goroutine中，而不是直接高并的goroutine调用。
2.3 高并发时避免共享对象互斥
传统多线程编程时，当并发冲突在4~8线程时，性能可能会出现拐点。Go中的推荐是不要经过共享内存来通信，Go建立goroutine很是容易，当大量goroutine共享同一互斥对象时，也会在某一数量的goroutine出在拐点。
建议：goroutine尽可能独立，无冲突地执行；若goroutine间存在冲突，则能够采分区来控制goroutine的并发个数，减小同一互斥对象冲突并发数。
3 其它优化
3.1 避免使用CGO或者减小CGO调用次数
GO能够调用C库函数，但Go带有垃圾收集器且Go的栈动态增涨，但这些没法与C无缝地对接。Go的环境转入C代码执行前，必须为C建立一个新的调用栈，把栈变量赋值给C调用栈，调用结束现拷贝回来。而这个调用开销也很是大，须要维护Go与C的调用上下文，二者调用栈的映射。相比直接的GO调用栈，单纯的调用栈可能有2个甚至3个数量级以上。
建议：尽可能避免使用CGO，没法避免时，要减小跨CGO的调用次数。
3.2 减小[]byte与string之间转换，尽可能采用[]byte来字符串处理
GO里面的string类型是一个不可变类型，不像c++中std:string，能够直接char*取值转化，指向同一地址内容；而GO中[]byte与string底层两个不一样的结构，他们之间的转换存在实实在在的值对象拷贝，因此尽可能减小这种没必要要的转化
建议：存在字符串拼接等处理，尽可能采用[]byte，例如：
func Prefix(b []byte) []byte {
return append([]byte("hello", b...))
}
3.3 字符串的拼接优先考虑bytes.Buffer
因为string类型是一个不可变类型，但拼接会建立新的string。GO中字符串拼接常见有以下几种方式：
- string + 操做 ：致使屡次对象的分配与值拷贝
- fmt.Sprintf ：会动态解析参数，效率好不哪去
- strings.Join ：内部是[]byte的append
- bytes.Buffer ：能够预先分配大小，减小对象分配与拷贝
建议：对于高性能要求，优先考虑bytes.Buffer，预先分配大小。非关键路径，视简洁使用。fmt.Sprintf能够简化不一样类型转换与拼接。