or
channel模式是一种并发控制模式,旨在多任务场景下实现,有一个任务成功返回即立即结束等待。
今天我们来看下两种不同的实现方式:
最近看了鸟窝的《Go并发编程实战课》,写的挺有意思的,打算后边弄些例子再回顾下并发原语。
今天来看看cond
原语。
cond
是用于等待或通知场景下的并发原语,条件不满足时,阻塞(wait
)一组goroutine
;条件满足后,唤醒单个(signal
)或所有(broadcast
)阻塞的goroutine
.
比如10个运动员跑步,都准备好了,裁判才发令的例子:
最近看Dave Cheney的一篇文章,发现一个有趣的代码片段,里面展示了一个8byte的内存优化。
代码片段是这样的:
1 | func BenchmarkSortStrings(b *testing.B) { |
Dig101: dig more, simplified more and know more
sync.Mutex
是Go
实现的互斥锁,提供了基本的同步操作,使用很方便。
不过,你是否好奇过,Go
是如何实现的Mutex
,又是为什么要这样实现?
今天跟随几个问题,我们一起探索下Mutex
背后的设计。
(不用担心,不会有大段的源码分析出现在本文😳)
Dig101: dig more, simplified more and know more
我们都知道Go
的struct
里,小写字段是非导出的,即不可从包外部访问。
但非导出字段在外部也并不是没有办法访问,也不是不可以修改。
今天看下reflect
包如何在包外操作非导出字段。
Dig101: dig more, simplified more and know more
今天来看一个小问题:如何在函数内部修改一个指针(参数或接收者)指向,使其值的改变能反映在函数外部?
直接上代码,这样可以么?
1 | type ArgType struct { |
今天聊一个最近升级go的protobuf
的故事。过程很是奇妙(曲折)😳
前两天,一个项目的dependabot
提示包github.com/golang/protobuf
可以从V1.3.5
升级到V1.4.0
Bundle
是OPA
管理policy
和data
的一种方式。
OPA
实现的轻量级策略引擎,一开始就是为了云原生环境的service
提供解耦的策略服务,分布式是必然要考虑的问题。
在Bundle api
的设计中,其实就全面考虑并体现了在分布式应用中如何更好的解耦策略引擎的管理。
比如:
有了这些功能,再加上其高效的策略描述语言Rego
,OPA
才真正称得上是云原生时代的通用策略引擎。
本文将带大家简单梳理一遍Bundle
的组织方式、管理api、及监控方式。
考虑到一次性过完不易消化,文末会提供一个直接可实操的docker-compose
版本的demo
,将全面覆盖本文细节
建议大家看完本文,本机运行去体验一下,会有更直观的理解。