2024-12-03 00:30:31
Go提供了一种称为通道的机制,用于在goroutine之间共享数据。当您作为goroutine执行并发活动时,需要在goroutine之间共享资源或数据,通道充当goroutine之间的管道(管道)并提供一种机制来保证同步交换。
根据数据交换的行为,有两种类型的通道:无缓冲通道和缓冲通道。无缓冲通道用于执行goroutine之间的同步通信,而缓冲通道用于执行异步通信。无缓冲通道保证在发送和接收发生的瞬间两个goroutine之间的交换。缓冲通道没有这样的保证。
通道由make函数创建,该函数指定chan关键字和通道的元素类型。
这是创建无缓冲和缓冲通道的代码块:
语法
使用内置函数make创建无缓冲和缓冲通道。make的第一个参数需要关键字chan,然后是通道允许交换的数据类型。
这是将值发送到通道的代码块需要使用-运算符:
语法
一个包含5个值的缓冲区的字符串类型的goroutine1通道。然后我们通过通道发送字符串“Australia”。
这是从通道接收值的代码块:
语法
-运算符附加到通道变量(goroutine1)的左侧,以接收来自通道的值。
在无缓冲通道中,在接收到任何值之前没有能力保存它。在这种类型的通道中,发送和接收goroutine在任何发送或接收操作完成之前的同一时刻都准备就绪。如果两个goroutine没有在同一时刻准备好,则通道会让执行其各自发送或接收操作的goroutine首先等待。同步是通道上发送和接收之间交互的基础。没有另一个就不可能发生。
在缓冲通道中,有能力在接收到一个或多个值之前保存它们。在这种类型的通道中,不要强制goroutine在同一时刻准备好执行发送和接收。当发送和接收阻塞时也有不同的条件。只有当通道中没有要接收的值时,接收才会阻塞。仅当没有可用缓冲区来放置正在发送的值时,发送才会阻塞。
实例
运行结果
【golang】高并发下TCP常见问题解决方案首先,看一下TCP握手简单描绘过程:
其握手过程原理,就不必说了,有很多详细文章进行叙述,本文只关注研究重点。
在第三次握手过程中,如果服务器收到ACK,就会与客户端建立连接,此时内核会把连接从半连接队列移除,然后创建新的连接,并将其添加到全连接队列,等待进程调用。
如果服务器繁忙,来不及调用连接导致全连接队列溢出,服务器就会放弃当前握手连接,发送RST给客户端,即connectionresetbypeer。
在linux平台上,客户端在进行高并发TCP连接处理时,最高并发数量都要受系统对用户单一进程同时打开文件数量的限制(这是因为系统每个TCP都是SOCKET句柄,每个soker句柄都是一个文件),当打开连接超过限制,就会出现toomanyopenfiles。
使用下指令查看最大句柄数量:
增加句柄解决方案
Golang并发读写map安全问题详解
下面先写一段测试程序,然后看下运行结果:
运行结果:
发生了错误,提示:fatalerror:concurrentmapreadandmapwrite,map发生了同时读和写了;但是这个错误并不是每次运行都会出现,就是有的时候会出现,有的时候并不会出现,根据笔者多次运行结果(其他例子,读者可以自己尝试下)来看还会有另外一种报错就是:fatalerror:concurrentmapwrites,就是map发生了同时写,但是只是读是不会有问题的。关于不同的运行结果小伙伴们可以自己写几个例子去测试下。下面就这两个错误的发生,笔者给出如下解释:
(1)fatalerror:concurrentmapreadandmapwrite
就是当一个goroutine在写数据,而同时另外一个goroutine要读数据就会报错,不过这个报错也很好理解:还没写完就读,读的数据会有问题,或者反过来还没读完就开始写了,同样会导致读取的数据有问题;
(2)fatalerror:concurrentmapwrites
两个goroutine同时写一个内存地址,这种操作也是不允许的,会导致一些比较奇怪的问题;
总体来看其实就是写map的操作和其他的读或者写同时发生了,导致的报错,做过几年开发的人可能会想到使用锁来解决,比如写map某个key的时候,通过锁来保证其他goroutine不能再对其写或者读了。
实现思路:
(1)当写map的某个key时,通过锁来保证其他goroutine不能再对其写或者读了。
(2)当读map的某个key时,通过锁来保证其他的goroutine不能再对其写,但是可以读。
于是我们马上想到golang的读写锁貌似符合需求,下面来实现下:
再来看下运行结果:
发现没有报错了,并且多次运行的结果都不会报错,说明这个方法是有用的,不过在go1.9版本后就有sync.Map了,不过这个适用场景是读多写少的场景,如果写很多的话效率比较差,具体的原因在这里笔者就不介绍了,后面会写篇文章详细介绍下。
今天的文章就到这里了,如果有不对的地方欢迎小伙伴给我留言,看到会即时回复的。
golangsync.pool对象复用并发原理缓存池在gohttp每一次goserve(l)都会构建Request数据结构。在大量数据请求或高并发的场景中,频繁创建销毁对象,会导致GC压力。解决办法之一就是使用对象复用技术。在http协议层之下,使用对象复用技术创建Request数据结构。在http协议层之上,可以使用对象复用技术创建(w,*r,ctx)数据结构。这样即可以回快TCP层读包之后的解析速度,也可也加快请求处理的速度。
先上一个测试:
结论是这样的:
貌似使用池化,性能弱爆了???这似乎与net/http使用sync.pool池化Request来优化性能的选择相违背。这同时也说明了一个问题,好的东西,如果滥用反而造成了性能成倍的下降。在看过pool原理之后,结合实例,将给出正确的使用方法,并给出预期的效果。
sync.Pool是一个协程安全的临时对象池。数据结构如下:
local成员的真实类型是一个poolLocal数组,localSize是数组长度。这涉及到Pool实现,pool为每个P分配了一个对象,P数量设置为runtime.GOMAXPROCS(0)。在并发读写时,goroutine绑定的P有对象,先用自己的,没有去偷其它P的。go语言将数据分散在了各个真正运行的P中,降低了锁竞争,提高了并发能力。
不要习惯性地误认为New是一个关键字,这里的New是Pool的一个字段,也是一个闭包名称。其API:
如果不指定New字段,对象池为空时会返回nil,而不是一个新构建的对象。Get()到的对象是随机的。
原生sync.Pool的问题是,Pool中的对象会被GC清理掉,这使得sync.Pool只适合做简单地对象池,不适合作连接池。
pool创建时不能指定大小,没有数量限制。pool中对象会被GC清掉,只存在于两次GC之间。实现是pool的init方法注册了一个poolCleanup()函数,这个方法在GC之前执行,清空pool中的所有缓存对象。
为使多协程使用同一个POOL。最基本的想法就是每个协程,加锁去操作共享的POOL,这显然是低效的。而进一步改进,类似于ConcurrentHashMap(JDK7)的分Segment,提高其并发性可以一定程度性缓解。
注意到pool中的对象是无差异性的,加锁或者分段加锁都不是较好的做法。go的做法是为每一个绑定协程的P都分配一个子池。每个子池又分为私有池和共享列表。共享列表是分别存放在各个P之上的共享区域,而不是各个P共享的一块内存。协程拿自己P里的子池对象不需要加锁,拿共享列表中的就需要加锁了。
Get对象过程:
Put过程:
如何解决Get最坏情况遍历所有P才获取得对象呢:
方法1止前sync.pool并没有这样的设置。方法2由于goroutine被分配到哪个P由调度器调度不可控,无法确保其平衡。
由于不可控的GC导致生命周期过短,且池大小不可控,因而不适合作连接池。仅适用于增加对象重用机率,减少GC负担。2
执行结果:
单线程情况下,遍历其它无元素的P,长时间加锁性能低下。启用协程改善。
结果:
测试场景在goroutines远大于GOMAXPROCS情况下,与非池化性能差异巨大。
测试结果
可以看到同样使用*sync.pool,较大池大小的命中率较高,性能远高于空池。
结论:pool在一定的使用条件下提高并发性能,条件1是协程数远大于GOMAXPROCS,条件2是池中对象远大于GOMAXPROCS。归结成一个原因就是使对象在各个P中均匀分布。
池pool和缓存cache的区别。池的意思是,池内对象是可以互换的,不关心具体值,甚至不需要区分是新建的还是从池中拿出的。缓存指的是KV映射,缓存里的值互不相同,清除机制更为复杂。缓存清除算法如LRU、LIRS缓存算法。
池空间回收的几种方式。一些是GC前回收,一些是基于时钟或弱引用回收。最终确定在GC时回收Pool内对象,即不回避GC。用java的GC解释弱引用。GC的四种引用:强引用、弱引用、软引用、虚引用。虚引用即没有引用,弱引用GC但有空间则保留,软引用GC即清除。ThreadLocal的值为弱引用的例子。
regexp包为了保证并发时使用同一个正则,而维护了一组状态机。
fmt包做字串拼接,从sync.pool拿[]byte对象。避免频繁构建再GC效率高很多。
Golang使用redis阻塞读brpop实现即时响应并发执行主要利用redis的brpop阻塞读和Golang的goroutine并发控制以及os/exec执行程序,实现队列有数据就立即执行对应程序并把结果set任务key。
【Golang】context.Context解析最近听了一位同事的分享,他说如果一个人不能把它所研究的项目/概念用十分简单的话表述清楚,那么就说明他并没有真正理解这个项目。然后他拿物理中粒子的自旋进行举例,有人向教授请教相关概念,教授说:我需要思考一下如何用浅显的话进行表述。稍许之后,教授说:很抱歉,可能我只能用非常复杂的公式和概念向你解释了。这说明了可能人类对于这一现象的本质并没有理解。
结合我的上一篇文章最近的一些感悟-体系的力量,这更加说明了我们在学习的时候其实就是拨开繁杂的迷雾,去窥探一个概念、一个项目、一个体系它最核心的本质。计算机是一门科学,由人类创造,所以我们应该是能力用简单的话将它表述清楚的。所以我也会以这样的要求来进行写作,力求用最简单、清晰的语言来描述。
今天的内容是golang中的context包中的Context接口。
context.Context本身为interface(接口),主要用于父协程关闭后可以同步关闭所有子孙协程,是一种并发控制/协程同步的重要手段。
那么我们实现Context,只需要实现Done,Err,Value,Deadline四个方法即可:
context包中提供了如withCancel,withTimeout等一系列方法用于创建子context。context之间呈树状结构,当传递事件(如取消)/数据时,可以递归地从上到下进行传递以控制子孙协程。
WithCancel:
Cancel:
WithDeadline:
WithTimeout:实际上也是调用WithDeadline