什么壁纸这么逼真？

> 只 add 的话，bag 会有几倍的优势

要不先试试弄个并发消息队列试试能不能比 chan 性能提升？我不太确定，因为还要有唤醒机制，用 cond 的话，意义还是不太大，可能优势主要是代码比 chan 的逻辑简单

因为数据存起来主要就是为了拿出来用，所以只 add 的场景，我暂时还想不出来

开始写 go 后我一直忽略了 go 的无锁相关，觉得没用，闲了我也学习研究下你的实现。

> 额外问下，nbio 是不是牛逼 io 的意思？

主要是 non-blocking 的意思，早期版本 readme 里还真加过牛逼的意思，后来删掉了：
https://github.com/lesismal/nbio/commit/c5122cc157bf098a4354eb75773c672233fb41de
性能应该是不输于其他 poller 框架的（ evio/easygo/gnet/gev ）:
https://github.com/lesismal/go-net-benchmark/issues/1

但是功能、可定制扩展空间，比他们丰富太多了，所以也对得起牛逼这俩字了。

我还想支持 HTTP2.0/3.0 ，但是工程量有点大、时间和体力吃不消，如果有兴趣，业余时间可以一起玩玩

> slice 的 Load 问题，如果是纯 Load ，Load 时没有 Append 和 Update ，确实不需要加锁。
> 欢迎提供能发挥场景多的无锁数据结构需求。

我以前接触过的、自己能想到的并发无锁优化性能的场景暂时只有一个，无锁队列做生产者消费者。比如多 IO 线程把事件丢到队列里，每个队列单线程 eventloop 消费。
但这种生产消费模型，也是与锁、同步（包括唤醒）机制比如信号量条件量。
通常的原子性（一组操作）场景都是不能简单到只使用无锁数据结构实现的，而 go 的 chan 里已经是自带了同步唤醒机制，入队出队也都是它自带流程里处理了的，所以多数时候，直接使用 chan 也就够用了。

我在自己网络框架中，对每个 connection 事件的有序执行设计用到了个执行队列，但是是直接用的[]T+Mutex ，因为对于单个 connection ，并发竞争的概率极低，Lock/Unlock 的开销就也只是简单的原子操作，所以也没必要引入无锁数据结构，而且是需要先判断是否队首再看要不要 pop 的多步骤，简单的无锁 get/set 并不能满足需求：
https://github.com/lesismal/nbio/blob/master/conn.go#L82

无竞争时 Mutex 的开销：
https://github.com/golang/go/blob/master/src/sync/mutex.go#L83

> 下面这个，烦劳提供改动后的代码：

sync.Map 源码里注释我的理解主要是优化多读、多读写（估计主要是读多）的场景，所以多写的场景，可能 Mutex+map 就好了，这个场景用 sync.Map 实际上是性能下降的。我改动的也只是换成 Mux+map:

func BenchmarkSyncMapWrite(b *testing.B) {
var mux sync.Mutex
var mapping = map[int]int{}

ch := make(chan int, 10000000)

b.ResetTimer()
b.RunParallel(func(p *testing.PB) {
var i int
for p.Next() {
mux.Lock()
mapping[i] = i
mux.Unlock()
ch <- i

i++

delI := <-ch
mux.Lock()
delete(mapping, delI)
mux.Unlock()
}
})
}

上一楼 slice get 的贴错行了，更正下：
BenchmarkSlice_Load-16 115303052 10.37 ns/op 0 B/op 0 allocs/op
BenchmarkMutexSlice_Load-16 1000000000 0.07651 ns/op 0 B/op 0 allocs/op

如我上一楼所说，BenchmarkMutexSlice_Load 是把 Lock/Unlock 去掉了的，这样才是公平的

sync.Map 主要用途 go 源码注释里有写的：
// The Map type is optimized for two common use cases: (1) when the entry for a given
// key is only ever written once but read many times, as in caches that only grow,
// or (2) when multiple goroutines read, write, and overwrite entries for disjoint
// sets of keys. In these two cases, use of a Map may significantly reduce lock
// contention compared to a Go map paired with a separate Mutex or RWMutex.

所以 OP 跟它比 Write 没什么意义，换成 mutex+map 后，我只简单跑了下我笔记本的 windows 环境，没多测，但是估计也不会有太好的结果：
BenchmarkBagWrite-16 3418212 347.2 ns/op 87 B/op 3 allocs/op
BenchmarkSyncMapWrite-16 5754406 219.8 ns/op 0 B/op 0 allocs/op


slice 的场景，append 应该是非常少于读写的吧，如果多余那八成是做队列用 list 更好了。
而一个普通的[]T ，在单纯的 get/set 语义下，不加锁时才是与 OP 的无锁 slice 等价，因为都只是 get/set 并不是需要处理额外的其他一组操作，所以 OP 的 BenchmarkMutexSlice_Load 这里给[]T 加锁是不公平的，去掉则也是劣势得多了：
BenchmarkMutexSlice_Load-16 12368889 96.06 ns/op 0 B/op 0 allocs/op
BenchmarkRWMutexSlice_Load-16 1000000000 0.07468 ns/op 0 B/op 0 allocs/op


原子操作能解决的问题场景太少了，现实场景绝大多数需要的是“原子性”对一组操作的保障，尤其是 go 这种逻辑并发流非常多的场景，无锁数据结构能发挥的场景点就更少了

加快了机器生命取代人类的进程

gopher-lua 的性能比较差，而且不管是 c 版还是 go 版的 lua 都不支持并发，多个 lua state 对性能提升意义也不大。另外，如果 lua 写复杂了 gopher-lua 的语法解析还可能出错、运行不正确。

> 如果每个 lua 请求都是新的 State 呢

@Aidenboss 这个成本就更高了，这会让你的程序慢太多了，只适合请求量低的系统。

@xx6412223 心跳用 db.Ping()就行了。但 Ping 也只是单个连接，如果要每个连接 7 层 keepalive 可能还是要自己封装下。
@yuancoder conn 的 keepalive 只是 4 层的，不过也还好，数据库都内网，比较稳定，够用了

vscode 足够了

I got it, sitting style is more important than the fingering style...

试用过几个，fyne 确实玩具，目前发现最强的是：
https://gioui.org

例子：
https://github.com/gioui/gio-example

楼主可以试试，他们仓库和 slack 群也都比较活跃

C Primer Plus 只能算一般，而且非常一般，入门看看也行，但未必比谭浩强的效果好
K&R 太老了而且内容也不算多，讲真，不是很适合

三剑客基本是必读的：《 C 和指针》《 C 陷阱与缺陷》《 C 专家编程》

有人整理了个指针相关的 《让你不再害怕指针》，半小时深入理解下，基本就能搞定指针了

系统之类相关的进阶：
《 CSAPP 》
《 APUE 》
《 UNP 》
《程序员的自我修养》《连接器与加载器》
《深入理解 linux 内核》
《 linux 设备驱动程序》

单就语言语法来讲，国内的一些还行，《狂人 C 》，其他的名字不记得了

这些够啃一阵子了，啃明白了语言和基础的系统只是，自己找个具体的业务方向再啃相关的吧

原来现金支付才是王道。。

这个课代表，能处

似乎我的 arpc 就能搞定绝大多数了
对于“高效率的开发，支持通过 proto 生成代码“想做也容易，但我觉得这反倒不如我现在支持的方式更简洁省力，反倒限制了自由度所以没做

github.com/lesismal/arpc

@lesismal #21
有兴趣的可以看下例子，再对比下 orm ，或者 sqlx 之类的，看看哪个好用。

@join 我这个也不是只支持 mysql 呀，主要是为了方便标准库 sql 与结构体的映射，并不限制用哪个 driver 。但我不是每个数据库都测了，目前 mysql 和 postgres 是可以的，如果 oracle 、sqlserver 或者其他的数据库有问题（应该只是占位符不一样会导致拼接的 sql 语句错误），我可以继续做兼容。

另外，不知道兄台多大年纪，但我也已经不是小伙子了。