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

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

m 要加锁

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

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

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

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

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

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

https://gobyexample.com/mutexes

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

@raincious

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

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

@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 个回复的时候，会 @自己，这有什么好处吗？

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

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

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

并不会影响 iterator 过程

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

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

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

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

@mahone3297 可以试试。%010d