[GH-ISSUE #202] 多核CPU在批量Stop服务时，程序崩溃 #126

New issue

Closed

opened 2026-02-27 23:15:33 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 23:15:33 +03:00

Owner

Originally created by @AlibabaDAMO on GitHub (Dec 29, 2018).
Original GitHub issue: https://github.com/snail007/goproxy/issues/202

之前一直在用单核的虚拟机，后来因为其它关系，E5的一台主机腾了出来，就开始用这台物理机测试。
测试平台：windows2008 windows2012 windows2016

主机配置：
CPU:E5-2695v42
内存:16G8

测试SDK：Windows SDK Android SDK
SKD版本：6.0-6.7 & dev
测试命令：sps -S socks -T tcp -P 100.159.43.33:1080 -A gpsdk:gpsdk -t tcp -p :{顺序端口} -h aes-192-cfb -j pass
测试描述：Start开启1.3w个服务，然后批量Stop服务，gpsdk发生崩溃。且CPU核心数越多，崩溃越提前。

分析原因：如果还是按照不可中断或者不会被线程调度机制打断理解的话，那么多核下的原子操作，没有保证操作数据的一致性导致的。

建议使用：
1>锁定总线技术
spin lock必须基于CPU的数据总线锁定, 它通过读取一个内存单元(spinlock_t)来判断这个spinlock是否已经被别的CPU锁住. 如果否, 它写进一个特定值, 表示锁定了总线, 然后返回. 如果是, 它会重复以上操作直到成功, 或者spin次数超过一个设定值. 记住上面提及到的: 锁定数据总线的指令只能保证一个指令操作期间CPU独占数据总线. (spinlock在锁定的时侯, 不会睡眠而是会持续的尝试).
2>保持线程间：内存可见性、有序性、原子性。

参考资料:

1>MESI协议文档：https://en.wikipedia.org/wiki/MESI_protocol
2>从多核硬件架构，看Java内存模型。举一反三：https://blog.csdn.net/ljheee/article/details/82317174

Originally created by @AlibabaDAMO on GitHub (Dec 29, 2018). Original GitHub issue: https://github.com/snail007/goproxy/issues/202 之前一直在用单核的虚拟机，后来因为其它关系，E5的一台主机腾了出来，就开始用这台物理机测试。测试平台：windows2008 windows2012 windows2016 主机配置： CPU:E5-2695v4*2 内存:16G*8 测试SDK：Windows SDK Android SDK SKD版本：6.0-6.7 & dev 测试命令：sps -S socks -T tcp -P 100.159.43.33:1080 -A gpsdk:gpsdk -t tcp -p :{顺序端口} -h aes-192-cfb -j pass 测试描述：Start开启1.3w个服务，然后批量Stop服务，gpsdk发生崩溃。且CPU核心数越多，崩溃越提前。分析原因：如果还是按照不可中断或者不会被线程调度机制打断理解的话，那么多核下的原子操作，没有保证操作数据的一致性导致的。建议使用： 1>锁定总线技术 spin lock必须基于CPU的数据总线锁定, 它通过读取一个内存单元(spinlock_t)来判断这个spinlock是否已经被别的CPU锁住. 如果否, 它写进一个特定值, 表示锁定了总线, 然后返回. 如果是, 它会重复以上操作直到成功, 或者spin次数超过一个设定值. 记住上面提及到的: 锁定数据总线的指令只能保证一个指令操作期间CPU独占数据总线. (spinlock在锁定的时侯, 不会睡眠而是会持续的尝试). 2>保持线程间：内存可见性、有序性、原子性。参考资料: 1>MESI协议文档：[https://en.wikipedia.org/wiki/MESI_protocol](url) 2>从多核硬件架构，看Java内存模型。举一反三：[https://blog.csdn.net/ljheee/article/details/82317174](url)