Golang并发不安全,go高并发解决方案

本文目录一览：

1、为什么用golang作为游戏服务端的开发语言，它的并发性如何
2、golang语言map的并发和排序
3、【golang】高并发下TCP常见问题解决方案
4、如何模拟千万并发 golang
5、Golang 并发读写map安全问题详解
6、Go sync/atomic包Load和Store并发不安全

为什么用golang作为游戏服务端的开发语言，它的并发性如何

你想想，如果你对怎么用C语言写高并发程序一无所知，你上golang就可以自动写出高并发程序了？其实很多时候幻觉就发生在这里。

我当初用delphi的时候还是个傻逼，现在用C++已经牛逼了，有时候我就总是会觉得C++写出来的程序就是比delphi的bug少，虽然这显然不成立。

golang语言map的并发和排序

golang缺省的map不是thread safe的，如果存在读写并发的使用场景，必须在外面使用lock机制。

包sync里面引入一个安全map；

用法：

运行结果如下：

golang官方说法map并不排序，不按key排序，也不按插入顺序排序，也就是说map是无序的，无法保证任何排序。

下面是一种常见的给map排序输出的办法：

【golang】高并发下TCP常见问题解决方案

首先，看一下TCP握手简单描绘过程：

其握手过程原理，就不必说了，有很多详细文章进行叙述，本文只关注研究重点。

在第三次握手过程中，如果服务器收到ACK，就会与客户端建立连接，此时内核会把连接从半连接队列移除，然后创建新的连接，并将其添加到全连接队列，等待进程调用。

如果服务器繁忙，来不及调用连接导致全连接队列溢出，服务器就会放弃当前握手连接，发送RST给客户端，即connection reset by peer。

在linux平台上，客户端在进行高并发TCP连接处理时，最高并发数量都要受系统对用户单一进程同时打开文件数量的限制（这是因为系统每个TCP都是SOCKET句柄，每个soker句柄都是一个文件），当打开连接超过限制，就会出现too many open files。

使用下指令查看最大句柄数量：

增加句柄解决方案

如何模拟千万并发 golang

学习了go的基本的并发变成模式，思路就是一个用通信来共享数据，而并不是像java一样共享内存来通讯。go采用了用channel来传递消息，每一个协程持有一个信道，当信道可用时便可以读写数据，各信道间的处理数据互不影响。回想一下java中的并发编程，通常我们是因为操作一个数据而采用多线程并发访问，比较明显的是更新cache中的key对应的value.

让我更是欢喜的时在golang中提供了sync.Once这个神器，从此做系统级的开关不再苦恼，天然的保证了就算多个协程并发的情况下也只有一个协程执行once.Do(func()),其他的协程阻塞。你再想想java里面完成一个系统级初始化，做到并发安全且一次，你要搞一个boolean、再搞把锁，再写逻辑，神啊想想头都大了。

Golang 并发读写map安全问题详解

下面先写一段测试程序，然后看下运行结果：

运行结果：

发生了错误，提示：fatal error: concurrent map read and map write， map 发生了同时读和写了；但是这个错误并不是每次运行都会出现，就是有的时候会出现，有的时候并不会出现，根据笔者多次运行结果(其他例子，读者可以自己尝试下)来看还会有另外一种报错就是：fatal error: concurrent map writes，就是map发生了同时写，但是只是读是不会有问题的。关于不同的运行结果小伙伴们可以自己写几个例子去测试下。下面就这两个错误的发生，笔者给出如下解释：

（1） fatal error: concurrent map read and map write

就是当一个goroutine在写数据，而同时另外一个goroutine要读数据就会报错，不过这个报错也很好理解：还没写完就读，读的数据会有问题，或者反过来还没读完就开始写了，同样会导致读取的数据有问题；

（2） fatal error: concurrent map writes

两个goroutine 同时写一个内存地址，这种操作也是不允许的，会导致一些比较奇怪的问题；

总体来看其实就是写map的操作和其他的读或者写同时发生了，导致的报错，做过几年开发的人可能会想到使用锁来解决，比如写map某个key的时候，通过锁来保证其他goroutine不能再对其写或者读了。

实现思路：

（1）当写map的某个key时，通过锁来保证其他goroutine不能再对其写或者读了。

（2）当读map的某个key时，通过锁来保证其他的goroutine不能再对其写，但是可以读。

于是我们马上想到golang 的读写锁貌似符合需求，下面来实现下：

再来看下运行结果：

发现没有报错了，并且多次运行的结果都不会报错，说明这个方法是有用的，不过在go1.9版本后就有sync.Map了，不过这个适用场景是读多写少的场景，如果写很多的话效率比较差，具体的原因在这里笔者就不介绍了，后面会写篇文章详细介绍下。

今天的文章就到这里了，如果有不对的地方欢迎小伙伴给我留言，看到会即时回复的。

Go sync/atomic包Load和Store并发不安全

前言：为了保证并发安全，go语言中可以使用原子操作。其执行过程不能被中断，这也就保证了同一时刻一个线程的执行不会被其他线程中断，也保证了多线程下数据操作的一致性。

在atomic包中对几种基础类型提供了原子操作，包括int32，int64，uint32，uint64，uintptr，unsafe.Pointer。

对于每一种类型，提供了五类原子操作分别是

Load和Store操作对应与变量的原子性读写，许多变量的读写无法在一个时钟周期内完成，而此时执行可能会被调度到其他线程，无法保证并发安全。

⚠️Load 只保证读取的不是正在写入的值，Store只保证写入是原子操作。

所以在使用的时候要注意。

下面简单示例：

点击?查看源码，哈哈哈…

原创文章，作者：小蓝，如若转载，请注明出处：https://www.506064.com/n/280593.html