C语言出身,看dubbo服务时多线程共享一个长连接时,在想为什么不会出现数据写乱的情况(不是粘包的那种),也就是一个socket缓冲区中,先写了A包的一部分,又写了B包的一部分,再写了A包的一部分???
“b”数据包只出现了一次,在数据包50。通过wireshark我计算出来前49个数据包一共是390800字节,每次a都是32768一组,那么前49个数据包发送了390800/32768.0= 11.9组“a”。注意:这是一个小数,也就是说最后第12块数据应该全是“a”而这10bytes的“b”完全是“乱入”。
分析
先看一下write方法的工作过程(所有的网络写入其实都是这个系统调用)
write函数最终会调用内核中的tcp_sendmsg函数,数据先被复制到tcp buffer中(这是位于内核的一块存储空间,大小是由参数tcp_wmem控制的),然后加上TCP头、加上IP头,丢给物理网卡。物理网卡中有一块发送队列的存储空间用来存放所有待发送数据。这个发送队列比较特殊是“环形”结构(ring),如果数据太多来不及发送会被丢弃掉(与之对应网卡还有“接收队列”,也是ring结构)。
虽然这个函数开始的时候通过lock_sock 上了锁但是它绝对仅仅代表是线程安全而不是无状态一个的函数。
无状态是指,只要输入的参数一样那么得到的结果应该是一致的;而线程安全是指两个线程可以同时访问。所以无状态一定是线程安全的,而反之则未必。
A、B两个线程,其中A每次写入32k,32k可能会被拆分成多次写入(根据buffer剩余空间决定真正能写入多少数据);B每次写入10bytes。如果内存不足(图中的wait_for_sndbuf和wait_for_memory)只写入一部分数据那么内核会调用sk_stream_wait_memory等待内存,而这个函数里面会释放sk。完整的调用链sk_stream_wait_memory->sk_wait_event->lock_sock。
当A写入数据的时候资源不足所以写入不完整于是释放资源,而B此时有机会被执行后刚好资源得到释放,于是写入成功;而A再次被执行的时候继续写入未完成的数据时,B已经“乱入”成功。
深度分析
如果你去做实验的话可能无法重现我上面的错误,因为这个问题跟语言有关。
首先,tcp_sendmsg不承诺“无状态”(或者叫原子性),这比较容易理解——毕竟send buffer满了,线程等待内存空间此时不应该继续占着“socket”(文件描述符)。内核要保证进程不被饿死,让资源尽可能的最大化的发挥作用。
那么做出“无状态”承诺的只能是应用程序,除了C语言之外其他的编程语言都不是直接调用systemcall,所以势必对socket写入函数做各种合理封装。
经过我实验发现Python、C语言会出现问题,而Java和Golang不会出现问题。以Java为例(SocketOutputStream.java):
这个函数没有返回值,它先对文件描述符(FD)加锁,然后一直尝试写入直到写入完len长度的数据为止。
Golang也有类似的实现,而Python中它的实现是这样的
看到了吗?虽然一直在调用write(system call)写入,但是并没有对文件描述符加锁,所以Python的实现不承诺“无状态”。
而C语言的实现基本上和Python的实现一样。
正确方式
有三种办法解决这个问题
1. 统一由一个Writer线程负责写入,其他线程通过Queue发送数据给Writer;
2. 每个线程各自启动一个TCP连接,不考虑连接复用(其实开销真不大);
3. 参考Java或者Golang的实现,为write加上锁;
转自:http://www.10tiao.com/html/254/201712/2648945984/1.html
有疑问加站长微信联系(非本文作者)