- 論壇徽章:
- 0
|
前些時(shí)間去了騰訊面試， 可惜現(xiàn)場沒回答好。
是一些基礎(chǔ)問題，同時(shí)也比較深入的問題。 在此列出來， 歡迎大家討論交流。
提問（不按時(shí)間順序）：
1， 使用Linux epoll模型，水平觸發(fā)模式（Level-Triggered）；當(dāng)socket可寫時(shí)，會不停的觸發(fā)socket可寫的事件，如何處理？
2， 從socket讀數(shù)據(jù)時(shí)，socket緩存里的數(shù)據(jù)，可能超過用戶緩存的長度，如何處理？ 例如，socket緩存有8kB的數(shù)據(jù)，而你的緩存只有2kB空間。
3， 向socket發(fā)送數(shù)據(jù)時(shí)， 可能只發(fā)送了用戶緩存里的一半，如何處理？例如，需要向socket發(fā)送8kB數(shù)據(jù)，返回值只有2kB發(fā)送成功。
4， C++的虛函數(shù)是怎么實(shí)現(xiàn)的？
5， C++的虛函數(shù)有什么作用？
6， 非阻塞connect（）如何實(shí)現(xiàn)？
7，sizeof()問題
class A
{
char c;
int val;
short sh;
}
class B
{
char c;
int val;
short sh;
void func1(void);
virtual func2(void);
}
sizeof(A), sizeof(B) 分別是多少？
8， 實(shí)現(xiàn)字符串比較函數(shù) strcmp(char *src, char * sub)
9， 實(shí)現(xiàn)內(nèi)存拷貝函數(shù) strcpy(void*dst, char * src, size_t len)
10，條件變量的如何使用? 你使用的線程函數(shù)是什么？
11， deamon進(jìn)程如何實(shí)現(xiàn)？
12， HTTP和CGI是什么?
13， TCP的三次握手， TIME_WAIT和CLOSE_WAIT狀態(tài)是什么？
因?yàn)榈?題之后的屬于客觀題，不打算在此寫答案。 朋友們?nèi)缬泻玫拇鸢敢矚g迎跟貼。
本人在此寫出自己對前6個(gè)問題的回答：
1， 使用linux epoll模型，水平觸發(fā)模式（Level-Triggered）；當(dāng)socket可寫時(shí)，會不停的觸發(fā)socket可寫的事件，如何處理？
第一種最普通的方式：
當(dāng)需要向socket寫數(shù)據(jù)時(shí)，將該socket加入到epoll模型（epoll_ctl）；等待可寫事件。
接收到socket可寫事件后，調(diào)用write()或send()發(fā)送數(shù)據(jù)。。。
當(dāng)數(shù)據(jù)全部寫完后， 將socket描述符移出epoll模型。
這種方式的缺點(diǎn)是： 即使發(fā)送很少的數(shù)據(jù)，也要將socket加入、移出epoll模型。有一定的操作代價(jià)。
第二種方式，（是本人的改進(jìn)方案， 叫做directly-write）
向socket寫數(shù)據(jù)時(shí)，不將socket加入到epoll模型；而是直接調(diào)用send()發(fā)送；
只有當(dāng)或send()返回錯(cuò)誤碼EAGAIN（系統(tǒng)緩存滿），才將socket加入到epoll模型，等待可寫事件后，再發(fā)送數(shù)據(jù)。
全部數(shù)據(jù)發(fā)送完畢，再移出epoll模型。
這種方案的優(yōu)點(diǎn)： 當(dāng)用戶數(shù)據(jù)比較少時(shí)，不需要epool的事件處理。
在高壓力的情況下，性能怎么樣呢？
對一次性直接寫成功、失敗的次數(shù)進(jìn)行統(tǒng)計(jì)。如果成功次數(shù)遠(yuǎn)大于失敗的次數(shù)， 說明性能良好。（如果失敗次數(shù)遠(yuǎn)大于成功的次數(shù)，則關(guān)閉這種直接寫的操作，改用第一種方案。同時(shí)在日志里記錄警告）
在我自己的應(yīng)用系統(tǒng)中，實(shí)驗(yàn)結(jié)果數(shù)據(jù)證明該方案的性能良好。
事實(shí)上，網(wǎng)絡(luò)數(shù)據(jù)可分為兩種到達(dá)/發(fā)送情況：
一是分散的數(shù)據(jù)包， 例如每間隔40ms左右，發(fā)送/接收3-5個(gè) MTU（或更小，這樣就沒超過默認(rèn)的8K系統(tǒng)緩存）。
二是連續(xù)的數(shù)據(jù)包， 例如每間隔1s左右，連續(xù)發(fā)送/接收 20個(gè) MTU（或更多）。
回來查了資料，發(fā)現(xiàn)以下兩種方式：
第三種方式： 使用Edge-Triggered（邊沿觸發(fā)），這樣socket有可寫事件，只會觸發(fā)一次。
可以在應(yīng)用層做好標(biāo)記。以避免頻繁的調(diào)用 epoll_ctl( EPOLL_CTL_ADD, EPOLL_CTL_MOD)。 這種方式是epoll 的 man 手冊里推薦的方式， 性能最高。但如果處理不當(dāng)容易出錯(cuò)，事件驅(qū)動停止。
第四種方式： 在epoll_ctl()使用EPOLLONESHOT標(biāo)志，當(dāng)事件觸發(fā)以后，socket會被禁止再次觸發(fā)。
需要再次調(diào)用epoll_ctl（EPOLL_CTL_MOD），才會接收下一次事件。 這種方式可以禁止socket可寫事件，應(yīng)該也會同時(shí)禁止可讀事件。會帶來不便，同時(shí)并沒有性能優(yōu)勢，因?yàn)閑poll_ctl（）有一定的操作代價(jià)。
2， 從socket讀數(shù)據(jù)時(shí)，socket緩存里的數(shù)據(jù)，可能超過用戶緩存的長度，如果處理？
可以調(diào)用realloc()，擴(kuò)大原有的緩存塊尺寸。
但是臨時(shí)申請內(nèi)存的有一定性能損失。
這種情況要看接收緩存的方式。
第一種方式： 使用100k的大接收緩存為例。
如果要等待數(shù)據(jù)，并進(jìn)行解析。可能發(fā)生緩存不夠的情況。此時(shí)只能擴(kuò)充緩存，或先處理100k的數(shù)據(jù)，再接收新的數(shù)據(jù)。
第二種方式： 使用緩存隊(duì)列，分成8K大小的隊(duì)列。
不存在接收緩存不夠的情況。 除非用戶解析已出錯(cuò)，使用數(shù)據(jù)接收、使用脫勾。 這種方式的代價(jià)是，可能需要將緩存隊(duì)列再次拷貝、拼接成一塊大的緩存，再進(jìn)行解析。 而在本人的系統(tǒng)中，只需要將socket接收的數(shù)據(jù)再次原樣分發(fā)給客戶， 所以這種方案是最佳方案。
3， 向socket發(fā)送數(shù)據(jù)時(shí)， 可能只發(fā)送了用戶緩存里的一半，然后失敗，如何處理？
記錄緩存的偏移量。 下一次socket寫事件時(shí)， 再從偏移的位置接著發(fā)送。
那個(gè)面試官居然對這個(gè)問題問了我兩次， 看來我解釋的不夠清晰。。。。。。 郁悶。
4， C++的虛函數(shù)是怎么實(shí)現(xiàn)的？
使用虛函數(shù)表。
回來查下資料： C++對象使用虛表， 如果是基類的實(shí)例，對應(yīng)位置存放的是基類的函數(shù)指針；如果是繼承類，對應(yīng)位置存放的是繼承類的函數(shù)指針（如果在繼承類有實(shí)現(xiàn)）。所以，當(dāng)使用基類指針調(diào)用對象方法時(shí)，也會根據(jù)具體的實(shí)例，調(diào)用到繼承類的方法。
5， C++的虛函數(shù)有什么作用？
虛函數(shù)作用是實(shí)現(xiàn)多態(tài)， 很多人都能理解這一點(diǎn)。但卻不會回答下面這一點(diǎn)。
更重要的，虛函數(shù)其實(shí)是實(shí)現(xiàn)封裝，使得使用者不需要關(guān)心實(shí)現(xiàn)的細(xì)節(jié)。在很多設(shè)計(jì)模式中都是這樣用法，例如Factory、Bridge、Strategy模式。 前兩天在書上剛好看到這個(gè)問題，但在面試的時(shí)候卻沒想起來。
個(gè)人覺得這個(gè)問題可以很好的區(qū)分C++的理解水平。
6， 非阻塞connect（）如何實(shí)現(xiàn)？
將socket設(shè)置成non-blocking，操作方法同非阻塞read()、write();
面試官是在聽到我介紹之后，才問我這個(gè)問題。可惜還是問我兩遍。
這次面試， 總的來說準(zhǔn)備不夠充足， 所以這次機(jī)會沒有青睞我！
也有其它一些問題：
1， 對于一般的面試提問， 總是想很簡要的回答完。因?yàn)閷Ψ娇赡鼙緛砭秃芮宄宰约壕拖胍粌删湓捳f完。 但是有時(shí)候這樣行不通。需要適當(dāng)?shù)幕卮鹎逦�、完整一些�?br />
2， 對TCP/UDP的問題本來是很熟悉的，但因?yàn)殚L時(shí)間沒復(fù)習(xí)，忘的差不多了。
3， 以前已經(jīng)對RTSP進(jìn)行了仔細(xì)的學(xué)習(xí)。 HTTP、SIP屬于同一類協(xié)議。而我卻回答不了HTTP的問題。努力學(xué)習(xí)啊................
4， 有些問題要問我兩遍，說明我的表達(dá)確實(shí)不夠清晰。有的問題可能面試官自己并不清晰，所以除了表達(dá)清晰之外，完全有必要適當(dāng)?shù)幕卮鹕酝暾７駝t很難讓人滿意。
5， 精神狀態(tài)不太好，思維有些慢了。 因?yàn)榭偸撬耐怼?br />
接下來打算繼續(xù)研究 lighttpd源碼， 這樣對我自己的水平提高會有很大幫助。
機(jī)會總是青睞有準(zhǔn)備的人！ 期待下次。
[ 本帖最后由 fm971 于 2009-6-18 17:52 編輯 ] |
|
免費(fèi)注冊
發(fā)表于 2009-06-18 16:44
