背景：
我们有一个用go做的项目，其中用到了zmq4进行通信，一个简单的rpc过程，早期远端是使用一个map去做ip和具体socket的映射。
问题
大概是这样
struct SocketMap {
sync.Mutex
sockets map[string]*zmq4.Socket
}
然后调用的时候的代码大概就是这样的：
func (pushList *SocketMap) push(ip string, data []byte) {
pushList.Lock()
defer pushList.UnLock()
socket := pushList.sockets[string]
if socket == nil {
socket := zmq4.NewSocket()
//do some initial operation like connect
pushList.sockets[ip] = socket
}
socket.Send(data)
}
相信大家都能看出问题：当push被并发访问的时候（事实上push会经常被并发访问），由于这把大锁的存在，同时只能有一个协程在临界区工作，效率是会被大大降低的。
解决方案：会带来crash的优化
所以我们决定使用sync.Map来替代这个设计，然后出了第一版代码，写的非常简单，只做了简单的替换：
struct SocketMap {
sockets sync.Map
}
func (pushList *SocketMap) push(ip string, data []byte) {
var socket *zmq4.Socket
socketInter, ok = pushList.sockets.Load(ip)
if !ok {
socket = zmq4.NewSocket()
//do some initial operation like connect
pushList.sockets.Store(ip, socket)
} else {
socket = socketInter.(*zmq4.Socket)
}
socket.Send(data)
}
乍一看似乎没什么问题？但是跑起来总是爆炸，然后一看log，提示有个非法地址。后来在github上才看到，zmq4.Socket不是线程安全的。上面的代码恰恰会造成多个线程同时拿到socket实例，然后就crash了。
解决方案2： 加一把锁也挡不住的冲突
然后怎么办呢？看来也只能加锁了，不过这次加锁不能加到整个map上，否则还会有性能问题，那就考虑减小锁的粒度吧，使用锁包装socket。这个时候我们的代码也就呼之欲出了：
struct SocketMutex{
sync.Mutex
socket *zmq4.Socket
}
struct SocketMap {
sockets sync.Map
}
func (pushList *SocketMap) push(ip string, data []byte) {
var socket *SocketMutex
socketInter, ok = pushList.sockets.Load(ip)
if !ok {
socket = &{
socket: zmq4.NewSocket()
}
//do some initial operation like connect
pushList.sockets.Store(ip, newSocket)
} else {
socket = socketInter.(*SocketMutex)
}
socket.Lock()
defer socket.Unlock()
socket.socket.Send(data)
}
但是这样还是有问题，相信经验比较丰富的老哥一眼就能看出来，问题处在socketInter, ok = pushList.sockets.Load(ip)这行代码上，如果map中没有这个值，且有多个协程同时访问到这行代码，显然这几个协程的ok都会置为false，然后都进入第一个if代码块，创建多个socket实例，并且争相覆盖原有值。
单纯解决这个问题也很简单，就是使用sync.Map.LoadOrStore(key interface{}, value interface{}) (v interface{}, loaded bool)这个api，来原子地去做读写。
然而这还没完，我们的写入新值的操作不光是调用一个api创建socket就完了，还要有一系列的初始化操作，我们必须保证在初始化完成之前，其他通过Load拿到这个实例的协程无法真正访问socket实例。
这时候显然sync.Map自带的机制已经无法解决这个问题了，那么我们必须寻求其他的手段，要么锁，要么就sync.WaitGroup或者whatever的其他什么东西。
解决方案3： 闭包带来的神奇体验
后来经大佬指点，我在encoder.go中看到了这么一段代码：
func typeEncoder(t reflect.Type) encoderFunc {
if fi, ok := encoderCache.Load(t); ok {
return fi.(encoderFunc)
}
// To deal with recursive types, populate the map with an
// indirect func before we build it. This type waits on the
// real func (f) to be ready and then calls it. This indirect
// func is only used for recursive types.
var (
wg sync.WaitGroup
f encoderFunc
)
wg.Add(1)
fi, loaded := encoderCache.LoadOrStore(t, encoderFunc(func(e *encodeState, v reflect.Value, opts encOpts) {
wg.Wait()
f(e, v, opts)
}))
if loaded {
return fi.(encoderFunc)
}
// Compute the real encoder and replace the indirect func with it.
f = newTypeEncoder(t, true)
wg.Done()
encoderCache.Store(t, f)
return f
}
豁然开朗，我们可以在sync.Map中存放一个闭包函数，然后在闭包函数中等待本地的sync.WaitGroup完成再返回实例。于是最终的代码也就成型了。
struct SocketMutex{
sync.Mutex
socket *zmq4.Socket
}
struct SocketMap {
sockets sync.Map
}
func (pushList *SocketMap) push(ip string, data []byte) {
type SocketFunc func()*SocketMutex
var (
socket *SocketMutex
w sync.WaitGroup
)
socket = &SocketMutex {
socket : zmq4.NewSocket()
}
w.Add(1)
socketf, ok = pushList.sockets.LoadOrStore(ip, SocketFunc(func()*SocketMutex) {
w.Wait()
return socket
})
if !ok {
socket = &{
socket: zmq4.NewSocket()
}
//do some initial operation like connect
w.Done()
} else {
socket = socketInter.(*SockeFunc)()
}
socket.Lock()
defer socket.Unlock()
socket.socket.Send(data)
}
总结：
并发代码中的竞争问题，每一行代码的重入性都要深思熟虑啊。
总的来说要保持以下几个准则：
（1） 不可重入访问的系统资源，如socketfd, filefd，signalfd（事实上大多数这种系统资源都是不可重入的）等，在使用无锁结构的容器、读写锁封装的容器时，需要给每个资源单独加锁或者使用其他手段保证系统资源在临界区受到有效保护。
（2）如果有读取，如果为空则写入的逻辑，需要使用能提供原子性保证的LoadOrSave调用，或者没有的话，自己实现也要保证读取和写入过程整体的原子性；防止并发访问Load调用时，多个线程都返回否而创建多个实例，然后在Save的时候又互相覆盖。——这个原则不光对成员是系统资源的时候生效，如果存放的是其他东西也同样适用。
（3）如果资源创建完毕，还需要其他的初始化过程，则可以考虑在容器内放置闭包，初始化过程使用sync.WaitGroup保护，在闭包中调用Wait方法等待初始化完成再给其他线程返回初始化好的实例。而初始化过程完成后，可以置换闭包函数，不再调用Wait方法，来减少可能的开销。
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！ 如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。