smallnest

这个基本无人维护了。欢迎你和有志于做Java版的同学维护起来

修复了。 先前代码不合理。本来使用singleflight就好了，没必要再加锁。 这样不会有大量的goroutine都在抢这把锁。服务器异常情况下应该1秒就返回了。 第二个是个优化项，尝试实现了一下，还没有优雅的实现。现在要实现的话会破坏Selector接口向下兼容性，暂时不实现了。 anyway, 不会再有等待锁的问题

rpcx-etcd的log日志呢?看起来只能是rpcx-etcd没有重新watch

etcd集群有什么问题吗？

ConnectionTimeout 超时设置大一些呢，比如1分钟？ 是因为rpcx无限次的重连导致的etcd集群高？

实现了一个泛型的通用的堆 https://pkg.go.dev/github.com/smallnest/[email protected]/container/heap#BinHeap 以及把一个已存在的slice转化成一个堆

> @rfyiamcool > 大佬可以再对比测试下，当不使用 workerpool，直接 go func() 所表现的吞吐率和延迟？ 已加

> @bigwhite > 第三篇Russ Cox已经发出，期待晁老师译文。 抓紧翻译，请白老师批评指正

> @keakon > 「与Java不同，C++没有给有种族的程序任何保证」，这里的「种族」应该翻译成「竞争」。 Yes，fixed

因为`metadata`即使是检测到有并发读写，但是这个`struct`本身并没有在“出现并发读写时候”做额外的处理(panic)，所以concurrentStruct不会出错。 与map对象相比，map类型会检测到， 比如 https://github.com/golang/go/blob/b080abf656feea5946922b2782bfeaa73cc317d4/src/runtime/map_fast64.go#L60，所以会panic。 如果你确定会有并发问题， 一般就使用`concurrentStructWithMuLock` > @fastcgi > > ### colobu 大师，你好 > > 按照你这个文章， 我做了一个测试（代码贴在下面在了），有一些疑问： > > - 为何 `struct`在不加锁的情况下并发读写，有`WARNING: DATA RACE`，但是不挂呢？ > - 那我们在开发服务端程序的时候，要如何"最佳实践"结构体的并发控制呢？ > > >...