在关于垃圾收集是否是一件好事的圣战中，人们经常指出它不处理诸如释放文件句柄之类的事情。将此逻辑放入终结器中被认为是一件坏事，因为资源随后会被非确定性地释放。然而，对于操作系统来说，一个简单的解决方案似乎是确保大量文件句柄可用，以便它们是一种廉价而丰富的资源，并且您可以在任何给定时间浪费一些。为什么在实践中不这样做？
问问题
1154 次
6 回答
5
实际上，这是无法做到的，因为操作系统必须分配更多的内存开销来跟踪不同进程正在使用哪些句柄。在如下所示的示例 C 代码中，我将演示一个存储在循环队列中的简单 OS 进程结构，例如...
结构过程记录{
整数进程ID；
CPURegs cpuRegs;
任务指针**孩子；
int *baseMemAddress;
int sizeOfStack;
int sizeOfHeap;
int *baseHeapAddress;
int 粒度；
时间；
枚举状态{正在运行，可运行，僵尸...}；
/* ...这里还有几个字段... */
长*文件句柄；
长文件句柄计数；
}程序;
想象一下，fileHandles 是一个指向整数数组的指针，每个整数都包含偏移量到操作系统表中文件存储在磁盘上的位置的位置（可能是编码格式）。
现在想象一下，有多少内存会耗尽并可能减慢整个内核，可能会带来不稳定，因为系统的“多任务”概念会因为必须跟踪正在使用的文件句柄而崩溃并提供一种机制来动态增加/减少指向整数的指针，如果操作系统根据用户程序的需求提供文件句柄，这可能会在减慢用户程序时产生连锁反应。
我希望这可以帮助您理解为什么它没有实现也不实用。
希望这是有道理的，最好的问候，汤姆。
于 2009-12-05T01:24:06.283 回答
2
这不仅仅是文件句柄的数量，有时当它们在某些模式下使用时，它们可以阻止其他调用者访问同一个文件。
于 2009-12-05T01:11:32.050 回答
2
关闭文件也会刷新对磁盘的写入——好吧，无论如何，从您的应用程序的角度来看。关闭文件后，应用程序可能会崩溃，只要系统本身不崩溃，更改就不会丢失。因此，让 GC 闲暇时关闭文件并不是一个好主意。即使现在在技术上可能是可行的。
而且，说实话，旧习惯很难改掉。文件句柄曾经很昂贵，并且由于历史原因仍然可能被认为是这样。
于 2009-12-05T01:11:53.707 回答
2
我相信会有更全面的答案，但基于我有限的经验和对 Windows 底层操作的理解，文件句柄（用于向操作系统表示它们的结构）是内核对象，因此它们需要某种类型的可用内存 - 更不用说内核部分的处理以保持与需要访问相同资源（即文件）的多个进程的一致性和连贯性
于 2009-12-05T01:14:39.817 回答
1
我认为它们不一定很昂贵 - 如果您的应用程序只打开了一些不必要的应用程序，它不会杀死系统。就像如果你在 C++ 中只泄漏了几个字符串，没有人会注意到，除非它们看起来很仔细。成为问题的地方是：
- 如果您泄漏数百或数千
- 如果打开文件会阻止对该文件进行其他操作（其他应用程序可能无法打开或删除该文件）
- 这是马虎的表现——如果你的程序无法跟踪它拥有的、正在使用的或已经停止使用的东西，那么程序还会有什么其他问题？有时，当一些小变化或用户做的事情与以前略有不同时，小泄漏会变成大泄漏。
于 2009-12-05T01:22:18.277 回答
0
在 Linux 范例中，套接字是文件描述符。尽快释放 TCP 端口有一定的优势。
于 2010-03-04T05:26:32.513 回答