爲什麼文件處理如此昂貴的資源？

Question

在有關垃圾回收是否是好事的神聖戰爭中，人們經常指出，它並不處理諸如釋放文件句柄之類的東西。把這個邏輯放入終結器被認爲是一件壞事，因爲資源會被非確定性地釋放。但是，對於操作系統來說，這似乎是一個簡單的解決方案，可以確保提供大量和大量的文件句柄，以便它們成爲便宜且豐富的資源，並且您可以在任何給定時間浪費一些資源。爲什麼在實踐中沒有這樣做？

Answer 1

關閉文件也會刷新寫入磁盤 - 無論如何，從您的應用程序的角度來看。關閉文件後，應用程序可能會崩潰，只要系統本身不會崩潰，更改就不會丟失。所以讓GC關閉文件並不是一個好主意。即使現在技術上可能也是如此。

另外，說實話，老習慣很難消退。文件句柄過去很昂貴，並且由於歷史原因可能仍被認爲是這樣。

Answer 2

這不僅僅是文件句柄的數量，它有時候在某些模式下使用它們時，可能會阻止其他調用者訪問相同的文件。

Answer 3

我確信會有更全面的答案，但基於我對Windows底層操作的有限經驗和理解，文件句柄（用於表示它們到OS的結構）是內核對象，因此它們需要某種類型的內存可用 - 更不用說在內核部分處理以保持與需要訪問相同資源的多個進程的一致性和一致性（即文件）

Answer 4

我不認爲它們必然很昂貴 - 如果你的應用程序只保留一些不合理的應用程序，它不會殺死系統。就像在C++中只泄漏了幾個字符串一樣，沒有人會注意到，除非他們看起來很小心。當它成爲一個問題是：

• 如果您泄漏數百或數千
• 如果有文件打開阻止在該文件上發生的（其他應用程序可能無法打開或刪除文件）
等操作
• 這是一個不穩定的跡象 - 如果您的程序無法追蹤它擁有的內容，並且正在使用或已停止使用，那麼該程序還會有哪些其他問題？有時候，當一些小的變化或用戶做了一些與以前不同的事情時，一個小小的泄漏就會變成一個大泄漏。

Answer 5

在實踐中，它不能完成，因爲操作系統將不得不分配更多的內存開銷來跟蹤哪些句柄被不同進程使用。在如下所示我將展示存儲在用於一個示例的循環隊列的簡單OS處理結構的一例的C代碼...

 
struct ProcessRecord{ 
    int ProcessId; 
    CPURegs cpuRegs; 
    TaskPointer **children; 
    int *baseMemAddress; 
    int sizeOfStack; 
    int sizeOfHeap; 
    int *baseHeapAddress; 
    int granularity; 
    int time; 
    enum State{ Running, Runnable, Zombie ... }; 
    /* ...few more fields here... */ 
    long *fileHandles; 
    long fileHandlesCount; 
}proc; 

試想一下，文件句柄是一個指針，指向一個整數數組，其中每個整數包含位置（可能是編碼格式），用於將文件存儲在磁盤上的操作系統表的偏移量。

現在想象一下，有多少內存會吃掉並且可能會減慢整個內核，可能會導致不穩定，因爲系統的「多任務」概念會由於必須跟蹤多少文件句柄正在使用中，並提供一種機制來動態增加/減少指向整數的指針，如果操作系統在用戶程序的需求基礎上拋出文件句柄，這可能會減慢用戶程序的效果。

我希望這可以幫助你理解爲什麼它沒有實現，也不切實際。

希望這是有道理的， 最好的問候， 湯姆。

Answer 6

在Linux範例中，套接字是文件描述符。儘快釋放TCP端口有一定的優勢。