一、疑惑开篇 有了map为什么还要搞个sync.map 呢？它们之间有什么区别？ 答：重要的一点是，map并发不是安全的。 在Go 1.6之前， 内置的map类型是部分goroutine安全的，并发的读没有问题，并发的写可能有问题。自go 1.6之后， 并发地读写map会报错，这在一些知名的开源库中都存在这个问题，所以go 1.9之前的解决方案是额外绑定一个锁

目录sync.Map sync.Map是Golang标准库提供的并发安全的Map类型，可以在多个goroutine并发读写Map的场景下不需要加锁。sync.Map最典型的两个使用场景： 写少读多的场景，特别是只写一次，读取多次的场景，例如缓存；当多个程序读取、写入和修改的场景。 sync.Map 提供如下几个方法： Store(key , value any)

gf框架提供了几个非常实用的并发安全容器，其中gmap就是项目开发中最常用的一个。 gmap具体的方法请参考godoc：https://godoc.org/github.com/... gmap内部有多个类型结构体定义，包括：IntBoolMap、IntIntMap、IntInterfaceMap、IntStringMap、InterfaceInterfaceMap、StringBoolMap

近年来，Golang语言在互联网开发领域愈发流行。它以其高效、简洁、安全、并发和跨平台等特性，越来越多地被应用于互联网开发中。其中，数据融合算法与缓存技术的结合应用在Golang中更是广泛被使用。本文将从Golang语言高效数据融合算法、缓存技术及两者结合的应用原理三个方面进行介绍。一、Golang语言高效数据融合算法Golang语言内置的数据结构有数组、slice、map等。其中

sync.Map 结构体 type Map struct { mu Mutex read atomic.Value // readOnly dirty map[interface{}]*entry misses int } sync.Map设计思想（读多写少） readdirty 与map+RWMutex的实现并发的方式相比，减少了加锁对性能的影响。 它做了一些优化：可以无锁访问read map

Garbage in, garbage out是什么sync.mapsync.mapsync.map有什么用一般情况下解决并发读写 map 的思路是加一把大锁，或者把一个 map 分成若干个小 map，对 key 进行哈希，只操作相应的小 map。前者锁的粒度比较大，影响效率；后者实现起来比较复杂，容易出错。sync.map如何使用使用非常简单，和普通 map 相比，仅遍历的方式略有区别

在 Golang 中，map 是一个很重要的数据类型，日常中经常会用到。但是由于协程用得太爽，会暴露出一个严重的问题：map是不能并发写的。 这个就有点尴尬了，毕竟并发写是一个非常常见的场景。所以，各路大神齐显神通除了很多 concurrent map 的库。后来 golang 在 1.9 的时候终于出了官方库，就是 sync.map。 但是一直到现在官方库的性能被吐槽得很厉害

一、前言 上一期中，我们介绍了 Go 语言对条件变量的实现 sync.Cond。本期文章我们介绍 package sync 下的另一个工具类：sync.Map。我们先看一个故事： 面试官：看你用过 Go，大概用过多久，感觉到哪个段位？ 小明：用了一年半左右，算是精通 面试官：用过 sync.Map 吗？ 小明：没用过，大致了解过 面试官：Go 内置的 map 和 sync.Map 有什么区别？

sync.map的总结 我先把结论贴在前面，让人有一种大概的认知 sync.map的实现原理 dirtyLocked 一起深入 如果要详细聊这个问题，那就要说一说golang中map的问题以及为什么会出现sync.map。 map map的问题 在go里面，map 是不支持并发写操作的，我们看下面一个例子 其实slice也不是并发安全的，但 Go 的运行时只对 map

golang 中 map 性能优化[低阶] 简单介绍 golang 中的 build-in 的 map 这个 map 是非线程安全的，但是也是最常用的一个家伙。 为了测试多个 map 的性能我写了个接口 Map type Map interface { Set(key interface{}, val interface{}) Get(key interface{})