几个Go系统可能遇到的锁问题

时间  2019-12-07
标签 几个 系统 可能 遇到 问题 繁體版
原文   原文链接

以前统一特征系统在 QA 同窗的帮助下进行了一些压测，发现了一些问题，这些问题是较为通用的问题，发出来给其余同窗参考一下，避免踩一样的坑。git

几个Go系统可能遇到的锁问题

底层依赖 sync.Pool 的场景github

有一些开源库，为了优化性能，使用了官方提供的 sync.Pool，好比咱们使用的 https://github.com/valyala/fasttemplate 这个库，每当你执行下面这样的代码的时候：网络

  1. template := "http://{{host}}/?q={{query}}&foo={{bar}}{{bar}}" 
  2.     t := fasttemplate.New(template, "{{", "}}") 
  3.     s := t.ExecuteString(map[string]interface{}{ 
  4.         "host":  "google.com", 
  5.         "query": url.QueryEscape("hello=world"), 
  6.         "bar":   "foobar", 
  7.     }) 
  8.     fmt.Printf("%s", s) 

内部都会生成一个 fasttemplate.Template 对象，并带有一个 byteBufferPool 字段：架构

  1. type Template struct { 
  2.     template string 
  3.     startTag string 
  4.     endTag   string 
  5.  
  6.     texts          [][]byte 
  7.     tags           []string 
  8.     byteBufferPool bytebufferpool.Pool   ==== 就是这个字段 
  9. } 

byteBufferPool 底层就是通过封装的 sync.Pool：并发

  1. type Pool struct { 
  2.     calls       [steps]uint64 
  3.     calibrating uint64 
  4.  
  5.     defaultSize uint64 
  6.     maxSize     uint64 
  7.  
  8.     pool sync.Pool 
  9. } 

这种设计会带来一个问题，若是使用方每次请求都 New 一个 Template 对象。并进行求值，好比咱们最初的用法，在每次拿到了用户的请求以后，都会用参数填入到模板：app

  1. func fromTplToStr(tpl string, params map[string]interface{}) string { 
  2.   tplVar := fasttemplate.New(tpl, `{{`, `}}`) 
  3.   res := tplVar.ExecuteString(params) 
  4.   return res 
  5. } 

在模板求值的时候：高并发

  1. func (t *Template) ExecuteFuncString(f TagFunc) string { 
  2.     bb := t.byteBufferPool.Get() 
  3.     if _, err := t.ExecuteFunc(bb, f); err != nil { 
  4.         panic(fmt.Sprintf("unexpected error: %s", err)) 
  5.     } 
  6.     s := string(bb.Bytes()) 
  7.     bb.Reset() 
  8.     t.byteBufferPool.Put(bb) 
  9.     return s 
  10. } 

会对该 Template 对象的 byteBufferPool 进行 Get，在使用完以后，把 ByteBuffer Reset 再放回到对象池中。但问题在于，咱们的 Template 对象自己并无进行复用，因此这里的 byteBufferPool 自己的做用其实并无发挥出来。oop

相反的，由于每个请求都须要新生成一个 sync.Pool，在高并发场景下，执行时会卡在 bb := t.byteBufferPool.Get() 这一句上，经过压测能够比较快地发现问题，达到必定 QPS 压力时，会有大量的 Goroutine 堆积，好比下面有 18910 个 G 堆积在抢锁代码上：性能

  1. goroutine profile: total 18910 
  2. 18903 @ 0x102f20b 0x102f2b3 0x103fa4c 0x103f77d 0x10714df 0x1071d8f 0x1071d26 0x1071a5f 0x12feeb8 0x13005f0 0x13007c3 0x130107b 0x105c931 
  3. #   0x103f77c   sync.runtime_SemacquireMutex+0x3c                               /usr/local/go/src/runtime/sema.go:71 
  4. #   0x10714de   sync.(*Mutex).Lock+0xfe                                     /usr/local/go/src/sync/mutex.go:134 
  5. #   0x1071d8e   sync.(*Pool).pinSlow+0x3e                                   /usr/local/go/src/sync/pool.go:198 
  6. #   0x1071d25   sync.(*Pool).pin+0x55                                       /usr/local/go/src/sync/pool.go:191 
  7. #   0x1071a5e   sync.(*Pool).Get+0x2e                                       /usr/local/go/src/sync/pool.go:128 
  8. #   0x12feeb7   github.com/valyala/fasttemplate/vendor/github.com/valyala/bytebufferpool.(*Pool).Get+0x37   /Users/xargin/go/src/github.com/valyala/fasttemplate/vendor/github.com/valyala/bytebufferpool/pool.go:49 
  9. #   0x13005ef   github.com/valyala/fasttemplate.(*Template).ExecuteFuncString+0x3f              /Users/xargin/go/src/github.com/valyala/fasttemplate/template.go:278 
  10. #   0x13007c2   github.com/valyala/fasttemplate.(*Template).ExecuteString+0x52                  /Users/xargin/go/src/github.com/valyala/fasttemplate/template.go:299 
  11. #   0x130107a   main.loop.func1+0x3a                                        /Users/xargin/test/go/http/httptest.go:22 

有大量的 Goroutine 会阻塞在获取锁上，为何呢?继续看看 sync.Pool 的 Get 流程：学习

  1. func (p *Pool) Get() interface{} { 
  2.     if race.Enabled { 
  3.         race.Disable() 
  4.     } 
  5.     l := p.pin() 
  6.     x := l.private 
  7.     l.private = nil 
  8.     runtime_procUnpin() 

而后是 pin：

  1. func (p *Pool) pin() *poolLocal { 
  2.     pid := runtime_procPin() 
  3.      
  4.     s := atomic.LoadUintptr(&p.localSize) // load-acquire 
  5.     l := p.local                          // load-consume 
  6.     if uintptr(pid) < s { 
  7.         return indexLocal(l, pid) 
  8.     } 
  9.     return p.pinSlow() 
  10. } 

由于每个对象的 sync.Pool 都是空的，因此 pin 的流程必定会走到 p.pinSlow：

  1. func (p *Pool) pinSlow() *poolLocal { 
  2.     runtime_procUnpin() 
  3.     allPoolsMu.Lock() 
  4.     defer allPoolsMu.Unlock() 
  5.     pid := runtime_procPin() 

而 pinSlow 中会用 allPoolsMu 来加锁，这个 allPoolsMu 主要是为了保护 allPools 变量：

  1. var ( 
  2.     allPoolsMu Mutex 
  3.     allPools   []*Pool 
  4. ) 

在加了锁的状况下，会把用户新生成的 sync.Pool 对象 append 到 allPools 中：

  1. if p.local == nil { 
  2.         allPools = append(allPools, p) 
  3.     } 

标准库的 sync.Pool 之因此要维护这么一个 allPools 意图也比较容易推测，主要是为了 GC 的时候对 pool 进行清理，这也就是为何说使用 sync.Pool 作对象池时，其中的对象活不过一个 GC 周期的缘由。sync.Pool 自己也是为了解决大量生成临时对象对 GC 形成的压力问题。

说完了流程，问题也就比较明显了，每个用户请求最终都须要去抢一把全局锁，高并发场景下全局锁是大忌。可是这个全局锁是由于开源库间接带来的全局锁问题，经过看本身的代码并非那么容易发现。

知道了问题，改进方案其实也还好实现，第一是能够修改开源库，将 template 的 sync.Pool 做为全局对象来引用，这样大部分 pool.Get 不会走到 pinSlow 流程。第二是对 fasttemplate.Template 对象进行复用，道理也是同样的，就不会有那么多的 sync.Pool 对象生成了。但前面也提到了，这个是个间接问题，若是开发工做繁忙，不太可能全部的依赖库把代码全看完以后再使用，这种状况下怎么避免线上的故障呢?

压测尽可能早作呗。

metrics 上报和 log 锁

这两个本质都是同样的问题，就放在一块儿了。

公司以前 metrics 上报 client 都是基于 udp 的，大多数作的简单粗暴，就是一个 client，用户传什么就写什么，最终必定会走到：

  1. func (c *UDPConn) WriteToUDP(b []byte, addr *UDPAddr) (int, error) { 
  2.     ---------- 刨去无用细节 
  3.     n, err := c.writeTo(b, addr) 
  4.     ---------- 刨去无用细节 
  5.     return n, err 
  6. } 

或者是：

  1. func (c *UDPConn) WriteTo(b []byte, addr Addr) (int, error) { 
  2.  
  3.     ---------- 刨去无用细节 
  4.     n, err := c.writeTo(b, a) 
  5.     ---------- 刨去无用细节 
  6.     return n, err 
  7. } 

调用的是：

  1. func (c *UDPConn) writeTo(b []byte, addr *UDPAddr) (int, error) { 
  2.     ---------- 刨去无用细节 
  3.     return c.fd.writeTo(b, sa) 
  4. } 

而后：

  1. func (fd *netFD) writeTo(p []byte, sa syscall.Sockaddr) (n int, err error) { 
  2.     n, err = fd.pfd.WriteTo(p, sa) 
  3.     runtime.KeepAlive(fd) 
  4.     return n, wrapSyscallError("sendto", err) 
  5. } 

而后是：

  1. func (fd *FD) WriteTo(p []byte, sa syscall.Sockaddr) (int, error) { 
  2.     if err := fd.writeLock(); err != nil {  =========> 重点在这里 
  3.         return 0, err 
  4.     } 
  5.     defer fd.writeUnlock() 
  6.  
  7.     for { 
  8.         err := syscall.Sendto(fd.Sysfd, p, 0, sa) 
  9.         if err == syscall.EAGAIN && fd.pd.pollable() { 
  10.             if err = fd.pd.waitWrite(fd.isFile); err == nil { 
  11.                 continue 
  12.             } 
  13.         } 
  14.         if err != nil { 
  15.             return 0, err 
  16.         } 
  17.         return len(p), nil 
  18.     } 
  19. } 

本质上，就是在高成本的网络操做上套了一把大的写锁，一样在高并发场景下会致使大量的锁冲突，进而致使大量的 Goroutine 堆积和接口延迟。

一样的，知道了问题，解决办法也很简单。再看看日志相关的。由于公司目前大部分日志都是直接向文件系统写，本质上同一个时刻操做的是同一个文件，最终都会走到：

  1. func (f *File) Write(b []byte) (n int, err error) { 
  2.     n, e := f.write(b) 
  3.     return n, err 
  4. } 
  5.  
  6. func (f *File) write(b []byte) (n int, err error) { 
  7.     n, err = f.pfd.Write(b) 
  8.     runtime.KeepAlive(f) 
  9.     return n, err 
  10. } 

而后：

  1. func (fd *FD) Write(p []byte) (int, error) { 
  2.     if err := fd.writeLock(); err != nil { =========> 又是 writeLock 
  3.         return 0, err 
  4.     } 
  5.     defer fd.writeUnlock() 
  6.     if err := fd.pd.prepareWrite(fd.isFile); err != nil { 
  7.         return 0, err 
  8.     } 
  9.     var nn int 
  10.     for { 
  11.         ----- 略去不相关内容 
  12.         n, err := syscall.Write(fd.Sysfd, p[nn:max]) 
  13.         ----- 略去无用内容 
  14.     } 
  15. } 

和 UDP 网络 FD 同样有 writeLock，在系统打日志打得不少的状况下，这个 writeLock 会致使和 metrics 上报同样的问题。

总结

上面说的几个问题实际上本质都是并发场景下的 lock contention 问题，全局写锁是高并发场景下的性能杀手，一旦大量的 Goroutine 阻塞在写锁上，会致使系统的延迟飚升，直至接口超时。在开发系统时，涉及到 sync.Pool、单个 FD 的信息上报、以及写日志的场景时，应该多加注意。早作压测保平安。

感兴趣的能够本身来个人Java架构群，能够获取免费的学习资料，群号：855801563 对Java技术，架构技术感兴趣的同窗，欢迎加群，一块儿学习，相互讨论。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程