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
