簡(jiǎn)介一份基于Linux平臺(tái)、使用C語(yǔ)言實(shí)現(xiàn)的局域網(wǎng)聊天室源碼包面向網(wǎng)絡(luò)編程初學(xué)者以及課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)的學(xué)生演示如何通過(guò)TCP/IP與多線程機(jī)制構(gòu)建一個(gè)小型局域網(wǎng)聊天服務(wù)。源碼采用客戶(hù)端與服務(wù)器分離模式完整實(shí)現(xiàn)消息群發(fā)、歷史數(shù)據(jù)查詢(xún)、好友列表管理、好友上下線提醒等常用功能其中涉及套接字通信、多客戶(hù)端并發(fā)處理、在線狀態(tài)廣播、聊天記錄存儲(chǔ)與檢索等關(guān)鍵知識(shí)點(diǎn)兼具可讀性與可擴(kuò)展性。壓縮包共七個(gè)文件主要包括三個(gè)C源文件、一個(gè)頭文件、一個(gè)Makefile構(gòu)建腳本、一份txt說(shuō)明文檔以及一份docx版程序設(shè)計(jì)文檔整體大小僅六十四KB內(nèi)容精煉解壓后可直接閱讀和編譯。附帶的設(shè)計(jì)文檔能幫助理解各模塊的設(shè)計(jì)思路便于對(duì)照源碼深入調(diào)試與二次開(kāi)發(fā)。目前已有100人學(xué)習(xí)下載適合通過(guò)實(shí)際項(xiàng)目掌握Linux網(wǎng)絡(luò)編程、多線程協(xié)作以及基礎(chǔ)協(xié)議應(yīng)用并可根據(jù)需要進(jìn)一步添加私聊、文件傳輸?shù)刃鹿δ堋?. 從Socket到聊天室為什么這個(gè)項(xiàng)目值得動(dòng)手拆一遍不少人在學(xué)完Linux網(wǎng)絡(luò)編程后卡在同一個(gè)地方read函數(shù)會(huì)阻塞、write返回值不檢查、多線程下共享變量亂改這些零散知識(shí)點(diǎn)單獨(dú)看都能理解一拼成完整的聊天室就四處漏風(fēng)。這個(gè)基于Linux使用C語(yǔ)言實(shí)現(xiàn)的局域網(wǎng)聊天室源碼恰好把網(wǎng)絡(luò)編程的核心鏈路串起來(lái)了——TCP連接管理、多線程并發(fā)、消息廣播、歷史記錄落盤(pán)、上下線狀態(tài)通知。它不做花哨的界面全部走終端交互反而能讓注意力集中在數(shù)據(jù)傳輸和處理邏輯上。適合剛啃完APUE卷socket章節(jié)的學(xué)生也適合想快速回顧select/poll之前那套經(jīng)典多線程模型的在職開(kāi)發(fā)。配套的docx文檔把設(shè)計(jì)思路寫(xiě)得很直白源代碼結(jié)構(gòu)簡(jiǎn)單到可以直接從頭讀完改造成自己項(xiàng)目的通信底層也非常方便。下面我按實(shí)際拆源碼的順序把協(xié)議設(shè)計(jì)、服務(wù)器端并發(fā)模型、客戶(hù)端交互和歷史查詢(xún)這幾塊逐一說(shuō)明。2. TCP選型、數(shù)據(jù)幀格式與多線程模型2.1 為什么局域網(wǎng)即時(shí)通訊首選TCP而非UDP聊天室最基礎(chǔ)的需求是“消息不能丟”。UDP雖然省去了握手和?；畹穆闊┑钟蚓W(wǎng)環(huán)境下的丟包率雖然低客戶(hù)端突然掉線時(shí)UDP根本無(wú)從感知服務(wù)器維護(hù)在線列表會(huì)變得十分不可靠。TCP提供的流式傳輸和連接狀態(tài)檢測(cè)能讓服務(wù)器立刻通過(guò)read返回0或errno發(fā)現(xiàn)對(duì)端關(guān)閉這是實(shí)現(xiàn)“好友上下線提醒”的前提。另一個(gè)原因是代碼復(fù)雜度TCP的accept、recv、send接口更直觀多線程模型下每個(gè)連接一個(gè)fd邏輯邊界清晰。如果你練習(xí)過(guò)UDP的sendto循環(huán)就知道要在業(yè)務(wù)層自己實(shí)現(xiàn)確認(rèn)和重傳那工作量已經(jīng)接近重寫(xiě)一個(gè)迷你TCP了。局域網(wǎng)場(chǎng)景下帶寬充足TCP頭部開(kāi)銷(xiāo)幾乎不影響體驗(yàn)所以這個(gè)項(xiàng)目選TCP是合理且務(wù)實(shí)的。2.2 自定義協(xié)議幀消息頭和消息體分離源碼中的common.h定義了通信雙方約定的報(bào)文格式這是整個(gè)聊天室的技術(shù)地基。協(xié)議設(shè)計(jì)為固定長(zhǎng)度頭部加上變長(zhǎng)消息體避免粘包和半包。#define MSG_MAX_LEN 1024 #define NAME_MAX_LEN 32 typedef enum { MSG_TYPE_BROADCAST 1, // 群發(fā)消息 MSG_TYPE_HISTORY, // 歷史記錄請(qǐng)求/響應(yīng) MSG_TYPE_ONLINE_LIST, // 在線列表查詢(xún) MSG_TYPE_LOGIN, // 登錄通知 MSG_TYPE_LOGOUT, // 退出通知 MSG_TYPE_PRIVATE // 預(yù)留的私聊消息 } msg_type_t; typedef struct { int type; // 消息類(lèi)型見(jiàn)msg_type_t int from_len; // 發(fā)送者名字長(zhǎng)度 int body_len; // 消息體長(zhǎng)度 } msg_header_t; typedef struct { msg_header_t header; char from[NAME_MAX_LEN]; // 發(fā)送者名字 char body[MSG_MAX_LEN]; // 消息內(nèi)容 } chat_message_t;頭部的三個(gè)int字段用定長(zhǎng)方式傳輸接收方先讀滿12字節(jié)的msg_header_t再?gòu)膄rom_len和body_len得知后續(xù)需要讀取多少字節(jié)。這種設(shè)計(jì)的好處是解析時(shí)不需要掃描整個(gè)數(shù)據(jù)流找分隔符效率高也不會(huì)誤拆中文內(nèi)容。注意msg_header_t沒(méi)有使用#pragma pack或__attribute__((packed))這是因?yàn)樵诰W(wǎng)絡(luò)傳輸中發(fā)送方和接收方可能在不同的Linux發(fā)行版上編譯結(jié)構(gòu)體默認(rèn)對(duì)齊可能產(chǎn)生額外填充字節(jié)。更穩(wěn)妥的做法是像項(xiàng)目里這樣把各字段單獨(dú)發(fā)送或者將頭部字段統(tǒng)一為網(wǎng)絡(luò)字節(jié)序的uint32_t。我在自己的代碼里會(huì)額外增加一個(gè)magic字段用于校驗(yàn)防止把錯(cuò)誤的數(shù)據(jù)流當(dāng)成消息處理。2.3 多線程與多進(jìn)程的選擇客戶(hù)端連接處理項(xiàng)目采用一連接一線程thread-per-connection模型服務(wù)器主線程執(zhí)行accept循環(huán)每接受一個(gè)新的客戶(hù)端連接就創(chuàng)建一個(gè)pthread_t線程專(zhuān)門(mén)處理該連接。相比f(wàn)ork子進(jìn)程線程共享進(jìn)程地址空間操作同一份在線鏈表和消息計(jì)數(shù)不需要借助IPC直接加鎖讀寫(xiě)即可。代價(jià)是一個(gè)線程棧默認(rèn)約8MB如果客戶(hù)端數(shù)量達(dá)到數(shù)百虛擬內(nèi)存壓力會(huì)比較大。對(duì)于局域網(wǎng)聊天室這種幾十人量級(jí)的場(chǎng)景這是最清晰的并發(fā)方案。void *client_handler(void *arg) { int client_fd *(int *)arg; char peer_ip[INET_ADDRSTRLEN]; // ... 獲取客戶(hù)端IP加入在線列表 ... chat_message_t msg; while (1) { memset(msg, 0, sizeof(msg)); // 分兩次讀取先讀頭再讀體 if (recv(client_fd, msg.header, sizeof(msg.header), 0) 0) break; if (recv(client_fd, msg.from, msg.header.from_len, 0) 0) break; if (recv(client_fd, msg.body, msg.header.body_len, 0) 0) break; handle_message(client_fd, msg); // 根據(jù)type分發(fā)處理 } remove_client(client_fd); pthread_detach(pthread_self()); close(client_fd); return NULL; }recv三次變長(zhǎng)讀取減少了粘包概率但沒(méi)完全解決如果網(wǎng)絡(luò)出現(xiàn)半包第二次recv可能只收到一部分。嚴(yán)謹(jǐn)?shù)膶?xiě)法是循環(huán)讀取直到收滿所需字節(jié)我在改進(jìn)時(shí)會(huì)封裝一個(gè)readn函數(shù)。另外需要注意線程參數(shù)arg指向的client_fd是棧上變量所以建議用堆上分配的方式傳參否則主線程繼續(xù)循環(huán)時(shí)可能修改同一塊內(nèi)存。源碼里用malloc分配新fd副本再傳入這點(diǎn)值得學(xué)習(xí)。3. 服務(wù)器端消息群發(fā)、在線列表與上下線通知3.1 服務(wù)器核心數(shù)據(jù)結(jié)構(gòu)與鎖維護(hù)在線客戶(hù)端需要一張全局鏈表每個(gè)節(jié)點(diǎn)保存fd、昵稱(chēng)、IP等。由于多線程同時(shí)讀寫(xiě)這張表必須用互斥鎖保護(hù)。源碼中在clientlist.c里實(shí)現(xiàn)了這個(gè)結(jié)構(gòu)插入和刪除都封裝成獨(dú)立函數(shù)。typedef struct client_node { int fd; char name[NAME_MAX_LEN]; struct sockaddr_in addr; struct client_node *next; } client_node_t; static client_node_t *head NULL; static pthread_mutex_t clients_mutex PTHREAD_MUTEX_INITIALIZER; void add_client(client_node_t *node) { pthread_mutex_lock(clients_mutex); node-next head; head node; pthread_mutex_unlock(clients_mutex); } void remove_client(int fd) { pthread_mutex_lock(clients_mutex); client_node_t *cur head, *prev NULL; while (cur) { if (cur-fd fd) { if (prev) prev-next cur-next; else head cur-next; free(cur); break; } prev cur; cur cur-next; } pthread_mutex_unlock(clients_mutex); }加鎖粒度要控制好。很多新手會(huì)把整個(gè)廣播循環(huán)也放在鎖內(nèi)導(dǎo)致一次慢客戶(hù)端拖住所有發(fā)送。正確做法是在遍歷時(shí)先鎖住鏈表然后逐個(gè)取出fd并調(diào)用sendsend是阻塞操作可能耗時(shí)長(zhǎng)所以應(yīng)該在取到fd后盡快解鎖。比較穩(wěn)妥的方式是用引用計(jì)數(shù)或淺拷貝的方式拿一份fd數(shù)組出來(lái)然后釋放鎖再執(zhí)行send。3.2 消息廣播與上下線提醒的實(shí)現(xiàn)廣播函數(shù)遍歷所有在線節(jié)點(diǎn)將收到的消息原樣轉(zhuǎn)發(fā)給除自己外的其他客戶(hù)端。上下線提醒本質(zhì)上是廣播一條特殊類(lèi)型的系統(tǒng)消息只是消息體寫(xiě)的是“xx上線了”。void broadcast_message(chat_message_t *msg, int sender_fd) { pthread_mutex_lock(clients_mutex); client_node_t *cur head; while (cur) { if (cur-fd ! sender_fd) { ssize_t sent send(cur-fd, msg, sizeof(*msg), 0); if (sent -1) { // 發(fā)送失敗通常會(huì)走到remove_client流程 perror(send error); } } cur cur-next; } pthread_mutex_unlock(clients_mutex); } void notify_status(const char *name, int online) { chat_message_t sys_msg; memset(sys_msg, 0, sizeof(sys_msg)); sys_msg.header.type online ? MSG_TYPE_LOGIN : MSG_TYPE_LOGOUT; sys_msg.header.from_len strlen(name); snprintf(sys_msg.body, sizeof(sys_msg.body), %s, online ? 上線了 : 下線了); sys_msg.header.body_len strlen(sys_msg.body); strncpy(sys_msg.from, name, NAME_MAX_LEN); broadcast_message(sys_msg, -1); }注意broadcast_message用sender_fd -1來(lái)表示系統(tǒng)廣播這樣所有客戶(hù)端都會(huì)收到。上下線提醒應(yīng)該在客戶(hù)端加入鏈表之前發(fā)送還是之后發(fā)送如果先發(fā)通知再插入鏈表其他客戶(hù)端無(wú)法看到這位新用戶(hù)因?yàn)榘l(fā)送通知時(shí)他還沒(méi)在列表里。正確順序是先插入鏈表再?gòu)V播上線的同時(shí)廣播一份在線列表給所有客戶(hù)端。這樣收到上線通知的客戶(hù)端可以主動(dòng)向新用戶(hù)問(wèn)好而新用戶(hù)也能立刻拿到完整的成員名單。源碼main.c里就是按這個(gè)順序處理的。3.3 歷史數(shù)據(jù)查詢(xún)的服務(wù)端存儲(chǔ)策略源碼將聊天記錄保存在一個(gè)普通文本文件chat.log中。每個(gè)廣播或私聊消息在轉(zhuǎn)發(fā)的同時(shí)同步追加寫(xiě)入文件。查詢(xún)歷史時(shí)客戶(hù)端發(fā)送MSG_TYPE_HISTORY類(lèi)型消息服務(wù)器打開(kāi)文件讀出全部?jī)?nèi)容通過(guò)send返回給客戶(hù)端。寫(xiě)入時(shí)要注意多線程寫(xiě)文件的原子性。兩個(gè)線程同時(shí)調(diào)用write到同一文件描述符如果消息長(zhǎng)度不超過(guò)PIPE_BUFLinux下4096字節(jié)內(nèi)核會(huì)保證write系統(tǒng)調(diào)用是原子的。這里每條消息通常不到幾百字節(jié)所以直接用write追加問(wèn)題不大。更穩(wěn)妥的做法是給文件寫(xiě)操作單獨(dú)加一把鎖或讓所有寫(xiě)入集中在專(zhuān)門(mén)的日志線程。我建議在關(guān)鍵函數(shù)里加鎖因?yàn)槿绻褀rite放在broadcast的循環(huán)里廣播期間的任何失敗都會(huì)影響寫(xiě)日志。void append_history(chat_message_t *msg) { FILE *fp fopen(chat.log, a); if (!fp) { perror(fopen chat.log); return; } fprintf(fp, [%ld] %s: %s\n, time(NULL), msg-from, msg-body); fclose(fp); }每次打開(kāi)和關(guān)閉文件會(huì)有開(kāi)銷(xiāo)但對(duì)聊天室這種低頻寫(xiě)入完全可接受。開(kāi)發(fā)環(huán)境里用fopen/fclose能保證數(shù)據(jù)立即落盤(pán)避免緩沖區(qū)滯留。查詢(xún)時(shí)使用fgets逐行讀取并拼接通過(guò)send一次性或分段發(fā)送給請(qǐng)求者。還記得MSG_MAX_LEN為1024嗎如果歷史文件超過(guò)這個(gè)長(zhǎng)度服務(wù)器端要拆包發(fā)送客戶(hù)端則需要循環(huán)接收。源碼里直接用了定長(zhǎng)數(shù)組返回這個(gè)在長(zhǎng)聊天記錄下會(huì)截?cái)辔覍?shí)測(cè)后把發(fā)送邏輯改成了按行拆包。4. 客戶(hù)端實(shí)現(xiàn)交互線程、好友列表與本地記錄4.1 客戶(hù)端主流程與雙線程結(jié)構(gòu)客戶(hù)端程序main.c的主函數(shù)邏輯清晰創(chuàng)建socket、connect到服務(wù)器、啟動(dòng)接收線程處理來(lái)自服務(wù)器的數(shù)據(jù)同時(shí)主線程循環(huán)讀取用戶(hù)輸入并發(fā)送。接收線程的存在是為了及時(shí)處理廣播消息、上下線提醒、在線列表更新等異步事件避免用戶(hù)正輸入時(shí)錯(cuò)過(guò)消息。void *recv_thread(void *arg) { int sock_fd *(int *)arg; chat_message_t msg; while (1) { int n recv(sock_fd, msg, sizeof(msg), 0); if (n 0) { printf(服務(wù)器連接已斷開(kāi)\n); exit(EXIT_FAILURE); } switch (msg.header.type) { case MSG_TYPE_BROADCAST: printf(\n[%s] %s\n, msg.from, msg.body); break; case MSG_TYPE_ONLINE_LIST: printf(當(dāng)前在線用戶(hù)\n%s\n, msg.body); break; case MSG_TYPE_LOGIN: printf( %s 上線了\n, msg.from); break; case MSG_TYPE_LOGOUT: printf( %s 下線了\n, msg.from); break; case MSG_TYPE_HISTORY: printf(-----歷史記錄-----\n%s\n, msg.body); break; default: break; } printf( ); fflush(stdout); } return NULL; }注意接收線程里printf之后要重新打印提示符并刷新stdout否則用戶(hù)正在輸入的內(nèi)容會(huì)和消息混在一起。這里有個(gè)小技巧在printf消息前輸出換行消息結(jié)束后再打印“ ”提示符并fflush這樣即使主線程正在等待輸入用戶(hù)也能看到新消息插入且自己的輸入內(nèi)容不會(huì)被沖掉。真正的控制臺(tái)聊天室還會(huì)加ncurses庫(kù)做獨(dú)立輸入?yún)^(qū)但這個(gè)項(xiàng)目的終端交互方式對(duì)學(xué)習(xí)socket更友好。4.2 好友列表查看與上下線狀態(tài)維護(hù)服務(wù)器返回在線列表的方式有兩種一種是指令觸發(fā)時(shí)服務(wù)器遍歷鏈表拼裝字符串另一種是每次客戶(hù)端登錄或退出時(shí)服務(wù)器主動(dòng)推送最新列表。源碼采用后者好處是客戶(hù)端無(wú)需主動(dòng)請(qǐng)求就能維持較新的好友狀態(tài)視圖?？蛻?hù)端側(cè)只需要在收到MSG_TYPE_ONLINE_LIST時(shí)用strtok按換行符拆分然后更新本地的一個(gè)char online_names[][NAME_MAX_LEN]數(shù)組即可。void update_online_list(const char *data) { memset(online_names, 0, sizeof(online_names)); online_count 0; char tmp[MSG_MAX_LEN]; strncpy(tmp, data, sizeof(tmp) - 1); char *token strtok(tmp, \n); while (token online_count MAX_CLIENTS) { strncpy(online_names[online_count], token, NAME_MAX_LEN - 1); token strtok(NULL, \n); } }注意strtok會(huì)修改原字符串所以必須先復(fù)制一份data。判斷一個(gè)好友是否在線只需遍歷online_names下線則意味著列表中沒(méi)有對(duì)應(yīng)名字。這個(gè)設(shè)計(jì)不需要客戶(hù)端維護(hù)好友關(guān)系數(shù)據(jù)庫(kù)一切以服務(wù)器廣播的列表為準(zhǔn)屬于無(wú)狀態(tài)模式。壞處是如果客戶(hù)端錯(cuò)過(guò)了某次列表推送會(huì)導(dǎo)致?tīng)顟B(tài)不準(zhǔn)確所以還需要一個(gè)主動(dòng)查詢(xún)指令也就是發(fā)送MSG_TYPE_ONLINE_LIST請(qǐng)求。4.3 歷史記錄查詢(xún)與本地文件緩存客戶(hù)端發(fā)送查詢(xún)請(qǐng)求時(shí)直接把MSG_TYPE_HISTORY類(lèi)型的空消息發(fā)給服務(wù)器服務(wù)器就返回整個(gè)聊天日志。這里要處理網(wǎng)絡(luò)傳輸長(zhǎng)度不穩(wěn)定的情況所以客戶(hù)端的接收邏輯不能只依賴(lài)一次recv。我用如下循環(huán)處理可能的多段響應(yīng)void request_history(int sock_fd) { chat_message_t req; memset(req, 0, sizeof(req)); req.header.type MSG_TYPE_HISTORY; send(sock_fd, req, sizeof(req.header), 0); char buf[MSG_MAX_LEN]; int total 0; int n; while ((n recv(sock_fd, buf total, sizeof(buf) - total - 1, 0)) 0) { total n; if (total sizeof(buf) - 1 || n MSG_MAX_LEN) break; } buf[total] \0; printf(%s\n, buf); return; }這個(gè)循環(huán)要想穩(wěn)定工作前提是服務(wù)器一次性發(fā)送完整數(shù)據(jù)后關(guān)閉連接或發(fā)送特定的結(jié)束標(biāo)記。當(dāng)前源碼里服務(wù)器用一次send發(fā)送歷史文件內(nèi)容然后保持連接不變這樣客戶(hù)端會(huì)阻塞在下一個(gè)recv等待新消息。所以更好的做法是服務(wù)器將歷史響應(yīng)用一個(gè)獨(dú)有的body長(zhǎng)度標(biāo)記客戶(hù)端通過(guò)body_len判斷是否收完整。我在自己改進(jìn)版里是讓服務(wù)器把文件內(nèi)容分多次發(fā)送并在末尾發(fā)送一個(gè)“END”字符串客戶(hù)端循環(huán)接收直到遇到END這樣更通用?？蛻?hù)端也可以把收到的歷史記錄追加寫(xiě)入本地history_YYYYMMDD.log方便離線查看。寫(xiě)入時(shí)的打開(kāi)方式用O_APPEND保證多寫(xiě)不覆蓋。這個(gè)功能雖然不是必須但面試聊到“如何做持久化”時(shí)可以多一個(gè)加分項(xiàng)。5. 進(jìn)階優(yōu)化與排錯(cuò)讓聊天室從能跑到好跑5.1 用netstat和telnet直接驗(yàn)證服務(wù)器狀態(tài)源碼編譯后先用最基本的方式驗(yàn)證網(wǎng)絡(luò)棧是否正常。服務(wù)器運(yùn)行./server后用netstat -tlnp查看監(jiān)聽(tīng)端口應(yīng)能看到LISTEN狀態(tài)的IPv4 socket。然后使用telnet作為簡(jiǎn)易模擬客戶(hù)端手動(dòng)敲入二進(jìn)制消息較麻煩但可以用printf管道配合nc工具。比如nc -v 127.0.0.1 8888如果項(xiàng)目源碼監(jiān)聽(tīng)的端口不是8888需要去main.c里確認(rèn)#define PORT的設(shè)置。nc連接上后輸入任意文本如果服務(wù)器有回顯或廣播其他端口說(shuō)明鏈路通。實(shí)際排查中我發(fā)現(xiàn)最常見(jiàn)的錯(cuò)誤是socket bind失敗原因是端口被占用或沒(méi)有設(shè)置SO_REUSEADDR。在bind前加一行int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));這樣可以快速重啟服務(wù)器而不需要等TIME_WAIT超時(shí)。5.2 粘包與半包問(wèn)題定位方法局域網(wǎng)高并發(fā)下多條小消息可能連續(xù)到達(dá)觸發(fā)TCP的Nagle算法合并成一個(gè)大包接收方一次recv拿到多條消息這就是粘包。本項(xiàng)目使用固定頭部加變長(zhǎng)體的做法能區(qū)分每一條消息的邊界。但前提是recv必須完整地讀到頭和體。我在調(diào)試中曾遇到客戶(hù)端發(fā)兩次send第一次發(fā)header第二次發(fā)bodybody較小時(shí)兩次可能落入同一個(gè)TCP段接收方先讀12字節(jié)頭部沒(méi)問(wèn)題然后要根據(jù)header里的body_len繼續(xù)讀。但我在第三個(gè)recv階段只調(diào)用一次如果body沒(méi)到齊就返回0會(huì)直接break導(dǎo)致消息丟失。所以需要把讀取操作封裝成readnssize_t readn(int fd, void *buf, size_t count) { size_t left count; char *ptr (char *)buf; while (left 0) { ssize_t ret recv(fd, ptr, left, 0); if (ret 0) return ret; ptr ret; left - ret; } return count; }然后用readn替換所有直接recv。這樣處理半包問(wèn)題后粘包問(wèn)題其實(shí)也迎刃而解因?yàn)槊看味紘?yán)格按照頭部聲明的長(zhǎng)度讀取剩下的數(shù)據(jù)會(huì)留到下次recv再解析。5.3 線程安全的日志寫(xiě)入與退出清理歷史記錄寫(xiě)入chat.log時(shí)如果廣播線程A和線程B同時(shí)調(diào)用append_history可能發(fā)生交錯(cuò)寫(xiě)入行內(nèi)容穿插。在append_history內(nèi)部加一把全局日志鎖static pthread_mutex_t log_mutex PTHREAD_MUTEX_INITIALIZER; void append_history_safe(chat_message_t *msg) { pthread_mutex_lock(log_mutex); FILE *fp fopen(chat.log, a); if (fp) { fprintf(fp, [%ld] %s: %s\n, time(NULL), msg-from, msg-body); fclose(fp); } pthread_mutex_unlock(log_mutex); }服務(wù)器main函數(shù)收到SIGINT退出時(shí)一定要先遍歷鏈表并逐個(gè)close所有客戶(hù)端fd再釋放鏈表內(nèi)存最后關(guān)閉監(jiān)聽(tīng)fd。否則客戶(hù)端socket不會(huì)被內(nèi)核立即回收重啟服務(wù)器時(shí)可能報(bào)Address already in use?？梢杂胹ignal(SIGINT, handler)注冊(cè)清理函數(shù)handler里將全局運(yùn)行標(biāo)志置為0主循環(huán)退出后執(zhí)行清理。5.4 用strace快速定位臨時(shí)故障如果客戶(hù)端發(fā)送消息后服務(wù)器端沒(méi)有轉(zhuǎn)發(fā)一個(gè)高效排查手段是strace跟蹤進(jìn)程的系統(tǒng)調(diào)用。假設(shè)服務(wù)器pid是1234strace -p 1234 -e tracenetwork,write,read -o /tmp/server_trace.log然后讓另一臺(tái)客戶(hù)端發(fā)一條消息查看trace日志里recv返回的字節(jié)數(shù)、send調(diào)用的目標(biāo)fd和返回值。如果send返回-1且errno為EPIPE說(shuō)明對(duì)端已關(guān)閉連接如果recv返回0說(shuō)明客戶(hù)端主動(dòng)斷開(kāi)了。這樣能快速判斷問(wèn)題在網(wǎng)絡(luò)層還是業(yè)務(wù)邏輯。這個(gè)技巧比打印log更快尤其適合排查只在特定網(wǎng)絡(luò)場(chǎng)景下才出現(xiàn)的偶發(fā)問(wèn)題。5.5 擴(kuò)展方向select/poll多路復(fù)用與private消息當(dāng)前項(xiàng)目是線程阻塞模型客戶(hù)端數(shù)量增加后在大量線程切換上會(huì)有開(kāi)銷(xiāo)。作為進(jìn)階練習(xí)可以用select或poll重寫(xiě)服務(wù)器事件循環(huán)將listenfd和所有客戶(hù)端fd放入fd_set統(tǒng)一處理可讀事件。這樣單線程就能支撐上百連接。另外協(xié)議里預(yù)留了MSG_TYPE_PRIVATE實(shí)現(xiàn)私聊很簡(jiǎn)單消息體里包含“目標(biāo)名字:內(nèi)容”服務(wù)器解析后轉(zhuǎn)發(fā)給對(duì)應(yīng)fd即可。這些改動(dòng)都在可控范圍內(nèi)建議把源碼復(fù)制一份出來(lái)先備份再逐項(xiàng)重構(gòu)每次都能跑通再繼續(xù)下一步。最后有個(gè)實(shí)用小技巧把makefile里的CFLAGS改為-Wall -Wextra -g編譯時(shí)把警告全部暴露出來(lái)。我看到源碼Makefile里只有一行g(shù)cc -o這在實(shí)際工作中不夠用。加上-fno-stack-protector調(diào)試棧問(wèn)題時(shí)關(guān)閉保護(hù)但上線前務(wù)必恢復(fù)。多讀幾遍clientlist.c里鏈表插入刪除的邏輯把它畫(huà)成圖理解指針操作后再去改比我在這里寫(xiě)一千字都有效。本文還有配套的精品資源點(diǎn)擊獲取