1.概述

在實際工作中會經常遇到一些bug，有些就需要用到檔案控制代碼，檔案描述符等概念，比如報錯： too many open files, 如果你對相關知識一無所知，那麼debug起來將會異常痛苦。在linux作業系統中，檔案控制代碼（包括Socket控制代碼）、開啟檔案、檔案指標、檔案描述符的概念比較繞，而且windows的檔案控制代碼又與此有何關聯和區別？這一系列的問題是我們不得不面對的。

博主通過翻閱相關資料，並採用了一些demo來驗證相關觀點。如果文中有理解偏差，歡迎指正，對linux核心不是很熟，持續學習中。

這裡先籠統的將一下自己對上面的問題的一些理解：
控制代碼，熟悉Windows程式設計的人知道：控制代碼是Windows用來標識被應用程式所建立或使用的物件的唯一整數，windows使用各種各樣的控制代碼標識諸如應用程式例項、視窗、控制、點陣圖等。Windows的控制代碼有點像C語言中的檔案控制代碼。更通俗的理解，控制代碼是一種指向指標的指標。在linux系統中檔案控制代碼（file handles）和檔案描述符(file descriptor)是一個一一對應的關係（如果錯誤，歡迎指正），按照C語言的理解檔案控制代碼是FILE*（fopen()返回）而檔案描述符是fd（int型，open()函式返回），FILE這個結構體中有一個欄位是_fileno其就是指fd(文章末尾通過程式驗證)，且FILE*和fd可以通過C語言函式進行互相轉換，故此博主認為linux的檔案控制代碼和檔案描述符應該是一個一一對應的關係。檔案指標即指FILE*，即指檔案控制代碼。開啟檔案（open files）包括檔案控制代碼但不僅限於檔案控制代碼，由於linux所有的事物都以檔案的形式存在，要使用諸如共享記憶體、訊號量、訊息佇列、記憶體對映等都會開啟檔案，但這些是不會佔用檔案控制代碼。

2. ulimit

檢視程序允許開啟的最大檔案控制代碼數：ulimit -n
設定程序能開啟的最大檔案控制代碼數：ulimit -n xxx

ulimit在系統允許的情況下，提供對特定shell可利用的資源的控制。（Provides control over the resources avaliable to the shell and to processes started by it, on systems that allow such control）-H和-S選項設定指定資源的硬限制和軟限制。硬限制設定之後不能再新增，而軟限制則可以增加到硬限制規定的值。如果-H和-S選項都沒有指定，則軟限制和硬限制同時設定。限制值可以是指定資源的數值或者hard, soft, unlimited這些特殊值，其中hard代表當前硬限制, soft代表當前軟體限制, unlimited代表不限制. 如果不指定限制值, 則列印指定資源的軟限制值, 除非指定了-H選項.如果指定了不只一種資源, 則限制名和單位都會在限制值前顯示出來.

[root@zhuzhonghua2-fqawb ~]# ulimit -Sn
1024
[root@zhuzhonghua2-fqawb ~]# ulimit -Hn
4096

需要注意的是ulimit提供的是對特定shell可利用的資源的控制，而shell是與具體使用者相關的。因此ulimit提供的是對單個使用者的限制。包括以下項：

[root@zhuzhonghua2-fqawb ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
 

file size               (blocks, -f) unlimited
pending signals                 (-i) 62799
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 65536
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

其中就有個“open files”的限制，預設是1024，也就是這個使用者最大可以開啟1024個檔案。如果使用ulimit -n修改最大檔案開啟數，那麼只對當前shell使用者有用，同時也只對當前shell和這個shell fork出來的子shell生效，重啟之後會重新恢復為預設值。

3. limits.conf

limits.conf這個檔案實在/etc/security/目錄下，因此這個檔案是處於安全考慮的。limits.conf檔案是用於提供對系統中的使用者所使用的資源進行控制和限制，對所有使用者的資源設定限制是非常重要的，這可以防止使用者發起針對處理器和記憶體數量等的拒絕服務攻擊。這些限制必須在使用者登入時限制。

[[email protected] ~]#  cat /etc/security/limits.conf
（省略若干....）
# End of file
apps soft nofile 65535
apps hard nofile 65535
apps soft nproc 10240
apps hard nproc 10240

其中含義如下：

• 第一列表示域（domain）,可以使用使用者名稱（root等），組名（以@開頭）,通配置*和%，%可以用於%group引數。
• 第二列表示型別(type),值可以是soft或者hard
• 第三列表示專案(item),值可以是core, data, fsize, memlock, nofile, rss, stack, cpu, nproc, as, maxlogins, maxsyslogins, priority, locks, msgqueue, nie, rtprio.
• 第四列表示值.

其中nofile(Number of Open File）就是檔案開啟數。
關於第三列的詳細解釋如下：

#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open file descriptors
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority

limits.conf與ulimit的區別在於前者是針對所有使用者的，而且在任何shell都是生效的，即與shell無關，而後者只是針對特定使用者的當前shell的設定。在修改最大檔案開啟數時，最好使用limits.conf檔案來修改，通過這個檔案，可以定義使用者，資源型別，軟硬限制等。也可修改/etc/profile檔案加上ulimit的設定語句來是的全域性生效。

當達到上限時，會報錯：too many open files或者遇上Socket/File: Cannot open so many files等。

4. file-max & file-nr

[root@zhuzhonghua2-fqawb ~]# cat /proc/sys/fs/file-max 
798282
[root@zhuzhonghua2-fqawb fd]# sysctl -a | grep fs.file-max
fs.file-max = 798282

該檔案指定了可以分配的檔案控制代碼的最大數目（系統全域性的可用控制代碼數目. The value in file-max denotes the maximum number of file handles that the Linux kernel will allocate）。如果使用者得到的錯誤訊息審批由於開啟檔案數已經達到了最大值，從而他們不能開啟更多檔案，則可能需要增加改之。可將這個值設定成任意多個檔案，並且能通過將一個新數字值寫入該檔案來更改該值。這個引數的預設值和記憶體大小有關係，可以使用公式：file-max ≈ 記憶體大小/ 10k.

[root@zhuzhonghua2-fqawb ~]# cat /proc/sys/fs/file-nr
1440        0   798282

關於file-nr引數的解釋如下：
Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles – this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.

這三個值分別指：系統已經分配出去的控制代碼數、已經分配但是還沒有使用的控制代碼數以及系統最大的控制代碼數(和file-max一樣)。

[root@zhuzhonghua2-fqawb fd]# lsof | wc -l
2538

lsof是列出系統所佔用的資源（list open files），但是這些資源不一定會佔用控制代碼。比如共享記憶體、訊號量、訊息佇列、記憶體對映等，雖然佔用了這些資源，但不佔用控制代碼。
如果出了某些故障，使用lsof | wc -l的結果，這個時候可以通過file-nr粗略的估算一下。

檢視硬碟資訊：df -m
檢視記憶體資訊：free -m
檢視CPU資訊：cat /proc/cpuinfo
檢視核心所能開啟的執行緒數：cat /proc/sys/kernel/threads-max

5. 為什麼有限制？

為什麼Linux核心對檔案控制代碼數、執行緒和程序的最大開啟數進行了限制？以及如果我們把它調的太大，會產生什麼樣的後果？

原因1 - 資源問題：the operating system needs memory to manage each open file, and memory is a limited resource - especially on embedded systems.
原因2 - 安全問題：if there were no limits, a userland software would be able to create files endlessly until the server goes down.

What’s more? If the file descriptors are tcp sockets, etc, then you risk using up a large amount for the socket buffers and other kernel objects, this memory is not going to be swappable.

最主要的是資源問題，為防止某一單一程序開啟過多檔案描述符而耗盡系統資源，對程序開啟檔案數做了限制。

6. lsof

lsof(list open files)是一個列出當前系統開啟檔案的工具。在linux環境下，任何事物都以檔案的形式存在，通過檔案不僅僅可以訪問常規資料，還可以訪問網路連線和硬體。所以如TCP和UDP等，系統在後臺都為該應用程式分配了一個檔案描述符，無論這個檔案的本質如何，該檔案描述符為應用程式與基礎作業系統之間的互動提供了通用介面。因為應用程式開啟檔案的描述符列表提供了大量關於這個應用程式本身的資訊，因此通過lsof工具能夠檢視這個列表對系統檢測以及拍錯將是很有幫助的。

在終端下輸入lsof即可顯示系統開啟的檔案，因為lsof需要訪問核心記憶體和各種檔案，所以必須以root身份執行它才能夠充分地發揮其功能。

[[email protected] linuxC]# lsof -p 14895
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF    NODE NAME
java    14895 root  cwd    DIR              252,1     4096 1310824 /root/util/kafka_2.10-0.8.2.1
java    14895 root  rtd    DIR              252,1     4096       2 /
java    14895 root  txt    REG              252,1     7734 1583642 /root/util/jdk1.8.0_112/bin/java
java    14895 root  mem    REG              252,1 10485760 1325066 /tmp/kafka-logs/default_channel_kafka_zzh_demo-4/00000000000003626728.index
...(省略若干)
java    14895 root   85u   REG              252,1        0 1311594 /tmp/kafka-logs/default_channel_kafka_zzh_demo-4/00000000000003626728.log
java    14895 root   87u   REG              252,1        0 1325038 /tmp/kafka-logs/default_channel_kafka_zzh_demo-3/00000000000003915669.log
java    14895 root   88u  IPv6           40855648      0t0     TCP zhuzhonghua2-fqawb:XmlIpcRegSvc->xx.xx.139.85:64708 (ESTABLISHED)
java    14895 root   89u   REG              252,1        0 1325037 /tmp/kafka-logs/default_channel_kafka_zzh_demo-2/00000000000005892533.log
java    14895 root   93u   REG              252,1        0 1325040 /tmp/kafka-logs/default_channel_kafka_zzh_demo-1/00000000000005494790.log
java    14895 root   94u   REG              252,1        0 1325043 /tmp/kafka-logs/default_channel_kafka_zzh_demo-0/00000000000003858999.log
[[email protected] linuxC]# ls /proc/14895/fd | wc -l
89
[[email protected] linuxC]# ls /proc/14895/fd 
0  10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  47  49  50  52  54  56  58  6   61  63  65  67  69  70  72  75  77  79  80  82  85  88  9   94
1  11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  46  48  5   51  53  55  57  59  60  62  64  66  68  7   71  74  76  78  8   81  83  87  89  93

lsof輸出割裂資訊的意義如下：

• COMMAND：程序的名稱
• PID： 程序識別符號
• USER：程序所有者
• FD：檔案描述符，應用程式通過檔案描述符識別該檔案。如cwd, rtd, txt, mem, DEL, 0u, 3w, 4r等
• TYPE：檔案型別，如DIR, REG, CHR, Ipv6, unix, FIFO等
• DEVICE：指定磁碟的名稱
• SIZE/OFF：檔案的大小
• NODE：索引節點
• NAME：開啟檔案的確切名稱

FD列中的檔案描述符cwd表示應用程式的當前工作目錄，這是該應用程式啟動的目錄，除非它本身對這個目錄進行更改；txt型別的檔案是程式程式碼，如應用程式二進位制檔案本身或共享庫，如上列表中顯示的、sbin/init程式；數值表示應用程式的檔案描述符，這是開啟該檔案時返回的一個整數，如“lsof -p 14895”命令解析出來的最後一行的檔案描述符為94，u表示該檔案被開啟處於讀寫模式，而不是隻讀r或只寫w模式，同時還有大寫的W表示該應用程式具有對整個檔案的寫鎖。該檔案描述符用於確保每次只能開啟一個應用程式例項。初始開啟每個應用程式時，都有三個檔案描述符：0，1，2，分別表示標準輸入、標準輸出、錯誤流。所以大多數應用程式所開啟的檔案的FD都是從3開始的。

TYPE列比較直觀。檔案和目錄分別為REG和DIR。而CHR和BLK分別表示字元和塊裝置。或者unix, FIFO, Ipv6分表表示UNIX域套接字，FIFO佇列和IP套接字。

檢視當前程序打開了多少檔案：lsof -n|awk ‘{print $2}’|sort|uniq -c|sort -nr|more | grep [PID]

[root@zhuzhonghua2-fqawb fd]# lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more | grep 14895
    173 14895

第一列是控制代碼數，第二列是程序號PID.

[root@zhuzhonghua2-fqawb proc]# lsof -p 14895 | wc -l
174

這裡多了一個是由於：

COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF    NODE NAME
java    14895 root  cwd    DIR              252,1     4096 1310824 /root/util/kafka_2.10-0.8.2.1
java    14895 root  rtd    DIR              252,1     4096       2 /
java    14895 root  txt    REG              252,1     7734 1583642 /root/util/jdk1.8.0_112/bin/java
java    14895 root  mem    REG              252,1 10485760 1325066 /tmp/kafka-logs/default_channel_kafka_zzh_demo-4/00000000000003626728.index
java    14895 root  mem    REG              252,1 10485760 1325044 /tmp/kafka-logs/default_channel_kafka_zzh_demo-0/00000000000003858999.index
java    14895 root  mem    REG              252,1 10485760 1325042 /tmp/kafka-logs/default_channel_kafka_zzh_demo-2/00000000000005892533.index
java    14895 root  mem    REG              252,1 10485760 1325041 /tmp/kafka-logs/default_channel_kafka_zzh_demo-1/00000000000005494790.index
....(省略若干)
java    14895 root   85u   REG              252,1        0 1311594 /tmp/kafka-logs/default_channel_kafka_zzh_demo-4/00000000000003626728.log
java    14895 root   87u   REG              252,1        0 1325038 /tmp/kafka-logs/default_channel_kafka_zzh_demo-3/00000000000003915669.log
java    14895 root   88u  IPv6           40855648      0t0     TCP zhuzhonghua2-fqawb:XmlIpcRegSvc->xx.xx.139.85:64708 (ESTABLISHED)
java    14895 root   89u   REG              252,1        0 1325037 /tmp/kafka-logs/default_channel_kafka_zzh_demo-2/00000000000005892533.log
java    14895 root   93u   REG              252,1        0 1325040 /tmp/kafka-logs/default_channel_kafka_zzh_demo-1/00000000000005494790.log
java    14895 root   94u   REG              252,1        0 1325043 /tmp/kafka-logs/default_channel_kafka_zzh_demo-0/00000000000003858999.log

多了“COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME”這一行。

而檔案描述符的個數為90：

[root@zhuzhonghua2-fqawb linuxC]# ls /proc/14895/fd |wc -l
90
[root@zhuzhonghua2-fqawb linuxC]# ls /proc/14895/fd
0  10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  47  49  50  52  54  56  58  6   61  63  65  67  69  70  72  75  77  79  80  82  84  87  89  93
1  11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  46  48  5   51  53  55  57  59  60  62  64  66  68  7   71  74  76  78  8   81  83  85  88  9   94

7. 檔案描述符（file descriptor）

對於linux而言，所有對裝置和檔案的操作都使用檔案描述符來進行的。檔案描述符是一個非負的整數，它是一個索引值，指向核心中每個程序開啟檔案的記錄表。當開啟一個現存檔案或建立一個新檔案時，核心就向程序返回一個檔案描述符；當需要讀寫檔案時，也需要把檔案描述符作為引數傳遞給相應的函式。
通常，一個程序啟動時，都會開啟3個檔案：標準輸入、標準輸出和標準出錯處理。這3個檔案分別對應檔案描述符為0、1和2（巨集STD_FILENO、STDOUT_FILENO和STDERR_FILENO）。

每一個檔案描述符會與一個開啟檔案相對應，同時，不同的檔案描述符也會指向同一個檔案。相同的檔案可以被不同的程序開啟也可以在同一個程序中被多次開啟。系統為每一個程序維護了一個檔案描述符表，該表的值都是從0開始的，所以在不同的程序中你會看到相同的檔案描述符，這種情況下相同檔案描述符有可能指向同一個檔案，也有可能指向不同的檔案。具體情況要具體分析，要理解具體其概況如何，需要檢視由核心維護的3個數據結構。
1. 程序級的檔案描述符表
2. 系統級的開啟檔案描述符表
3. 檔案系統的i-node表

由於程序級檔案描述符表的存在，不同的程序中會出現相同的檔案描述符，它們可能指向同一個檔案，也可能指向不同的檔案。兩個不同的檔案描述符，若指向同一個開啟檔案控制代碼，將共享同一檔案偏移量。因此，如果通過其中一個檔案描述符來修改檔案偏移量，那麼從另一個檔案描述符中也會觀察到變化，無論這兩個檔案描述符是否屬於不同程序，還是同一個程序，情況都是如此。

8. 檔案控制代碼 vs 檔案描述符

檔案控制代碼也稱為檔案指標(FILE *)：C語言中使用檔案指標做為I/O的控制代碼。檔案指標指向程序使用者區中的一個被稱為FILE結構的資料結構。FILE結構包括一個緩衝區和一個檔案描述符。而檔案描述符是檔案描述符表的一個索引，因此從某種意義上說檔案指標就是控制代碼的控制代碼（在Windows系統上，檔案描述符被稱作檔案控制代碼）。

C語言中FILE結構體的定義：

/* Define outside of namespace so the C++ is happy.  */
struct _IO_FILE;

__BEGIN_NAMESPACE_STD
/* The opaque type of streams.  This is the definition used elsewhere.  */
typedef struct _IO_FILE FILE;
__END_NAMESPACE_STD
#if defined __USE_LARGEFILE64 || defined __USE_SVID || defined __USE_POSIX \
    || defined __USE_BSD || defined __USE_ISOC99 || defined __USE_XOPEN \
    || defined __USE_POSIX2
__USING_NAMESPACE_STD(FILE)
#endif

# define __FILE_defined 1
#endif /* FILE not defined.  */
#undef  __need_FILE


#if !defined ____FILE_defined && defined __need___FILE

/* The opaque type of streams.  This is the definition used elsewhere.  */
typedef struct _IO_FILE __FILE;

struct _IO_FILE {
int _flags; /* High-order word is _IO_MAGIC; rest is flags. */
#define _IO_file_flags _flags

/* The following pointers correspond to the C++ streambuf protocol. */
/* Note: Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
char* _IO_read_ptr; /* Current read pointer */
char* _IO_read_end; /* End of get area. */
char* _IO_read_base; /* Start of putback+get area. */
char* _IO_write_base; /* Start of put area. */
char* _IO_write_ptr; /* Current put pointer. */
char* _IO_write_end; /* End of put area. */
char* _IO_buf_base; /* Start of reserve area. */
char* _IO_buf_end; /* End of reserve area. */
/* The following fields are used to support backing up and undo. */
char *_IO_save_base; /* Pointer to start of non-current get area. */
char *_IO_backup_base; /* Pointer to first valid character of backup area */
char *_IO_save_end; /* Pointer to end of non-current get area. */

struct _IO_marker *_markers;

struct _IO_FILE *_chain;

int _fileno;
#if 0
int _blksize;
#else
int _flags2;
#endif
_IO_off_t _old_offset; /* This used to be _offset but it's too small. */

#define __HAVE_COLUMN /* temporary */
/* 1+column number of pbase(); 0 is unknown. */
unsigned short _cur_column;

signed char _vtable_offset;
char _shortbuf[1];

/* char* _save_gptr; char* _save_egptr; */

_IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};

這個_IO_FILE結構體中的“int _fileno”就是fd，即檔案描述符。

這個可以通過程式驗證：

#include<stdio.h>
#include<stdlib.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<unistd.h>

int main(){
        char buf[50] = {"file descriptor demo"};
        FILE *myfile;

        myfile = fopen("test","w+");
        if(!myfile){
                printf("error: openfile failed!\n");
        }
        printf("The openfile's descriptor is %d\n", myfile->_fileno);
        if(write(myfile->_fileno,buf,50)<0){
                perror("error: write file failed!\n");
                exit(1);
        }else{
                printf("writefile successed!\n");
        }

        exit(0);
}

編譯：g++ fileno.cpp -o fileno.out
執行+輸出：

[[email protected] linuxC]# ./fileno.out 
The openfile's descriptor is 3
writefile successed!

檢視test檔案：

[root@zhuzhonghua2-fqawb linuxC]# cat test
file descriptor demo

參考資料

歡迎支援《RabbitMQ實戰指南》以及關注微信公眾號：朱小廝的部落格。