這裡我們先區分好兩個概念：檔案描述符和檔案控制代碼
簡單來說，每個程序都有乙個開啟的檔案表（fdtable)。表中的每一項是struct file型別，包含了開啟檔案的一些屬性比如偏移量，讀寫訪問模式等，這是真正意義上的檔案控制代碼。
檔案描述符是乙個整數。代表fdtable中的索引位置（下標），指向具體的struct file（檔案控制代碼）。
哪些地方會分配檔案控制代碼？
知道檔案控制代碼最終是通過get_empty_filp函式從filp cache中分配的之後，我們順著函式呼叫鏈路簡單梳理下，就能知道有哪些地方會分配檔案控制代碼了：
file-nr檔案裡面的第乙個字段代表的是核心分配的struct file的個數，也就是檔案控制代碼個數，而不是檔案描述符
機器上的常常會出現檔案控制代碼使用量與常用的lsof命令的數量相去甚遠的情況
因為檔案描述符和檔案控制代碼是兩個不同的東西：lsof在使用者空間，主要還是從檔案描述符的角度來看檔案控制代碼。
我們來做乙個實驗：只開啟一次檔案，然後複製1000次檔案描述符。
我們啟動dupfd程序開啟了一次/dev/zero檔案，複製了1000次檔案描述符。file-nr中的檔案控制代碼數只是個位數的變化，而lsof看到的結果漲了1000多。
如果我們把前面的**換成open 1000次， 就可以看到file-nr和lsof的輸出幾乎都漲了1000。
我們迴圈1000次開啟/dev/zero檔案，之後mmap對映到程序位址空間，然後把這些開啟的檔案描述符都關掉。很顯然，開啟的描述符都被close掉了，不會有什麼變化。 那為什麼檔案控制代碼數還是增加了1000個左右呢？
原來，linux核心中很多物件都是有引用計數的。 雖然檔案控制代碼是由open先開啟的，但mmap之後，引用計數被加1，儘管我們接著把檔案描述符close掉了，但是底層指向的struct file由於引用數大於0，不會被**。
通過上面兩個例子，你應該知道lsof的輸出和實際的檔案控制代碼數有差距的原因了。
檔案控制代碼 檔案描述符
檔案控制代碼和檔案描述符 在我們跨平台開發的時候，經常會碰到這倆個概念 檔案描述符 本質上是乙個索引號 非負整數 系統使用者層可以根據它找到系統核心層的檔案資料。這是乙個posix標準下的概念，常見於linux系統。但windows也有檔案描述符這個概念，但不常用。檔案控制代碼 windows下的概...
檔案控制代碼 檔案描述符
由於程序級檔案描述符表的存在，不同的程序中會出現相同的檔案描述符，它們可能指向同乙個檔案，也可能指向不同的檔案。兩個不同的檔案描述符，若指向同乙個開啟檔案控制代碼 file 將共享同一檔案偏移量。因此，如果通過其中乙個檔案描述符來修改檔案偏移量，那麼從另乙個檔案描述符中也會觀察到變化，無論這兩個檔案...
控制代碼和檔案描述符
控制代碼是windows下的概念。控制代碼是windows下各種物件的識別符號，比如檔案 也許叫文件比較合適一點 資源 選單 游標 點陣圖等。檔案控制代碼和檔案描述符類似，它也是乙個非負整數，也用於定位檔案資料在記憶體中的位置。由於linux下所有東西都被看成是檔案，比如檔案 也許叫文件比較合適一點...