linuxaccept

⑴ linux C下ACCEPT失敗，前面SOCKET,BIND,LISTEN都成功

我建議 閱讀 《unix網路編程》裡面有很詳細的解釋

舉個例子：
你可以把socket的IO操作看做是等人
阻塞：
你站在和人越好的地方等人，你們的約定了一個時間，當你等的時間超過了這個時間後你就可以離開這個地點去干其他的事情，否則你將繼續在這里等人。而INFINIT就是無限等待下去

非阻塞：
就是你不需要站在越好的地點等人，你可以作在離這個地點很近的一個咖啡廳喝茶聽音樂，但你能夠看到這個約定地點的情況，一旦有人來你就可以走過去和那個人見面

阻塞：人來了以後你可以第一時間見到，而不用別人等你
非阻塞：和你正在做的事情有關，如果你在坐在咖啡廳看電視，就很有可能造成別人等你的情況了

⑵ linux中有accept4這個函數么 man accept4 中有這個函數 怎麼我在使用的時候會提示錯誤

具體什麼錯誤？
你在包含頭文件<sys/socket.h>之前，應該加這一行#define _GNU_SOURCE
#define _GNU_SOURCE
#include <sys/socket.h>

⑶ linux中防火牆規則 accept 與drop 沖突了 遵循哪一條規則

使用的是iptables嗎？ 如果是iptables的話，清除規則： # iptables -F 注意！清除規則是恢復到默認規則，如果默認規則為ACCEPT那就全是ACCEPT，如果默認規則是DROP的話，那就是全DROP了。

⑷ linux tcp socket並發編程，調用accept函數後調用fork。兩台電腦測試，為何accept返回的描述符是相同的

可能是你的fork 之後產生的子進程拷貝的代碼，它那裡執行了accept，所以導致相同，你試著在每個fork之後的函數中用個exit（1）；將子進程退出，然後應該就不會有這個問題了。

⑸ linux socket的accept失敗，errno=24(Too many open files)

你的程序寫的可能不是太好，打開太多文件，超過系統設定了
當然，也有可能你的需求就是要打開很多，那麼修改系統限制，如下參數可供參考：
1 編輯/etc/sysctl.conf，增加
net.core.somaxconn=131072fs.file-max=131072
然後 sudo sysctl -p
2 修改/usr/include/linux/limits.h，其中NR_OPEN改成
NR_OPEN = 65536
3 編輯/etc/security/limits.conf，增加
* soft nofile 65535* hard nofile 65535

⑹ linux 開放埠的命令有哪些

一、查看哪些埠被打開 netstat -anp
二、關閉埠號:iptables -A INPUT -p tcp --drop 埠號-j DROP
iptables -A OUTPUT -p tcp --dport 埠號-j DROP
三、打開埠號：iptables -A INPUT -ptcp --dport 埠號-j ACCEPT
四、以下是linux打開埠命令的使用方法。
nc -lp 23 &(打開23埠，即telnet)
netstat -an | grep 23 (查看是否打開23埠)
五、linux打開埠命令每一個打開的埠，都需要有相應的監聽程序才可以

⑺ Linux下各種鎖的理解和使用及總結解決epoll驚群問題(面試常考)-

鎖出現的原因

臨界資源是什麼: 多線程執行流所共享的資源

鎖的作用是什麼, 可以做原子操作, 在多線程中針對臨界資源的互斥訪問... 保證一個時刻只有一個線程可以持有鎖對於臨界資源做修改操作...

任何一個線程如果需要修改，向臨界資源做寫入操作都必須持有鎖，沒有持有鎖就不能對於臨界資源做寫入操作.

鎖 ： 保證同一時刻只能有一個線程對於臨界資源做寫入操作 (鎖地功能)

再一個直觀地代碼引出問題，再從指令集的角度去看問題

上述一個及其奇怪的結果，這個結果每一次運行都可能是不一樣的，Why ？ 按照我們本來的想法是每一個線程 + 20000000 結果肯定應該是60000000呀，可以就是達不到這個值

為何？ (深入匯編指令來看) 一定將過程放置到匯編指令上去看就可以理解這個過程了.

a++; 或者 a += 1; 這些操作的匯編操作是幾個步驟?

其實是三個步驟：

正常情況下，數據少，操作的線程少，問題倒是不大，想一想要是這樣的情況下，操作次數大，對齊操作的線程多，有些線程從中間切入進來了，在運算之後還沒寫回內存就另外一個線程切入進來同時對於之前的數據進行++ 再寫回內存, 啥效果，多次++ 操作之後結果確實一次加加操作後的結果。 這樣的操作 (術語叫做函數的重入) 我覺得其實就是重入到了匯編指令中間了，還沒將上一次運算的結果寫回內存就重新對這個內存讀取再運算寫入，結果肯定和正常的邏輯後的結果不一樣呀

來一幅圖片解釋一下

咋辦? 其實問題很清楚，我們只需要處理的是多條匯編指令不能讓它中間被插入其他的線程運算. （要想自己在執行匯編指令的時候別人不插入進來） 將多條匯編指令綁定成為一條指令不就OK了嘛。

也就是原子操作！！！

不會原子操作？操作系統給咱提供了線程的 綁定方式工具呀：mutex 互斥鎖(互斥量)， 自旋鎖(spinlock)， 讀寫鎖（readers-writer lock） 他們也稱作悲觀鎖. 作用都是一個樣，將多個匯編指令鎖成為一條原子操作 (此處的匯編指令也相當於如下的臨界資源)

悲觀鎖：鎖如其名，每次都悲觀地認為其他線程也會來修改數據，進行寫入操作，所以會在取數據前先加鎖保護，當其他線程想要訪問數據時，被阻塞掛起

樂觀鎖：每次取數據的時候，總是樂觀地認為數據不會被其他線程修改，因此不上鎖。但是在更新數據前， 會判斷其他數據在更新前有沒有對數據進行修改。

互斥鎖

最為常見使用地鎖就是互斥鎖, 也稱互斥量. mutex

特徵，當其他線程持有互斥鎖對臨界資源做寫入操作地時候，當前線程只能掛起等待，讓出CPU，存在線程間切換工作

解釋一下存在線程間切換工作 : 當線程試圖去獲取鎖對臨界資源做寫入操作時候，如果鎖被別的線程正在持有，該線程會保存上下文直接掛起，讓出CPU，等到鎖被釋放出來再進行線程間切換，從新持有CPU執行寫入操作

互斥鎖需要進行線程間切換，相比自旋鎖而言性能會差上許多，因為自旋鎖不會讓出CPU, 也就不需要進行線程間切換的步驟，具體原理下一點詳述

加互斥量(互斥鎖)確實可以達到要求，但是會發現運行時間非常的長，因為線程間不斷地切換也需要時間, 線程間切換的代價比較大.

相關視頻推薦

你繞不開的組件—鎖，4個方面手撕鎖的多種實現

「驚群」原理、鎖的設計方案及繞不開的「死鎖」問題

學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂

需要C/C++ Linux伺服器架構師學習資料加qun812855908獲取（資料包括 C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg 等），免費分享

自旋鎖

spinlock.自旋鎖.

對比互斥量(互斥鎖)而言，獲取自旋鎖不需要進行線程間切換，如果自旋鎖正在被別的線程佔用，該線程也不會放棄CPU進行掛起休眠，而是恰如其名的在哪裡不斷地循環地查看自旋鎖保持者(持有者)是否將自旋鎖資源釋放出來... （自旋地原來就是如此）

口語解釋自旋：持有自旋鎖的線程不釋放自旋鎖，那也沒有關系呀，我就在這里不斷地一遍又一遍地查詢自旋鎖是否釋放出來，一旦釋放出來我立馬就可以直接使用 (因為我並沒有掛起等待，不需要像互斥鎖還需要進行線程間切換，重新獲取CPU，保存恢復上下文等等操作)

哪正是因為上述這些特點，線程嘗試獲取自旋鎖，獲取不到不會採取休眠掛起地方式，而是原地自旋（一遍又一遍查詢自旋鎖是否可以獲取）效率是遠高於互斥鎖了. 那我們是不是所有情況都使用自旋鎖就行了呢，互斥鎖就可以放棄使用了嗎????

解釋自旋鎖地弊端：如果每一個線程都僅僅只是需要短時間獲取這個鎖，那我自旋占據CPU等待是沒啥問題地。要是線程需要長時間地使用占據（鎖）。。。 會造成過多地無端占據CPU資源，俗稱站著茅坑不拉屎... 但是要是僅僅是短時間地自旋，平衡CPU利用率 + 程序運行效率 （自旋鎖確實是在有些時候更加合適）

自旋鎖需要場景：內核可搶占或者SMP(多處理器)情況下才真正需求 (避免死鎖陷入死循環，瘋狂地自旋，比如遞歸獲取自旋鎖. 你獲取了還要獲取，但是又沒法釋放)

自旋鎖的使用函數其實和互斥鎖幾乎是一摸一樣地，僅僅只是需要將所有的mutex換成spin即可

僅僅只是在init存在些許不同

何為驚群，池塘一堆, 我瞄準一條插過去，但是好似所有的都像是覺著自己正在被插一樣的四處逃竄。 這個就是驚群的生活一點的理解

驚群現象其實一點也不少，比如說 accept pthread_cond_broadcast 還有多個線程共享epoll監視一個listenfd 然後此刻 listenfd 說來 SYN了，放在了SYN隊列中，然後完成了三次握手放在了 accept隊列中了, 現在問題是這個connect我應該交付給哪一個線程處理呢.

多個epoll監視准備工作的線程 就是這群 ()，然後connet就是魚叉，這一叉下去肯定是所有的 epoll線程都會被驚醒 (多線程共享listenfd引發的epoll驚群)

同樣如果將上述的多個線程換成多個進程共享監視 同一個 listenfd 就是(多進程的epoll驚群現象)

咱再畫一個草圖再來理解一下這個驚群:

如果是多進程道理是一樣滴，僅僅只是將所有的線程換成進程就OK了

終是來到了今天的正題了: epoll驚群問題地解決上面了...

首先 先說說accept的驚群問題，沒想到吧accept 平時大家寫它的多線程地時候，多個線程同時accept同一個listensock地時候也是會存在驚群問題地，但是accept地驚群問題已經被Linux內核處理了: 當有新的連接進入到accept隊列的時候，內核喚醒且僅喚醒一個進程來處理

但是對於epoll的驚群問題，內核卻沒有直接進行處理。哪既然內核沒有直接幫我們處理，我們應該如何針對這種現象做出一定的措施呢?

驚群效應帶來的弊端: 驚群現象會造成epoll的偽喚醒，本來epoll是阻塞掛起等待著地，這個時候因為掛起等待是不會佔用CPU地。。。 但是一旦喚醒就會佔用CPU去處理發生地IO事件， 但是其實是一個偽喚醒，這個就是對於線程或者進程的無效調度。然而進程或者線程地調取是需要花費代價地，需要上下文切換。需要進行進程(線程)間的不斷切換... 本來多核CPU是用來支持高並發地，但是現在卻被用來無效地喚醒，對於多核CPU簡直就是一種浪費 （浪費系統資源） 還會影響系統的性能.

解決方式（一般是兩種）

Nginx的解決方式:

加鎖：驚群問題發生的前提是多個進程（線程）監聽同一個套接字(listensock)上的事件，所以我們只讓一個進程（線程）去處理監聽套接字就可以了。

畫兩張圖來理解一下：

上述還沒有進行一個每一個進程都對應一個listensock 而是多線程共享一個listensock 運行結果如下

所有的線程同時被喚醒了，但是實際上會處理連接的僅僅只是一個線程，

咱僅僅只是將主線程做如上這樣一個簡單的修改，每一個線程對應一個listensock；每一個線程一個獨有的監視窗口，將問題拋給內核去處理，讓內核去負載均衡 ： 結果如下

僅僅喚醒一個線程來進行處理連接，解決了驚群問題

本文通過介紹兩種鎖入手，以及為什麼需要鎖，鎖本質就是為了保護，持有鎖你就有權力有能力操作寫入一定的臨界保護資源，沒有鎖你就不行需要等待，本質其實是將多條匯編指令綁定成原子操作

然後介紹了驚群現象，通過一個巧妙地例子，扔一顆石子，只是瞄準一條魚扔過去了，但是整池魚都被驚醒了，

對應我們地實際問題就是， 多個線程或者進程共同監視同一個listensock。。。。然後IO連接事件到來地時候本來僅僅只是需要一個線程醒過來處理即可，但是卻會使得所有地線程（進程）全部醒過來，造成不必要地進程線程間切換，多核CPU被浪費喔，系統資源被浪費

處理方式 一。 Nginx 源碼加互斥鎖處理。。 二。設置SO_REUSEPORT, 使得多個進程線程可以同時連接同一個port , 為每一個進程線程搞一個listensock... 將問題拋給內核去處理，讓他去負載均衡地僅僅將IO連接事件分配給一個進程或線程

⑻ linux 我的accept函數為什麼不阻塞啊，請教

大概掃了一眼沒仔細看

但我想問你
你bind的sock_man從哪來的?
listen呢?
accept呢?
看一下你的socket函數吧

⑼ linux系統中在客戶端連上服務端後,調用accept函數返回一直是-1是什麼原因

系統就是應用程序

⑽ linux網路編程，可以用select函數代替accept函數接收客戶端的connect請求嗎

select不可以替代accept，但可以用來作輔助，比如
nfds = select(Fd + 1, &fds, NULL, NULL , &tv);
if(nfds>0){
if (listenSock != -1 && FD_ISSET(listenSock, &fds))
{

if ((sock = accept(listenSock,(struct sockaddr *)&addr, &addrlen)) < 0)
{
return -1;
}
}
}
大概就這樣