下面大概分几个方面进行罗列：
Linux要包含
[cpp]
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.h>
等头文件，而windows下则是包含
[cpp]
#include <winsock.h>
。
Linux中socket为整形，Windows中为一个SOCKET。
Linux中关闭socket为close，Windows中为closesocket。
Linux中有变量socklen_t，Windows中直接为int。
因为linux中的socket与普通的fd一样，所以可以在TCP的socket中，发送与接收数据时，直接使用read和write。而windows只能使用recv和send。
设置socet选项，比如设置socket为非阻塞的。Linux下为
[cpp]
flag = fcntl (fd, F_GETFL);
fcntl (fd, F_SETFL, flag | O_NONBLOCK);
，Windows下为
[cpp]
flag = 1;
ioctlsocket (fd, FIONBIO, (unsigned long *) &flag);
。
当非阻塞socket的TCP连接正在进行时，Linux的错误号为EINPROGRESS，Windows的错误号为WSAEWOULDBLOCK。
file
Linux下面，文件换行是"\n"，而windows下面是"\r\n"。
Linux下面，目录分隔符是"/"，而windows下面是"\"。
Linux与Windows下面，均可以使用stat调用来查询文件信息。但是，Linux只支持2G大小，而Windows只支持4G大小。为了支持更大的文件查询，可以在Linux环境下加
_FILE_OFFSET_BITS=64定义，在Windows下面使用_stat64调用，入参为struct __stat64。
Linux中可根据stat的st_mode判断文件类型，有S_ISREG、S_ISDIR等宏。Windows中没有，需要自己定义相应的宏，如
[cpp]
#define S_ISREG(m) (((m) & 0170000) == (0100000))
#define S_ISDIR(m) (((m) & 0170000) == (0040000))
Linux中删除文件是unlink，Windows中为DeleteFile。
time
Linux中，time_t结构是长整形。而windows中，time_t结构是64位的整形。如果要在windows始time_t为32位无符号整形，可以加宏定义，_USE_32BIT_TIME_T。
Linux中，sleep的单位为秒。Windows中，Sleep的单位为毫秒。即，Linux下sleep (1)，在Windows环境下则需要Sleep (1000)。
Windows中的timecmp宏，不支持大于等于或者小于等于。
Windows中没有struct timeval结构的加减宏可以使用，需要手动定义：
[cpp]
#define MICROSECONDS (1000 * 1000)
#define timeradd(t1, t2, t3) do { \
(t3)->tv_sec = (t1)->tv_sec + (t2)->tv_sec; \
(t3)->tv_usec = (t1)->tv_usec + (t2)->tv_usec % MICROSECONDS; \
if ((t1)->tv_usec + (t2)->tv_usec > MICROSECONDS) (t3)->tv_sec ++; \
} while (0)
#define timersub(t1, t2, t3) do { \
(t3)->tv_sec = (t1)->tv_sec - (t2)->tv_sec; \
(t3)->tv_usec = (t1)->tv_usec - (t2)->tv_usec; \
if ((t1)->tv_usec - (t2)->tv_usec < 0) (t3)->tv_usec --, (t3)->tv_usec += MICROSECONDS; \
} while (0)
调用进程
Linux下可以直接使用system来调用外部程序。Windows最好使用WinExec，因为WinExec可以支持是打开还是隐藏程序窗口。用WinExec的第二个入参指明，如
SW_SHOW/SW_HIDE。
杂项
Linux为srandom和random函数，Windows为srand和rand函数。
Linux为snprintf，Windows为_snprintf。
同理，Linux中的strcasecmp，Windows为_stricmp。
错误处理
Linux下面，通常使用全局变量errno来表示函数执行的错误号。Windows下要使用GetLastError ()调用来取得。
Linux环境下仅有的
这些函数或者宏，Windows中完全没有，需要用户手动实现。
atoll
[cpp]
long long
atoll (const char *p)
{
int minus = 0;
long long value = 0;
if (*p == '-')
{
minus ++;
p ++;
}
while (*p >= '0' && *p <= '9')
{
value *= 10;
value += *p - '0';
p ++;
}
return minus ? 0 - value : value;
}
gettimeofday
[cpp]
#if defined(_MSC_VER) || defined(_MSC_EXTENSIONS)
#define EPOCHFILETIME 11644473600000000Ui64
#else
#define EPOCHFILETIME 11644473600000000ULL
#endif
struct timezone
{
int tz_minuteswest;
int tz_dsttime;
};
int
gettimeofday (struct timeval *tv, struct timezone *tz)
{
FILETIME ft;
LARGE_INTEGER li;
__int64 t;
static int tzflag;
if (tv)
{
GetSystemTimeAsFileTime (&ft);
li.LowPart = ft.dwLowDateTime;
li.HighPart = ft.dwHighDateTime;
t = li.QuadPart; /* In 100-nanosecond intervals */
t -= EPOCHFILETIME; /* Offset to the Epoch time */
t /= 10; /* In microseconds */
tv->tv_sec = (long) (t / 1000000);
tv->tv_usec = (long) (t % 1000000);
}
if (tz)
{
if (!tzflag)
{
_tzset ();
tzflag++;
}
tz->tz_minuteswest = _timezone / 60;
tz->tz_dsttime = _daylight;
}
return 0;
}
编译相关
当前函数，Linux用__FUNCTION__表示，Windows用__func__表示。
--------------------------------------------------------------------------------
Socket 编程 windows到Linux代码移植遇到的问题
1)头文件
windows下winsock.h/winsock2.h
linux下sys/socket.h
错误处理：errno.h
2)初始化
windows下需要用WSAStartup
linux下不需要
3)关闭socket
windows下closesocket(...)
linux下close(...)
4)类型
windows下SOCKET
linux下int
如我用到的一些宏：
#ifdef WIN32
typedef int socklen_t;
typedef int ssize_t;
#endif
#ifdef __LINUX__
typedef int SOCKET;
typedef unsigned char BYTE;
typedef unsigned long DWORD;
#define FALSE 0
#define SOCKET_ERROR (-1)
#endif
5)获取错误码
windows下getlasterror()/WSAGetLastError()
linux下errno变量
6)设置非阻塞
windows下ioctlsocket()
linux下fcntl() <fcntl.h>
7)send函数最后一个参数
windows下一般设置为0
linux下最好设置为MSG_NOSIGNAL，如果不设置，在发送出错后有可 能会导致程序退出。
8)毫秒级时间获取
windows下GetTickCount()
linux下gettimeofday()
3、多线程
多线程: (win)process.h --〉(linux)pthread.h
_beginthread --> pthread_create
_endthread --> pthread_exit
-----------------------------------------------------------------
windows与linux平台使用的socket均继承自Berkeley socket(rfc3493)，他们都支持select I/O模型，均支持使用getaddrinfo与getnameinfo实现协议无关编程。但存在细微差别，
主要有：
头文件及类库。windows使用winsock2.h(需要在windows.h前包含)，并要链接库ws2_32.lib；linux使用netinet/in.h, netdb.h等。
windows下在使用socket之前与之后要分别使用WSAStartup与WSAClean。
关闭socket，windows使用closesocket，linux使用close。
send*与recv*函数参数之socket长度的类型，windows为int，linux为socklen_t，可预编译指令中处理这一差异，当平台为windows时#define socklen_t unsigned int。
select函数第一个参数，windows忽略该参数，linux下该参数表示集合中socket的上限值，一般设为sockfd(需select的socket) + 1。
windows下socket函数返回值类型为SOCKET(unsigned int)，其中发生错误时返回INVALID_SOCKET(0)，linux下socket函数返回值类型int, 发生错误时返回-1。
另外，如果绑定本机回环地址，windows下sendto函数可以通过，linux下sendto回报错：errno=22, Invalid arguement。一般情况下均绑定通配地址。
转载jlins
⑵ Nginx锛氩熀链铡熺悊绡
Nginx镄処O阃氩父浣跨敤epoll锛宔poll鍑芥暟浣跨敤浜咺/O澶岖敤妯″瀷銆备笌I/O阒诲炴ā鍨嬫瘆杈冿纴I/O澶岖敤妯″瀷镄勪紭锷垮湪浜庡彲浠ュ悓镞剁瓑寰呭氢釜锛堣屼笉鍙鏄涓涓锛夊楁帴瀛楁弿杩扮﹀氨缁銆侼ginx镄别poll宸ヤ綔娴佺▼濡备笅锛
2 . 褰扑竴涓猚lient杩炴帴鍒版潵镞讹纴镓链塧ccept镄剋ork杩涚▼閮戒细鍙楀埌阃氱煡锛屼絾鍙链変竴涓杩涚▼鍙浠accept鎴愬姛锛屽叾瀹幂殑鍒欎细accept澶辫触锛孨ginx鎻愪緵浜嗕竴鎶婂叡浜阌乤ccept_mutex𨱒ヤ缭璇佸悓涓镞跺埢鍙链変竴涓犸ork杩涚▼鍦╝ccept杩炴帴锛屼粠钥岃В鍐虫侪缇ら梾棰
𨱍婄兢鐜拌薄锛氭侪缇ゆ晥搴斿氨鏄褰扑竴涓猣d镄勪簨浠惰瑙﹀彂镞讹纴镓链夌瓑寰呰繖涓猣d镄勭嚎绋嬫垨杩涚▼閮借鍞ら啋銆备竴鑸閮芥槸socket镄刟ccept()浼氩艰嚧𨱍婄兢锛屽緢澶氢釜杩涚▼閮絙lock鍦╯erver socket镄刟ccept()锛屼竴浣嗘湁瀹㈡埛绔杩涙潵锛屾墍链夎繘绋嬬殑accept()閮戒细杩斿洖锛屼絾鏄鍙链変竴涓杩涚▼浼氲诲埌鏁版嵁锛屽氨鏄𨱍婄兢銆
Nginx 閲囩敤accept-mutex𨱒ヨВ鍐虫侪缇ら梾棰桡细褰扑竴涓璇锋眰鍒拌揪镄勬椂鍊欙纴鍙链夌珵浜夊埌阌佺殑worker杩涚▼镓崭细𨱍婇啋澶勭悊璇锋眰锛屽叾浠栬繘绋嬩细缁х画绛夊緟锛岀粨钖 timer_solution 閰岖疆镄勬渶澶х殑瓒呮椂镞堕棿缁х画灏濊瘯銮峰彇accept-mutex
I/O 澶岖敤鎺ュ彛链塻elect 鍜 epoll 涓ょ嶆ā鍨嬶纴棣栧厛浠嬬粛涓涓嬭繖涓ょ嶆ā鍨嬬殑镓ц屾柟寮忥细
鐢变簬缃戠粶鍝嶅簲镞堕棿镄勫欢杩熶娇寰楀ぇ閲庑CP杩炴帴澶勪簬闱炴椿璺幂姸镐侊纴浣呜皟鐢╯elect()杩樻槸浼氩 镓链夌殑socket杩涜屼竴娆＄嚎镐ф壂鎻 锛屼细
璋幂敤涓娆epoll_wait()銮峰缑灏辩华鏂囦欢鎻忚堪绗︽椂锛岃繑锲炵殑骞朵笉鏄瀹为檯镄勬弿杩扮︼纴钥屾槸涓涓浠ｈ〃灏辩华鎻忚堪绗︽暟閲忕殑鍊硷纴𨰾垮埌杩欎簺鍊煎幓epoll鎸囧畾镄勪竴涓鏁扮粍涓渚濇″彇寰楃浉搴旀暟閲忕殑鏂囦欢鎻忚堪绗﹀嵆鍙锛岃繖閲屼娇鐢ㄥ唴瀛樻椠灏勶纸mmap锛夋妧链锛 阆垮厤浜嗗嶅埗澶ч噺鏂囦欢鎻忚堪绗﹀甫𨱒ョ殑寮阌銆
鍦╯elect/poll镞朵唬锛屾湇锷″櫒杩涚▼姣忔￠兘鎶婅繖100涓囦釜杩炴帴锻婅瘔镎崭綔绯荤粺(浠庣敤鎴锋佸嶅埗鍙ユ焺鏁版嵁缁撴瀯鍒板唴镙告)锛岃╂搷浣灭郴缁熷唴镙稿幓镆ヨ㈣繖浜涘楁帴瀛椾笂鏄钖︽湁浜嬩欢鍙戠敓锛岃疆璇㈠畬钖庯纴鍐嶅皢鍙ユ焺鏁版嵁澶嶅埗鍒扮敤鎴锋侊纴璁╂湇锷″櫒搴旂敤绋嫔簭杞璇㈠勭悊宸插彂鐢熺殑缃戠粶浜嬩欢锛岃繖涓杩囩▼璧勬簮娑堣楄缉澶э纴锲犳わ纴select/poll涓鑸鍙鑳藉勭悊鍑犲崈镄勫苟鍙戣繛鎺ャ
epoll镄勮捐″拰瀹炵幇涓巗elect瀹屽叏涓嶅悓銆俥poll阃氲繃鍦↙inux鍐呮牳涓鐢宠蜂竴涓绠鏄撶殑鏂囦欢绯荤粺锛屾妸铡熷厛镄剆elect/poll璋幂敤鍒嗘垚浜3涓閮ㄥ垎锛
璋幂敤epoll_create()寤虹珛涓涓猠poll瀵硅薄(鍦╡poll鏂囦欢绯荤粺涓涓鸿繖涓鍙ユ焺瀵硅薄鍒嗛厤璧勬簮)
璋幂敤epoll_ctl钖慹poll瀵硅薄涓娣诲姞杩100涓囦釜杩炴帴镄勫楁帴瀛
璋幂敤epoll_wait鏀堕泦鍙戠敓镄勪簨浠剁殑杩炴帴
鍙闇瑕佸湪杩涚▼钖锷ㄦ椂寤虹珛涓涓猠poll瀵硅薄锛岀劧钖庡湪闇瑕佺殑镞跺椤悜杩欎釜epoll瀵硅薄涓娣诲姞鎴栬呭垹闄よ繛鎺ャ傚悓镞讹纴epoll_wait镄勬晥鐜囦篃闱炲父楂桡纴锲犱负璋幂敤epoll_wait镞讹纴骞舵病链変竴镶¤剳镄勫悜镎崭綔绯荤粺澶嶅埗杩100涓囦釜杩炴帴镄勫彞镆勬暟鎹锛屽唴镙镐篃涓嶉渶瑕佸幓阆嶅巻鍏ㄩ儴镄勮繛鎺ャ
apache 閲囩敤镄剆elect妯″瀷锛宯ginx閲囩敤epoll妯″瀷锛宯ginx 澶勭悊璇锋眰鏄寮傛ラ潪阒诲炵殑锛岃宎pache鍒欐槸阒诲炲瀷镄勶纴鍦ㄩ珮骞跺彂涓媙ginx 鑳戒缭鎸佷绠璧勬簮浣庢秷钥楅珮镐ц兘銆傚湪Apache+PHP锛坧refork锛夋ā寮忎笅锛屽傛灉PHP澶勭悊鎱㈡垨钥呭墠绔铡嫔姏寰埚ぇ镄勬儏鍐典笅锛屽緢瀹规槗鍑虹幇Apache杩涚▼鏁伴椤崌锛屼粠钥屾嫆缁濇湇锷＄殑鐜拌薄銆
Nginx 甯哥敤锷熻兘
鍙傝冩枃绔狅细 http://tengine.taobao.org/book/chapter_02.html
⑶ linux手册翻译——timerfd_create(2)
timerfd_create, timerfd_settime, timerfd_gettime - timers that notify via file descriptors
这些系统调用创建并操作一个计时器，计时器通过文件描述符来通知计时到期，这样就可以通过 select(2)、poll(2) 和 epoll(7) 监视文件描述符从而监听计时器。
这三个系统调用的使用类似于 timer_create(2)、timer_settime(2) 和 timer_gettime(2) 。 （没有与timer_getoverrun(2) 类似的系统调用，因为该功能由 read(2) 提供，如下所述。）
int timerfd_create(int clockid, int flags);
timerfd_create() 创建一个新的计时器对象，并返回引用该计时器的文件描述符。 clockid 参数指定使用那种类型的时钟(clock)来实现计时器(timer)，并且必须是以下之一：
有关上述时钟的更多详细信息，请参阅clock_getres(2)。
可以使用clock_gettime(2) 获取每个时钟的当前值。
从 Linux 2.6.27 开始，可以在标志中对以下值进行厅局轿按位 OR 运算以更改 timerfd_create() 的行为：
在 2.6.26 及包括 2.6.26 的 Linux 版本中，标志必须指定为零。
int timerfd_settime(int fd, int flags, const struct itimerspec *new_value, struct itimerspec *old_value);
timerfd_settime() arms (starts) or disarms (stops) the timer referred to by the file descriptor fd.
new_value 参数指定计时器的初始到期时间和到期间隔（换句话说，计时器开始执行后，将会在到达初始到期时间时报告一次，此后每过一个到期间隔就会报告一次）。 用于此参数的 itimerspec 结构包含两个字段，每个字段又是一个 timespec 类型的结构：
new_value.it_value 指定计时器的初始到期时间，以秒和纳秒为单位。 将 new_value.it_value 的任一字段设置为非零值，即可启动计时器。 将 new_value.it_value 的两个字段都设置为零会解除定时器。
将 new_value.it_interval 的一个或两个字段设置为非零值指定初始到期后重复计时器到期的时间段（以秒和纳秒为单位）。 如果 new_value.it_interval 的两个字段都为零，则计时器仅在 new_value.it_value 指定的时间到期一次。
如果将 new_value 设置为(10S，2S)，即表示，计时器启动后，将会在扮肆10S后报告一次，然后每隔2S报告一次；
如果将 new_value 设置为(10S，0S)，即表示，计时器启动后，将会在10S后报告一次，然后就不再报告了；
如果将 new_value 修改为(0S，0S)，即表示，停止计时。腊枝
默认情况下， new_value 中指定的初始到期时间是相对于调用时计时器时钟上的当前时间的（即，new_value.it_value 是相对于 clockid 指定的时钟的当前值设置的）。 可以通过 flags 参数指定使用绝对时间。
flags 参数是一个位掩码，可以包含以下值：
如果 old_value 参数不为 NULL，则它指向的 itimerspec 结构用于返回调用时当前计时器的设置； 请参阅下面的 timerfd_gettime() 说明。
int timerfd_gettime(int fd, struct itimerspec *curr_value);
timerfd_gettime() 在 curr_value 中返回一个 itimerspec 结构，该结构包含文件描述符 fd 所引用的计时器的当前设置。
it_value 字段返回计时器下一次到期之前的时间量。 如果此结构的两个字段都为零，则定时器当前已解除。 无论在设置计时器时是否指定了 TFD_TIMER_ABSTIME 标志，该字段始终包含一个相对值。
it_interval 字段返回定时器的间隔。 如果此结构的两个字段都为零，则计时器设置为仅在 curr_value.it_value 指定的时间到期一次。
timerfd_create() 返回的文件描述符支持以下附加操作：
在 fork(2) 之后，子进程继承了 timerfd_create() 创建的文件描述符的副本。 文件描述符引用与父级中相应文件描述符相同的底层计时器对象，子级中的 read(2) 将返回有关计时器到期的信息。
A file descriptor created by timerfd_create() is preserved across execve(2), and continues to generate timer expirations if the timer was armed.
成功时， timerfd_create() 返回一个新的文件描述符。 出错时，返回 -1 并设置 errno 以指示错误。
timerfd_settime() 和 timerfd_gettime() 成功返回 0； 出错时返回 -1，并设置 errno 以指示错误。
timerfd_create() can fail with the following errors:
timerfd_settime() and timerfd_gettime() can fail with the following errors:
timerfd_settime() can also fail with the following errors:
These system calls are available on Linux since kernel 2.6.25.
Library support is provided by glibc since version 2.8.
These system calls are Linux-specific.
假设在使用 timerfd_create() 创建的 CLOCK_REALTIME 或 CLOCK_REALTIME_ALARM 计时器时，发生以下场景：
在这种情况下，会发生以下情况：
目前，timerfd_create() 支持的时钟 ID 类型少于 timer_create(2)。
以下程序创建一个 基于实时时钟的绝对时间 的计时器，然后监控其进度。 该程序最多接受三个命令行参数。 第一个参数指定计时器初始到期的秒数。 第二个参数指定计时器的间隔，以秒为单位。 第三个参数指定程序在终止前应允许计时器到期的次数。 第二个和第三个命令行参数是可选的。
以下 shell 会话演示了该程序的使用：
⑷ 如何看懂《Linux多线程服务端编程
一：进程和线程
每个进程有自己独立的地址空间。“在同一个进程”还是“不在同一个进程”是系统功能划分的重要决策点。《Erlang程序设计》[ERL]把进程比喻为人：
每个人有自己的记忆（内存），人与人通过谈话（消息传递）来交流，谈话既可以是面谈（同一台服务器），也可以在电话里谈（不同的服务器，有网络通信）。面谈和电话谈的区别在于，面谈可以立即知道对方是否死了（crash,SIGCHLD），而电话谈只能通过周期性的心跳来判断对方是否还活着。
有了这些比喻，设计分布式系统时可以采取“角色扮演”，团队里的几个人各自扮演一个进程，人的角色由进程的代码决定（管登录的、管消息分发的、管买卖的等等）。每个人有自己的记忆，但不知道别人的记忆，要想知道别人的看法，只能通过交谈（暂不考虑共享内存这种IPC）。然后就可以思考：
·容错：万一有人突然死了
·扩容：新人中途加进来
·负载均衡：把甲的活儿挪给乙做
·退休：甲要修复bug，先别派新任务，等他做完手上的事情就把他重启
等等各种场景，十分便利。
线程的特点是共享地址空间，从而可以高效地共享数据。一台机器上的多个进程能高效地共享代码段(操作系统可以映射为同样的物理内存)，但不能共享数据。如果多个进程大量共享内存，等于是把多进程程序当成多线程来写，掩耳盗铃。
“多线程”的价值，我认为是为了更好地发挥多核处理器(multi-cores)的效能。在单核时代，多线程没有多大价值（个人想法：如果要完成的任务是CPU密集型的，那多线程没有优势，甚至因为线程切换的开销，多线程反而更慢；如果要完成的任务既有CPU计算，又有磁盘或网络IO，则使用多线程的好处是，当某个线程因为IO而阻塞时，OS可以调度其他线程执行，虽然效率确实要比任务的顺序执行效率要高，然而，这种类型的任务，可以通过单线程的”non-blocking IO+IO multiplexing”的模型（事件驱动）来提高效率，采用多线程的方式，带来的可能仅仅是编程上的简单而已）。Alan Cox说过：”A computer is a state machine.Threads are for people who can’t program state machines.”（计算机是一台状态机。线程是给那些不能编写状态机程序的人准备的）如果只有一块CPU、一个执行单元，那么确实如Alan Cox所说，按状态机的思路去写程序是最高效的。
二：单线程服务器的常用编程模型
据我了解，在高性能的网络程序中，使用得最为广泛的恐怕要数”non-blocking IO + IO multiplexing”这种模型，即Reactor模式。
在”non-blocking IO + IO multiplexing”这种模型中，程序的基本结构是一个事件循环（event loop），以事件驱动（event-driven）和事件回调的方式实现业务逻辑：
[cpp] view plain
//代码仅为示意，没有完整考虑各种情况
while(!done)
{
int timeout_ms = max(1000, getNextTimedCallback());
int retval = poll(fds, nfds, timeout_ms);
if (retval<0){
处理错误，回调用户的error handler
}else{
处理到期的timers,回调用户的timer handler
if(retval>0){
处理IO事件，回调用户的IO event handler
}
}
}
这里select(2)/poll(2)有伸缩性方面的不足（描述符过多时，效率较低），Linux下可替换为epoll(4)，其他操作系统也有对应的高性能替代品。
Reactor模型的优点很明显，编程不难，效率也不错。不仅可以用于读写socket，连接的建立(connect(2)/accept(2))，甚至DNS解析都可以用非阻塞方式进行，以提高并发度和吞吐量(throughput)，对于IO密集的应用是个不错的选择。lighttpd就是这样，它内部的fdevent结构十分精妙，值得学习。
基于事件驱动的编程模型也有其本质的缺点，它要求事件回调函数必须是非阻塞的。对于涉及网络IO的请求响应式协议，它容易割裂业务逻辑，使其散布于多个回调函数之中，相对不容易理解和维护。
三：多线程服务器的常用编程模型
大概有这么几种：
a：每个请求创建一个线程，使用阻塞式IO操作。在Java 1.4引人NIO之前，这是Java网络编程的推荐做法。可惜伸缩性不佳（请求太多时，操作系统创建不了这许多线程）。
b：使用线程池，同样使用阻塞式IO操作。与第1种相比，这是提高性能的措施。
c：使用non-blocking IO + IO multiplexing。即Java NIO的方式。
d：Leader/Follower等高级模式。
在默认情况下，我会使用第3种，即non-blocking IO + one loop per thread模式来编写多线程C++网络服务程序。
1：one loop per thread
此种模型下，程序里的每个IO线程有一个event loop，用于处理读写和定时事件（无论周期性的还是单次的）。代码框架跟“单线程服务器的常用编程模型”一节中的一样。
libev的作者说：
One loop per thread is usually a good model. Doing this is almost never wrong, some times a better-performance model exists, but it is always a good start.
这种方式的好处是：
a：线程数目基本固定，可以在程序启动的时候设置，不会频繁创建与销毁。
b：可以很方便地在线程间调配负载。
c：IO事件发生的线程是固定的，同一个TCP连接不必考虑事件并发。
Event loop代表了线程的主循环，需要让哪个线程干活，就把timer或IO channel（如TCP连接）注册到哪个线程的loop里即可：对实时性有要求的connection可以单独用一个线程；数据量大的connection可以独占一个线程，并把数据处理任务分摊到另几个计算线程中（用线程池）；其他次要的辅助性connections可以共享一个线程。
比如，在dbproxy中，一个线程用于专门处理客户端发来的管理命令；一个线程用于处理客户端发来的MySQL命令，而与后端数据库通信执行该命令时，是将该任务分配给所有事件线程处理的。
对于non-trivial（有一定规模）的服务端程序，一般会采用non-blocking IO + IO multiplexing，每个connection/acceptor都会注册到某个event loop上，程序里有多个event loop，每个线程至多有一个event loop。
多线程程序对event loop提出了更高的要求，那就是“线程安全”。要允许一个线程往别的线程的loop里塞东西，这个loop必须得是线程安全的。
在dbproxy中，线程向其他线程分发任务，是通过管道和队列实现的。比如主线程accept到连接后，将表示该连接的结构放入队列，并向管道中写入一个字节。计算线程在自己的event loop中注册管道的读事件，一旦有数据可读，就尝试从队列中取任务。
2：线程池
不过，对于没有IO而光有计算任务的线程，使用event loop有点浪费。可以使用一种补充方案，即用blocking queue实现的任务队列：
[cpp] view plain
typedef boost::function<void()>Functor;
BlockingQueue<Functor> taskQueue; //线程安全的全局阻塞队列
//计算线程
void workerThread()
{
while (running) //running变量是个全局标志
{
Functor task = taskQueue.take(); //this blocks
task(); //在产品代码中需要考虑异常处理
}
}
// 创建容量（并发数）为N的线程池
int N = num_of_computing_threads;
for (int i = 0; i < N; ++i)
{
create_thread(&workerThread); //启动线程
}
//向任务队列中追加任务
Foo foo; //Foo有calc()成员函数
boost::function<void()> task = boost::bind(&Foo::calc，&foo);
taskQueue.post(task);
除了任务队列，还可以用BlockingQueue<T>实现数据的生产者消费者队列，即T是数据类型而非函数对象，queue的消费者从中拿到数据进行处理。其实本质上是一样的。
3：总结
总结而言，我推荐的C++多线程服务端编程模式为：one (event) loop per thread + thread pool：
event loop用作IO multiplexing，配合non-blockingIO和定时器；
thread pool用来做计算，具体可以是任务队列或生产者消费者队列。
以这种方式写服务器程序，需要一个优质的基于Reactor模式的网络库来支撑，muo正是这样的网络库。比如dbproxy使用的是libevent。
程序里具体用几个loop、线程池的大小等参数需要根据应用来设定，基本的原则是“阻抗匹配”（解释见下），使得CPU和IO都能高效地运作。所谓阻抗匹配原则：
如果池中线程在执行任务时，密集计算所占的时间比重为 P (0 < P <= 1)，而系统一共有 C 个 CPU，为了让这 C 个 CPU 跑满而又不过载，线程池大小的经验公式 T = C/P。（T 是个 hint，考虑到 P 值的估计不是很准确，T 的最佳值可以上下浮动 50%）
以后我再讲这个经验公式是怎么来的，先验证边界条件的正确性。
假设 C = 8，P = 1.0，线程池的任务完全是密集计算，那么T = 8。只要 8 个活动线程就能让 8 个 CPU 饱和，再多也没用，因为 CPU 资源已经耗光了。
假设 C = 8，P = 0.5，线程池的任务有一半是计算，有一半等在 IO 上，那么T = 16。考虑操作系统能灵活合理地调度 sleeping/writing/running 线程，那么大概 16 个“50%繁忙的线程”能让 8 个 CPU 忙个不停。启动更多的线程并不能提高吞吐量，反而因为增加上下文切换的开销而降低性能。
如果 P < 0.2，这个公式就不适用了，T 可以取一个固定值，比如 5*C。
另外，公式里的 C 不一定是 CPU 总数，可以是“分配给这项任务的 CPU 数目”，比如在 8 核机器上分出 4 个核来做一项任务，那么 C=4。
四：进程间通信只用TCP
Linux下进程间通信的方式有：匿名管道(pipe)、具名管道(FIFO)、POSIX消息队列、共享内存、信号(signals)，以及Socket。同步原语有互斥器(mutex)、条件变量(condition variable)、读写锁(reader-writer lock)、文件锁(record locking)、信号量(semaphore)等等。
进程间通信我首选Sockets（主要指TCP，我没有用过UDP，也不考虑Unix domain协议）。其好处在于：
可以跨主机，具有伸缩性。反正都是多进程了，如果一台机器的处理能力不够，很自然地就能用多台机器来处理。把进程分散到同一局域网的多台机器上，程序改改host:port配置就能继续用；
TCP sockets和pipe都是操作文件描述符，用来收发字节流，都可以read/write/fcntl/select/poll等。不同的是，TCP是双向的，Linux的pipe是单向的，进程间双向通信还得开两个文件描述符，不方便；而且进程要有父子关系才能用pipe，这些都限制了pipe的使用；
TCP port由一个进程独占，且进程退出时操作系统会自动回收文件描述符。因此即使程序意外退出，也不会给系统留下垃圾，程序重启之后能比较容易地恢复，而不需要重启操作系统（用跨进程的mutex就有这个风险）；而且，port是独占的，可以防止程序重复启动，后面那个进程抢不到port，自然就没法初始化了，避免造成意料之外的结果；
与其他IPC相比，TCP协议的一个天生的好处是“可记录、可重现”。tcpmp和Wireshark是解决两个进程间协议和状态争端的好帮手，也是性能（吞吐量、延迟）分析的利器。我们可以借此编写分布式程序的自动化回归测试。也可以用tcp之类的工具进行压力测试。TCP还能跨语言，服务端和客户端不必使用同一种语言。
分布式系统的软件设计和功能划分一般应该以“进程”为单位。从宏观上看，一个分布式系统是由运行在多台机器上的多个进程组成的，进程之间采用TCP长连接通信。
使用TCP长连接的好处有两点：一是容易定位分布式系统中的服务之间的依赖关系。只要在机器上运行netstat -tpna|grep <port>就能立刻列出用到某服务的客户端地址（Foreign Address列），然后在客户端的机器上用netstat或lsof命令找出是哪个进程发起的连接。TCP短连接和UDP则不具备这一特性。二是通过接收和发送队列的长度也较容易定位网络或程序故障。在正常运行的时候，netstat打印的Recv-Q和Send-Q都应该接近0，或者在0附近摆动。如果Recv-Q保持不变或持续增加，则通常意味着服务进程的处理速度变慢，可能发生了死锁或阻塞。如果Send-Q保持不变或持续增加，有可能是对方服务器太忙、来不及处理，也有可能是网络中间某个路由器或交换机故障造成丢包，甚至对方服务器掉线，这些因素都可能表现为数据发送不出去。通过持续监控Recv-Q和Send-Q就能及早预警性能或可用性故障。以下是服务端线程阻塞造成Recv-Q和客户端Send-Q激增的例子：
[cpp] view plain
$netstat -tn
Proto Recv-Q Send-Q Local Address Foreign
tcp 78393 0 10.0.0.10:2000 10.0.0.10:39748 #服务端连接
tcp 0 132608 10.0.0.10:39748 10.0.0.10:2000 #客户端连接
tcp 0 52 10.0.0.10:22 10.0.0.4:55572
五：多线程服务器的适用场合
如果要在一台多核机器上提供一种服务或执行一个任务，可用的模式有：
a：运行一个单线程的进程；
b：运行一个多线程的进程；
c：运行多个单线程的进程；
d：运行多个多线程的进程；
考虑这样的场景：如果使用速率为50MB/s的数据压缩库，进程创建销毁的开销是800微秒，线程创建销毁的开销是50微秒。如何执行压缩任务？
如果要偶尔压缩1GB的文本文件，预计运行时间是20s，那么起一个进程去做是合理的，因为进程启动和销毁的开销远远小于实际任务的耗时。
如果要经常压缩500kB的文本数据，预计运行时间是10ms，那么每次都起进程 似乎有点浪费了，可以每次单独起一个线程去做。
如果要频繁压缩10kB的文本数据，预计运行时间是200微秒，那么每次起线程似 乎也很浪费，不如直接在当前线程搞定。也可以用一个线程池，每次把压缩任务交给线程池，避免阻塞当前线程（特别要避免阻塞IO线程）。
由此可见，多线程并不是万灵丹(silver bullet)。
1：必须使用单线程的场合
据我所知，有两种场合必须使用单线程：
a：程序可能会fork(2)；
实际编程中，应该保证只有单线程程序能进行fork(2)。多线程程序不是不能调用fork(2)，而是这么做会遇到很多麻烦：
fork一般不能在多线程程序中调用，因为Linux的fork只克隆当前线程的thread of control，不可隆其他线程。fork之后，除了当前线程之外，其他线程都消失了。
这就造成一种危险的局面。其他线程可能正好处于临界区之内，持有了某个锁，而它突然死亡，再也没有机会去解锁了。此时如果子进程试图再对同一个mutex加锁，就会立即死锁。因此，fork之后，子进程就相当于处于signal handler之中（因为不知道调用fork时，父进程中的线程此时正在调用什么函数，这和信号发生时的场景一样），你不能调用线程安全的函数（除非它是可重入的），而只能调用异步信号安全的函数。比如，fork之后，子进程不能调用：
malloc，因为malloc在访问全局状态时几乎肯定会加锁；
任何可能分配或释放内存的函数，比如snprintf；
任何Pthreads函数；
printf系列函数，因为其他线程可能恰好持有stdout/stderr的锁；
除了man 7 signal中明确列出的信号安全函数之外的任何函数。
因此，多线程中调用fork，唯一安全的做法是fork之后，立即调用exec执行另一个程序，彻底隔断子进程与父进程的联系。
在多线程环境中调用fork，产生子进程后。子进程内部只存在一个线程，也就是父进程中调用fork的线程的副本。
使用fork创建子进程时，子进程通过继承整个地址空间的副本，也从父进程那里继承了所有互斥量、读写锁和条件变量的状态。如果父进程中的某个线程占有锁，则子进程同样占有这些锁。问题是子进程并不包含占有锁的线程的副本，所以子进程没有办法知道它占有了哪些锁，并且需要释放哪些锁。
尽管Pthread提供了pthread_atfork函数试图绕过这样的问题，但是这回使得代码变得混乱。因此《Programming With Posix Threads》一书的作者说：”Avoid using fork in threaded code except where the child process will immediately exec a new program.”。
b：限制程序的CPU占用率；
这个很容易理解，比如在一个8核的服务器上，一个单线程程序即便发生busy-wait，占满1个core，其CPU使用率也只有12.5%，在这种最坏的情况下，系统还是有87.5%的计算资源可供其他服务进程使用。
因此对于一些辅助性的程序，如果它必须和主要服务进程运行在同一台机器的话，那么做成单线程的能避免过分抢夺系统的计算资源。