你们有没有也发现，OP 的头像跟 OP 本人确实挺搭的

00 后整治职场，这里只建议 00 后不要学，否则就是四九国军。

PS ，标题第一眼看成了 “不会说人话的。。。”

让我们这些 7080 后的人情何以堪

好嘛，35 岁还不够早，感觉以后大厂要搞 32 岁毕业了

@qeqv 这几年 AI 写作发展太快了，以后类似的会越來越多

OP 的行文，不像是人，猜测是 AI 在进行机器学习吧。

其他那些功能太多了，涉及到的细节处理也多。
我的库主要就是在 std 基础上封装了反射的部分，rawsql 能用的部分依旧能用，封装过的 sqlw.DB 提供了一点便捷的方法，让用户减轻结构体与传参、结果绑定部分的工作量，如果熟悉标准库的 rawsql ，不需要去学习其他那些库的基础只是、看下例子就懂了
话说，我就是因为其他库太复杂了，学不懂 /动，所以一直使用 rawsql ，后来写了这个，省力多了

试试我这个呀：
https://github.com/lesismal/sqlw

我也喜欢原生，但是 sqlx 那些也并不好用，所以按照自己喜欢的方式撸了个

旧帖：
https://www.v2ex.com/t/861739

也欢迎关注我的其他库：
https://www.v2ex.com/t/794435#reply4

什么壁纸这么逼真？

> 只 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...