zhiyong.luo
zhiyong.luo
@xtaci 的观点方向是正确的，我之前实现过类似算法，其实主要矛盾在于非阻塞io方式下如何设计良好的cork机制。我采用的办法是（说思路，忽略加锁细节）： 1、采用tcp per socket wirte buffer设计，且buffer通过内存池方式管理 2、异步read请求根据掩码选择读或者延迟读（cork方法会设置可用事件（读/写）掩码） 3、write 返回AGAIN后缓存，且设置源头socket读cork，防止快发送/慢接收持续恶化 4、有write缓存的socket，关注WRITABLE事件，可写时继续发送，如果发完release之前设置的cork，释放write-buffer 6、并发write请求时如果有未发送数据，且当前发送数据+待发送缓存>缓存最大值（默认设置256K per-socket）时，当前线程尝试发送，直到缓存空闲大小足以容纳当前发送数据大小
android推荐使用smarGate
可以留意一下具体复现的操作，便于排查问题
> > 可以留意一下具体复现的操作，便于排查问题 > > 昨天看到服务端有新的提交，我试着替换了下重新运行了大半天，暂时没复现25%占用的问题，但看着版本号没变，不晓得是不是程序修复了。 还有不知道跟网速有没有关系，所在的出租屋共用一条宽带，邻居不知道做了什么，他一下班回来网就很容易卡，卡到连打开个百度都失败的那种，前晚出现25%占用的时候，网就卡过一阵，不过昨天网很流畅，可能邻居回家过年了。 的确，当网络慢发送数据无法确保到达时，系统会尽可能重试，期间cpu会有增高现象，一般这种情况基本不会持续太长时间。建议再观察一下。
这种情况请排除一下网络原因，具体来讲除非SG没有收到tcp断开报文，且在已断开连接上发送数据未触发错误，才可能一直重试。建议： 1、排除是否有vpn网络影响 2、如有条件直接在“干净”的物理机上测试一下，看看是否仍然重现 另，测试时下载网盘上最新版本，修复了部分bug
windows确有BUG，但难以重现，如有可靠重现步骤，再行排查
已修复发现的相关BUG
1、使用最新更新后的版本进行测试，最新编译：v0.40.5 (2025-10-25 23:44:24） 2、其它平台版本没有发现此问题；在win7的旧电脑上（家宽、非移动网络）测试没有发现此种情况。 3、这个问题之前有issue #101 ,没有找到切实的原因。系统层面排查是否进行了网络切换，是否休眠等。
建议：使用最新更新后的版本进行测试，网络进行了一些优化 由于没有重现你的问题，多做一些尝试
请下载新版本再测试一下，最新版本已在如下环境测试，没有发现问题： 测试机环境： - 版本：Windows 11 家庭中文版 - 版本号：24H2 - 操作系统版本：26100.6899 - 系统类型：64 位操作系统, 基于 x64 的处理器