关于go:golang-sync-map源码阅读

背景

在开发的过程中，应用golang syncmap存储连贯信息，其中将本人封装的连贯对象指针作为key，
连贯对象大略是上面的构造

type Con struct {
    con net.Conn
    addr string
    readBuffer []byte
    writeBuffer []byte
    ......
}

在跑benchmark测试的时候，发现了一个问题，就是每次跑完benchmark，无论工夫过来多久，内存始终回不到程序刚启动的水准。然而无论跑多少次benchmark，内存并不会有限升高，而是维持在方才的水准高低。过后感觉这个不是简略的内存透露。go pprof剖析内存发现是readbuffer和writeBuffer那里好多调配的内存没有开释。看到这个后果也是有点懵逼，一个会话完结的时候不仅连贯会断开，con对象也会从map中被删除，为什么还没有被开释呢。因为只有这个map的逻辑是前面加的，过后判断问题大概率出在这里，所以仔细阅读了sync map的源码。

源码

源码在sync包的map.go

type Map struct {
    mu Mutex //操作dirty时用到的锁
    
    read atomic.Value // 只读map，只读的删除是通过更新entry中unsafe point的指向来实现，所以其实这样的删除，key占用的内存空间并没有被开释（这个场景在下文会说到）
    
    dirty map[any]*entry 
    
    misses int
}

type readOnly struct {
    m       map[interface{}]*entry
    amended bool // 如果dirty map比read map中存储的数据要全，则该字段的值为true
}

type entry struct {
    p unsafe.Pointer // *interface{}
}

加载key

func (m *Map) Load(key any) (value any, ok bool) {
    read, _ := m.read.Load().(readOnly)
    e, ok := read.m[key] //先尝试从read map加载数据
    if !ok && read.amended {
    //如果没有找到数据，并且read map和dirty有差别
        m.mu.Lock()
        read, _ = m.read.Load().(readOnly)
        e, ok = read.m[key]
        if !ok && read.amended {
            //这里是进行一个double check
            e, ok = m.dirty[key]
            //减少一下miss的次数，miss次数达到dirty长度就会用dirty笼罩readmap
            m.missLocked()
        }
        m.mu.Unlock()
    }
    if !ok {
        return nil, false
    }
    return e.load()
}

func (m *Map) missLocked() {
    m.misses++
    if m.misses < len(m.dirty) {
        return
    
    //当miss的次数大于等于dirty的长度的时候，就用dirty笼罩readmap
    m.read.Store(readOnly{m: m.dirty})
    m.dirty = nil
    m.misses = 0
}

func (e *entry) load() (value any, ok bool) {
    p := atomic.LoadPointer(&e.p)
    //不为空并且不是擦除状态，这个擦除状态是指的是，当从read map向dirty同步数据的时候，如果这个key对应value的entry指向的是nil（删除状态），就不同步到dirty，而是标记为擦除（expunged）状态
思考 为什么要设置为擦除状态
当发现read map中的一个key是擦除状态的时候，能够阐明dirty非空，并且dirty外面没有这个key。这样在store的时候就能够通过判断擦除状态来保障，dirty外面没有的key，会被sotre到dirty。
    if p == nil || p == expunged {
        return nil, false
    }
    return *(*any)(p), true
}

存储key

func (m *Map) Store(key, value any) {
    read, _ := m.read.Load().(readOnly)
    if e, ok := read.m[key]; ok && e.tryStore(&value) {
        return
    }

    m.mu.Lock()
    read, _ = m.read.Load().(readOnly)
    if e, ok := read.m[key]; ok {
        if e.unexpungeLocked() {
            m.dirty[key] = e
        }
        e.storeLocked(&value)
    } else if e, ok := m.dirty[key]; ok {
        e.storeLocked(&value)
    } else {
        if !read.amended {
            m.dirtyLocked()
            m.read.Store(readOnly{m: read.m, amended: true})
        }
        m.dirty[key] = newEntry(value)
    }
    m.mu.Unlock()
}

func (e *entry) tryStore(i *any) bool {
    for {
        p := atomic.LoadPointer(&e.p)
        if p == expunged {
        //响应在load办法中的思考
            return false
        }
        if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(i)) {
            return true
        }
    }
}

func (m *Map) dirtyLocked() {
    if m.dirty != nil {
        return
    }

    read, _ := m.read.Load().(readOnly)
    m.dirty = make(map[any]*entry, len(read.m))
    for k, e := range read.m {
    //这里就是把readmap外面value的entry外面unsafe point不是nil的同步到dirty，是nil的原地标记为擦除状态
        if !e.tryExpungeLocked() {
            m.dirty[k] = e
        }
    }
}

func (e *entry) tryExpungeLocked() (isExpunged bool) {
    p := atomic.LoadPointer(&e.p)
    for p == nil {
        if atomic.CompareAndSwapPointer(&e.p, nil, expunged) {
            return true
        }
        p = atomic.LoadPointer(&e.p)
    }
    return p == expunged
}

删除key

删除这里后面局部跟load的原理差不多

func (m *Map) LoadAndDelete(key any) (value any, loaded bool) {
    read, _ := m.read.Load().(readOnly)
    e, ok := read.m[key]
    if !ok && read.amended {
        m.mu.Lock()
        read, _ = m.read.Load().(readOnly)
        e, ok = read.m[key]
        if !ok && read.amended {
            e, ok = m.dirty[key]
            delete(m.dirty, key)//先删除后计数miss
            m.missLocked()
        }
        m.mu.Unlock()
    }
    if ok {
        return e.delete()
    }
    return nil, false
}

// Delete deletes the value for a key.
func (m *Map) Delete(key any) {
    m.LoadAndDelete(key)
}

func (e *entry) delete() (value any, ok bool) {
    for {
        p := atomic.LoadPointer(&e.p)
        if p == nil || p == expunged {
            return nil, false
        }
        if atomic.CompareAndSwapPointer(&e.p, p, nil) {
            return *(*any)(p), true
        }
    }
}

试验

如图代码在14行处断点
此时sync map中各个字段的内容如下

此时因为13行的删除其实有一次load操作，此时misses是1，那么实践上14行运行实现，后dirty的长度会变成1，missing会变成2.此时会用dirty笼罩read map，并且置空dirty，如图

剖析是正确

而后如果跑完15行，则会从read map删除”1″,然而不是真正删除，只是unsafe point指针为空
继续执行15行后果如下

能够看出的确是空值

剖析

其实依据试验曾经比拟显著了，当在readmap删除的时候，并不是传统的delete(m,key)的形式，key并不会删除，所以，当咱们的key是一个指针，刚好指向的对象占用的对象空间比拟大的时候。这里我只是拿只有一个key的状况做举例，在做benchmark的时候，这种key会很多，就比方结尾说的，好多conn对象的指针作为key，导致这个对象不能gc，所以就会呈现，明明删除了，然而内存还没上来的状况。

持续试验

持续写入加load触发 dirty笼罩readmap的操作

17行执行完，发现readmap中的 key”1″变成如图，其实就是在把readmap同步到dirty过程中，把key”1″的value设置成擦除状态
继续执行18行

能够看到readmap曾经被笼罩，如果后面是很多个key的话，此时就会发现有大量的内存空间被开释