默认的 http 那一套，是否保证了原子性？

The Go Programming Language

Go Projects

This topic created in 3847 days ago, the information mentioned may be changed or developed.

上一下代码

我的疑问：
1. 我用 ab -c 10 -n 100000 'http://192.168.81.130:8080/increase?key=user&count=1' 去压， server 端，应该是多 go routine 去处理， m 应该是保证不了原子性的吧？但是我的出来的值，却是
curl 'http://192.168.81.130:8080/debug'
debug v = map[user:100000]
很精准的值 100000 。。。测了多次都是。。。
所以，问题，是这个 http 包保证了？还是 map 保证了？还是其他？
我是否要用 https://golang.org/pkg/sync/atomic/ 包去保证原子性？

2. ab 的结果，如下图

Failed requests: 99991 有这么多 failed ？但是值又都有。这是为什么？

failed

map

原子性

下图

14 replies • 2015-12-03 10:53:07 +08:00

9hills

Dec 2, 2015

m[key] += 1
这个最后的累加结果和执行顺序无关，所以累加后的值应该是精确的

zzn

Dec 2, 2015

m 要加锁

zealot0630

Dec 2, 2015

go routine 是非抢占的意味着所有基本操作（非 syscall ）都是原子的

然而，你这个程序冲突概率太低了，即使使用 java/C++这种语言跑个几天大概能冲突一次吧

martifact

Dec 2, 2015

都不能保证。这个场景下 routine 之间的数据并发应该跟核数有关，概率确实挺低。

yinheli

Dec 2, 2015

1. 程序执行太快了. 要想模拟冲突, 应该先取出值, 然后随机 sleep 一会, 1 毫秒, 都够
2. `failed` 是因为你的响应, 不一致. ab 判断长度不同导致的

fwee

Dec 2, 2015

说版本， 1.5 之前默认是单核的协作式，这个结果正常

raincious

Dec 2, 2015

读公共数据的时候需要建立一个 mutex 来锁，否则铁定冲突。

https://gobyexample.com/mutexes

想看冲突的话， 1.4 以及之前需要用 runtime.GOMAXPROCS 来使用多个核心。

raincious

Dec 2, 2015

@raincious

修改，不仅仅是读，写的时候也要锁。详见 Golang 的 Sync 包： https://golang.org/pkg/sync/

如果只是一个 Int 的话，可以用 Atomic ，我上面帖的例子里也有。但是不知道是不是 atomic 和 mutex 必须结合起来一起用。（我记得只要用 mutex 锁上就好了，不知道记忆是否准确）

mahone3297

Dec 2, 2015

@9hills
》 m[key] += 1
》这个最后的累加结果和执行顺序无关，所以累加后的值应该是精确的
光是这样写，应该也是保证不了原子性的，所以才会有 atomic 库，这个页面中的例子就谈到了这样的情况
https://golang.org/pkg/sync/atomic/

@zzn 嗯，应该要加 atomic

@zealot0630 同上，这个加，应该是非原子的，看下这个库的介绍
https://golang.org/pkg/sync/atomic/

@martifact 确实，本来概率就低，我还虚拟机，分配的单核。。。看来环境也有问题

@yinheli
》 1. 程序执行太快了. 要想模拟冲突, 应该先取出值, 然后随机 sleep 一会, 1 毫秒, 都够
确实，说的有道理，考虑试试，谢谢指点。
2. `failed` 是因为你的响应, 不一致. ab 判断长度不同导致的
》这个不太明白，再解释下?

@fwee
最新版本， 1.5.1

@raincious
谢谢例子！好好研究下。
再问下，我们有些人，第 2 个回复的时候，会 @自己，这有什么好处吗？

msg7086

Dec 2, 2015

@mahone3297 at 自己表示编辑补充，属于惯例用法。
多数是发现自己上一段没说完整或者没说正确，所以提醒别人下一段是承接、修正上一段的。

pubby

Dec 2, 2015

map 并发读写要上锁，碰到过冲突 panic 的

另外提一下<map>有意思的地方
for i,_ := range <map> {
delete(<map>,i)
}

并不会影响 iterator 过程

pubby

Dec 2, 2015

ab 测试的时候，返回的内容长度不同，就会 failed

你的响应中 %d 只有 1-9 的时候长度才是一样的，后面都跟第一次不一样，所以全部 failed 了

mahone3297

Dec 3, 2015

@pubby
>map 并发读写要上锁，碰到过冲突 panic 的
>另外提一下<map>有意思的地方
for i,_ := range <map> {
delete(<map>,i)
}
>并不会影响 iterator 过程
有点意思。。。

>ab 测试的时候，返回的内容长度不同，就会 failed
>你的响应中 %d 只有 1-9 的时候长度才是一样的，后面都跟第一次不一样，所以全部 failed 了
原来是这样啊。。。了解了。他是要每个请求的返回长度都一样啊。那我这样的案例，如果测试请求是否成功呢？按照 ab 的逻辑，不行了。他干嘛不看返回的 http code 呢，真见鬼。

pubby

Dec 3, 2015 via Android

@mahone3297 可以试试。%010d