1.浅谈Golang两种线程安全的源码阅读map
2.golang本地缓存(bigcache/freecache/fastcache等)选型对比及原理总结
浅谈Golang两种线程安全的map
文章标题：浅谈Golang两种线程安全的map
导语：本文将深入探讨Golang中的本地缓存库选择与对比，帮助您解决困惑。源码阅读
Golang map并发读写测试：
在Golang中，源码阅读原生的源码阅读map在并发场景下的读写操作是线程不安全的，无论key是源码阅读否相同。具体来说，源码阅读pyhook源码当并发读写map的源码阅读不同key时，运行结果会出现并发错误，源码阅读因为map在读取时会检查hashWriting标志。源码阅读如果存在该标志，源码阅读即表示正在写入，源码阅读此时会报错。源码阅读在写入时，源码阅读会设置该标志：h.flags |= hashWriting。源码阅读设置完成后，源码阅读系统会取消该标记。
使用-race编译选项可以检测并发问题，这是通过Golang的源码分析、文章解析和官方博客中详细解释的。
map+读写锁实现：
在官方sync.map库推出之前，推荐使用map与读写锁（RWLock）的组合。通过定义一个匿名结构体变量，包含map、RWLock，可以实现读写操作。
具体操作方法如下：从counter中读取数据，往counter中写入数据。然而，邮箱源码教程下载视频sync.map和这种实现方式有何不同？它在性能优化方面做了哪些改进？
sync.map实现：
sync.map使用读写分离策略，通过空间换取时间，优化了并发性能。相较于map+RWLock的实现，它在某些特定场景中减少锁竞争的可能性，因为可以无锁访问read map，并优先操作read map。如果仅操作read map即可满足需求（如增删改查和遍历），则无需操作write map，后者在读写时需要加锁。
sync.map的源码深入分析：
接下来，我们将着重探讨sync.Map的源码，以理解其运作原理，包括结构体Map、readOnly、entry等。
sync.Map方法介绍：
sync.Map提供了四个关键方法：Store、Load、Delete、Range。具体功能如下：
Load方法：解释Map.dirty如何提升为Map.read的机制。
Store方法：介绍tryStore函数、unexpungeLocked函数和dirtyLocked函数的实现。
Delete方法：简单总结。
Range方法：简单总结。
sync.Map总结：
sync.Map更适用于读取频率远高于更新频率的场景（appendOnly模式，尤其是抢单搬砖源码key存一次，多次读取且不删除的情况），因为在key存在的情况下，读写删操作可以无锁直接访问readOnly。不建议用于频繁插入与读取新值的场景，因为这会导致dirty频繁操作，需要频繁加锁和更新read。此时，github开源库orcaman/concurrent-map可能更为合适。
设计点：expunged：
expunged是entry.p值的三种状态之一。当使用Store方法插入新key时，会加锁访问dirty，并将readOnly中未被标记为删除的所有entry指针复制到dirty。此时，之前被Delete方法标记为软删除的entry（entry.p被置为nil）都会变为expunged状态。
sync.map其他问题：
sync.map为何不实现len方法？这可能涉及成本与收益的权衡。
orcaman/concurrent-map的适用场景与实现：
orcaman/concurrent-map适用于反复插入与读取新值的场景。其实现思路是对Golang原生map进行分片加锁，降低锁粒度，从而达到最少的锁等待时间（锁冲突）。
它实现简单，部分源码如下，包括数据结构和函数介绍。
后续：
在其他业务场景中，可能需要本地kv缓存组件库，支持键过期时间设置、淘汰策略、存储优化、织梦宝宝起名源码GC优化等功能。此时，可能需要了解freecache、gocache、fastcache、bigcache、groupcache等组件库。
参考链接：
链接1：/questions//golang-fatal-error-concurrent-map-read-and-map-write/
链接2：/golang/go/issues/
链接3：/golang/go/blob/master/src/sync/map.go
链接4：/orcaman/concurrent-map
golang本地缓存(bigcache/freecache/fastcache等)选型对比及原理总结
以下内容来自腾讯后台研发工程师jayden
导语：提到本地缓存大家都不陌生，只要是个有点经验的后台开发人员，都知道缓存的作用和弊端。本篇文章我们就来简单聊聊在golang做业务开发的过程中，本地缓存的一些可选的开源方案，分析它们的特点，以及内部的实现原理。
1.本地缓存需求分析
首先来梳理一下业务开发过程中经常面临的本地缓存的一些需求。我们一般做缓存就是为了能提高系统的读写性能，缓存的命中率越高，也就意味着缓存的效果越好。其次本地缓存一般都受限于本地内存的大小，所有全量的数据一般存不下。那基于这样的场景一方面是想缓存的数据越多，则命中率理论上也会随着缓存数据的增多而提高；另外一方面是想，既然所有的数据存不下那就想办法利用有限的内存存储有限的数据。这些有限的数据需要是经常访问的，同时有一定时效性(不会频繁改变)的。基于这两个点展开，我们一般对本地缓存会要求其满足支持过期时间、任务发布网站源码大全支持淘汰策略。最后再使用自动管理内存的语言例如golang等开发时，还需要考虑在加入本地缓存后引发的GC问题。
分析完我们日常本地缓存的诉求，再结合我们日常开发用到的golang语言，我们可以提炼得到golang本地缓存组件必须具备以下几个能力：
分析清楚了我们的需求，也明确了我们需要的能力。那自然优先考虑golang内置的标准库中是否存在这样的组件可以直接使用呢？很遗憾，没有。golang中内置的可以直接用来做本地缓存的无非就是map和sync.Map。而这两者中，map是非并发安全的数据结构，在使用时需要加锁；而sync.Map虽然是线程安全的。但是需要在并发读写时加锁。此外二者均无法支持数据的过期和淘汰，同时在存储大量数据时，又会产生比较频繁的GC问题，更严重的情况下导致线上服务无法稳定运行。
既然标准库中没有我们满足上述需求的本地缓存组件，那我们就想只有两种解决方案了
那首先面临的第一个问题就是方案的调研和选型，没有合适的方案时自己再来动手构建。下面我们就来给大家介绍下golang中哪些可以直接来使用的本地缓存组件吧。
2.golang本地缓存组件概览
golang中本地缓存方案可选的有如下一些：
下面通过笔者一段时间的调研和研究，将golang可选的开源本地缓存组件汇总为下表，方便大家在方案选型时作参考。
在上述方案中，freecache、bigcache、fastcache、ristretto、groupcache这几个大家根据实际的业务场景首选，offheap有定制需求时可考虑。
通过上表的总结，个人想再此再谈几点关于本地缓存组件的理解：
（1）上述本地缓存组件中，实现零GC的方案主要就两种：
a.无GC：分配堆外内存(Mmap)
b.避免GC：map非指针优化(map[uint]uint)或者采用slice实现一套无指针的map
c.避免GC：数据存入[]byte slice(可考虑底层采用环形队列封装循环使用空间)
（2）实现高性能的关键在于：
a.数据分片(降低锁的粒度)
3. 主流缓存组件实现原理剖析
在本节中我们会重点分析下freecache、bigcache、fastcache、offheap这几个组件内部的实现原理。
3.1 freecache实现原理
首先分析下freecache的内部实现原理。在freecache中它通过segment来进行对数据分片，freecache内部包含个segment，每个segment维护一把互斥锁，每一条kv数据进来后首先会根据k进行计算其hash值，然后根据hash值决定当前的这条数据落入到哪个segment中。
对于每个segment而言，它由索引、数据两部分构成。
索引：其中索引最简单的方式采用map来维护，例如map[uint]uint这种。而freecache并没有采用这种做法，而是通过采用slice来底层实现一套无指针的map，以此避免GC扫描。
数据：数据采用环形缓冲区来循环使用，底层采用[]byte进行封装实现。数据写入环形缓冲区后，记录写入的位置index作为索引，读取时首先读取数据header信息，然后再读取kv数据。
在freecache中数据的传递过程是：freecache->segment->(slot,ringbuffer) 下图是freecache的内部实现框架图。
总结： freecache通过利用数据分片减小锁的粒度，然后再存储时索引并没有采用内置的map来维护而是采用自建map减少指针来避免GC，同时数据存储时采用预先分配内存然后后边循环使用。通过上述两种方法保证了在堆上分配内存同时减少GC对系统性能的影响。
3.2 bigcache实现原理
bigcache和freecache类似，也是一个零GC、高性能的cache组件，但是它的实现和freecache还是有些差异，这儿有篇 英文博客介绍bigcache设计原理的，内容稍长感兴趣的可以阅读下，下面我们介绍一下bigcache的实现原理。
bigcache同样是采用分片的方式构成，一个bigcache对象包含2^n 个cacheShard对象，默认是个。每个cacheShard对象维护着一把sync.RWLock锁(读写锁)。所有的数据会分散到不同的cacheShard中。
每个cacheShard同样由索引和数据构成。索引采用map[uint]uint来存储，数据采用entry([]byte)环形队列存储。索引中存储的是该条数据在entryBuffer写入的位置pos。每条kv数据按照TLV的格式写入队列。
不过值得注意的是，和bigcache和freecache不同的一点在于它的环形队列可以自动扩容。同时bigcache中数据的过期是通过全局的时间窗口维护的，每个单独的kv无法设置不同的过期时间。
下面是bigcache的内容实现原理框架图。
总结：bigcache思路和freecache大体相同，只不过在索引存储时更为巧妙，直接采用内置的map结构加上基础数据类型来实现。同时底层存储数据的队列也可以根据空间大小来决定是否扩容。唯一的缺陷是无法针对每个key进行设置不同的过期时间。这个个人认为如果想用bigcache同时想要这个特性，可以进行二次开发一下。
通过 性能测试数据来看，bigcache性能要比freecache稍微好一点。大家可以思考下他们性能的差异可能会在哪里呢？
3.3 fastcache实现原理
本节介绍下fastcache的实现原理，根据fastcache官方文档介绍，它的灵感来自于bigcache。所以整体的思路和bigcache很类似，数据通过bucket进行分片。fastcache由个bucket构成。每个bucket维护一把读写锁。在bucket内部数据同理是索引、数据两部分构成。索引用map[uint]uint存储。数据采用chunks二维的切片(二维数组)存储。不过值得注意的是fastcache有一个很大的特性是，它的内存分配是在堆外分配的，而不是在堆上分配的。堆外分配的内存。这样做也就避免了golang GC的影响。下图是fastcache内部实现框架图。
总结： fastcache一方面充分利用了分片来降低锁的粒度，另一方面在索引存储时采用了对map的优化，同时在分配内存时，直接从堆外申请内存，自己实现了分配和释放内存的逻辑。通过上述手段使得GC的影响降到了最低。fastcache唯一的缺陷是官方提供的版本没有提供针对kv数据的过期时间这个特性。所以如果需要这个特性的话，需要自己动手二次开发。整体从性能上来看是比bigcache和freecache都更优。
3.4 offheap实现原理
本节介绍下offheap的相关内容，offheap其实功能就比较简单了，就是一个基于堆外内存构建的哈希表。它通过直接调用系统调用函数来分配内存。然后在内部通过数组来实现哈希表。实现过程中当发生哈希冲突时，它是采用探测法来解决。由于是在堆外分配的内存上构建的哈希表。导致它的GC开销非常的小。下图是offheap的内部实现框架图。
总结：offheap内部由于是采用探测法解决哈希冲突的，所以当哈希冲突严重时数据删除、查询都会带来非常复杂的处理流程。而且性能也会有一些损耗。可以作为学习和研究的项目还是非常不错的。
4.总结
本文主要从日常需求出发，分析了日常业务过程中对本地缓存的需求，再调研了业界可选的一些组件并进行了对比，希望对本地缓存选型上起到一些参考和帮助。最后再对其中比较重要的几个组件如freecache、bigcache、fastcache、offheap等做了内部实现的简单介绍。上述内容只是从架构层面展开介绍，后续有时间再从源码层面做一些分析。由于篇幅限制本篇内容并未对map、sync.Map、go-cache、groupcache进行介绍。感兴趣的读者可以自行搜索资料进行阅读。如果大致理解了上述原理的童鞋也可以自己动手实践起来，造个轮子看看。
5.参考资料
欢迎点赞分享，关注 @鹅厂架构师，一起探索更多业界领先产品技术。
