还有，我看你里面有自旋，这显然是不太好的

话说你都加了互斥锁了，那个 slice 的 value 完全没必要用 atomic.Value 了

@wencan 数据竞争是有的，只不过不容易测出来吧。
比如函数 func (slice *Slice) Append(p interface{}) int 中，在互斥锁之前会读 limitSlicesNum ，互斥锁之后会写 limitSlicesNum 。而且这两个是可以同时发生的。

还有喜欢檀香味的呢，说通俗就是尼姑味

@tsotsi 去掉也不行什么意思？ 我那个是 ut 是证明 op 的那个库是并发不安全的

@tsotsi range 的时候读取是更新前的还是后的，这取决于设计（是整体的并发安全还是对元素的并发安全）。从这个角度来说我那个 ut 不太准确。

但还是那个结论。如果把竞争检测开启，我那个 ut 会有竞争、而你那个 sync.Map 不会有

time.Time 就是 nano 时间戳加时区嘛。json 是要序列化成可读的啊。你不想要毫秒，就直接 parse 成字符串啊

@wencan 起码你不应该用 atomic.Value 存指针。对于 slice 的操作，你应该对其细化，比如 read1 的时候 updata2 这种就可以不用串行化。其实都类似于无锁队列一样，只是 slice 更复杂

@tsotsi 有啥问题，就是为了测并发操作啊

会 block 吗？我记得只是浏览器的锁会警告

@wencan 这和 range 无关，只是 range 更好测出来，atomic.Value 的使用是完全错误的。

你对 atomic.Value 的理解完全是错误的，应该从内存角度来看。像这个 ut 就过不了

```golang
func Test_Concurrent(t *testing.T) {
var slice Slice
slice.Append(0)
slice.Append(1)
slice.Append(2)
slice.Append(3)

go func() {
time.Sleep(time.Second * 2)
slice.UpdateAt(3, 0)
time.Sleep(time.Second * 5)
}()

slice.Range(func(index int, p interface{}) (stopIteration bool) {
time.Sleep(time.Second)
require.Equal(t, index, p)
return false
})
}
```

我们说原子变量比锁快，是因为原子变量相当于颗粒度更小的锁，如果锁和原子变量颗粒度相同，那么是没有性能差别的。

@keppelfei 东软是吧？

就你列的那两个数，用基础类型是足以应付的

官方库不是有 big 嘛？ math/big/#Float.Mul 。float 数据库存字符串就行。基础类型的 float 只能表示 16 位精度

就算你搭了个内网 git server ；还不是得手动把 GitHub 上的下载下来、再导入到你的 git 上。。这不一样嘛