Andy Pan

Sorry, I didn't check out the problem carefully before and thought you were talking about the server-side, have you tried not to use `ants` pool and what's the memory usage...

There is no way that `ants` doesn't control the concurrent amount correctly, what version of `ants` were you using? You can add some debug code into your `ants` function and...

> 同一个连接大量大写的情况下遇到一样的问题。特别是开10个连接大量读写的时候，尤其明显。性能直线下降 不管是什么网络框架，针对你说的这种大量读写的比如一个包几MB大的场景，性能肯定是会下降的，没有例外，还有 gnet 默认的 buffer 大小只有 64KB，如果是这种大包的场景可以通过调大读写 buffer 大小来适配： https://pkg.go.dev/github.com/panjf2000/gnet/v2#WithReadBufferCap https://pkg.go.dev/github.com/panjf2000/gnet/v2#WithWriteBufferCap

> hi panjf2000 ,[FJSDS]说的和我不是同一个问题。我的问题是可以解决的。这个是golang对map数据结构存储的限制，不能存储含有指针的超大内存。否则GC间歇性的扫描大内存，没有任何业务，cpu间歇性能够上升到70%，无法接受 。 你说的没错，big map 存指针的确会对 GC 造成很大的负担，但是你们一个进程连了几百万个 TCP 连接吗？这个我的确是没想到。。。

> 可以的话，我提交一份git修改。并附带一份测试200w的连接~ 可以的

能先说一下你的解决思路是什么吗？我昨天想了一下，最简单的做法就是用 slice 代替 map，fd 作为 slice 下标，但缺点是需要预分配固定长度的 slice，或者使用 map[int]int + slice，可以实现动态分配，但是又有可能在不断扩容 slice 的时候导致大量的拷贝，目前的思路是参考 [bigcache](https://github.com/allegro/bigcache) 的思路实现一个精简版的，基本思路也是 map[int]int + slice 但是更高效，看看你有没有更好的思路？ @situnan

> > 能先说一下你的解决思路是什么吗？我昨天想了一下，最简单的做法就是用 slice 代替 map，fd 作为 slice 下标，但缺点是需要预分配固定长度的 slice，或者使用 map[int]int + slice，可以实现动态分配，但是又有可能在不断扩容 slice 的时候导致大量的拷贝，目前的思路是参考 [bigcache](https://github.com/allegro/bigcache) 的思路实现一个精简版的，基本思路也是 map[int]int + slice 但是更高效，看看你有没有更好的思路？ @situnan > > 刚好也在梳理这一块，map[int]int + slice确实是一个比较好的思路，但也会附带其他的问题，如：高并发锁竞争问题、扩容、缩容的问题... 目前也还没想到比较好的方案！ @panjf2000 后续是否有计划调整udpSockets...

> 嗯。线程安全要独立考虑~ 不需要是线程安全的，gnet 里这个 map 不会被并发访问。

> 嗯。map[int]int + slice 模型。请参考： > > https://github.com/legougames/slice_map 他这个实现有点简单了，而且在 slice 不断扩容的情况下会导致大量的内存拷贝，可以参考下 bigcache 或者 fastcache 的思路，做一个精简版的。

@situnan 这里有什么进展吗？你要是没时间搞的话我就自己弄了。