偶尔讨论到了socket发送数据时是否应该加锁的问题，就在网上查了一下，下面是大神陈硕的答案
- 对于 UDP，多线程读写同一个 socket 不用加锁，不过更好的做法是每个线程有自己的 socket，避免 contention，可以用 SO_REUSEPORT 来实现这一点。
- 对于 TCP，通常多线程读写同一个 socket 是错误的设计，因为有 short write 的可能。假如你加锁，而又发生 short write，你是不是要一直等到整条消息发送完才解锁（无论阻塞IO还是非阻塞IO）？如果这样，你的临界区长度由对方什么时候接收数据来决定，一个慢的 peer 就把你的程序搞死了。
这里解释下什么是short write
对于一个非阻塞的TCP套接口，如果其发送缓冲区中根本没有空间，输出函数调用将立即返回一个EWOULDBLOCK错误。如果其发送缓冲区中有一些空间，返回值将是内核能够拷贝到该缓冲区中的字节数。这个字节数也称为不足计数(应该就是short write的意思)
那么陈硕大神的意思是 如果接收方的滑动窗口一直为0，则发送方一直不会发送数据，则会一直持有锁，就算是非阻塞的，立刻返回后我们就不对接下来的数据进行发送了么？则一直等待在那里
socket分为阻塞模式和非阻塞模式。
| 阻塞 | 非阻塞 | |
| read | 接收缓冲区只要有数据就立即返回，只有当接收缓冲区为空时才阻塞等待 | 无论有无数据，都立即返回 |
| write | 只有发送缓冲区可以放下整个buffer时才返回，否则阻塞 | 无论发送缓冲区是否能放下整个buffer，都立即返回。返回能够放下的字节数 |
1. read总是在接收缓冲区有数据时立即返回，而不是等到给定的read buffer填满时返回。
只有当receive buffer为空时，blocking模式才会等待，而nonblock模式下会立即返回-1（errno = EAGAIN或EWOULDBLOCK）
2. blocking的write只有在缓冲区足以放下整个buffer时才返回（与blocking read并不相同）
nonblock write则是返回能够放下的字节数，之后调用则返回-1（errno = EAGAIN或EWOULDBLOCK）
对于blocking的write有个特例：当write正阻塞等待时对面关闭了socket，则write则会立即将剩余缓冲区填满并返回所写的字节数，再次调用则write失败（connection reset by peer），这正是下个小节要提到的：