为什么文件句柄是如此昂贵的资源？
在关于垃圾收集是否是一件好事的圣战中，人们经常指出它不处理诸如释放文件句柄之类的事情。将此逻辑放入终结器被认为是一件坏事，因为资源随后会被不确定地释放。然而，对于操作系统来说，一个简单的解决方案似乎是确保有大量的文件句柄可用，这样它们就成为廉价且丰富的资源，并且您可以在任何给定时间浪费一些文件句柄。为什么在实践中没有这样做？
In holy wars about whether garbage collection is a good thing, people often point out that it doesn't handle things like freeing file handles. Putting this logic in a finalizer is considered a bad thing because the resource then gets freed non-deterministically. However, it seems like an easy solution would be for the OS to just make sure lots and lots of file handles are available so that they are a cheap and plentiful resource and you can afford to waste a few at any given time. Why is this not done in practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
实际上，这是不可能完成的，因为操作系统必须分配更多的内存开销来跟踪不同进程正在使用哪些句柄。在如下所示的示例 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;想象一下 fileHandles 是一个指向整数数组的指针，其中每个整数包含位置（可能采用编码格式）用于在磁盘上存储文件的操作系统表中的偏移量。
现在想象一下，会消耗多少内存并可能减慢整个内核的速度，可能会带来不稳定，因为系统的“多任务”概念将由于必须跟踪正在使用的文件句柄而失败。并提供一种动态增加/减少整数指针的机制，如果操作系统根据用户程序的需求分发文件句柄，则可能会产生连锁反应，减慢用户程序的速度。
我希望这可以帮助您理解为什么它没有实施或不实用。
希望这是有道理的，
此致，
汤姆.
In practice, it cannot be done because the OS would have to allocate a lot more memory overhead for keeping track of which handles are in use by different processes. In an example C code as shown below I will demonstrate a simple OS process structure stored in a circular queue for an example...
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;Imagine that fileHandles is an pointer to an array of integers which each integer contains the location (perhaps in encoded format) for the offset into the OS's table of where the files are stored on disk.
Now imagine how much memory that would eat up and could slow down the whole kernel, maybe bring about instability as the 'multi-tasking' concept of the system would fall over as a result of having to keep track of how much filehandles are in use and to provide a mechanism to dynamically increase/decrease the pointer to integers which could have a knock on effect in slowing down the user program if the OS was dishing out file handles on a user program's demand basis.
I hope this helps you to understand why it is not implemented nor practical.
Hope this makes sense,
Best regards,
Tom.
关闭文件也会将写入内容刷新到磁盘 - 无论如何，从应用程序的角度来看。关闭文件后，应用程序可能会崩溃，只要系统本身不崩溃，更改就不会丢失。因此让 GC 随意关闭文件并不是一个好主意。即使现在技术上可能是可行的。
而且，说实话，旧习难改。文件句柄曾经很昂贵，并且由于历史原因仍然可能被认为是昂贵的。
Closing a file also flushes the writes to disk -- well, from the point of view of your application anyway. After closing a file, the application can crash, as long as the system itself doesn't crash the changes will not be lost. So it's not a good idea to let the GC close files at its leisure. Even if it may be technically possible nowadays.
Also, to tell the truth, old habits die hard. File handles used to be expensive and are still probably considered as such for historical reasons.
这不仅仅是文件句柄的数量，有时当它们在某些模式下使用时，它们可以阻止其他调用者访问同一文件。
It's not just the amount of file handles, it's that sometimes when they're used in some modes, they can prevent other callers from being able to access the same file.
我确信将会出现更全面的答案，但基于我有限的经验和对 Windows 底层操作的理解，文件句柄（用于向操作系统表示它们的结构）是内核对象，因此它们需要某种类型的内存可用 - 更不用说在内核部分进行处理以保持与需要访问相同资源（即文件）的多个进程的一致性和连贯性
I'm sure more comprehensive answers will ensue, but based on my limited experience and understanding of the underlying operation of Windows, file handles (the structures used to represent them to the OS) are kernel objects and as such they require a certain type of memory to be available - not to mention processing on the kernel part to maintain consistency and coherence with multiple processes requiring access to the same resources (i.e. files)
我认为它们不一定很昂贵 - 如果您的应用程序仅打开一些不必要的应用程序，则不会杀死系统。就像如果你在 C++ 中只泄漏了几个字符串，没有人会注意到，除非他们看得非常仔细。问题在于：
I don't think they're necessarily expensive - if your application only holds a few unnessary ones open it won't kill the system. Just like if you leak only a few strings in C++ no one will notice, unless they're looking pretty carefully. Where it becomes a problem is:
在 Linux 范例中，套接字是文件描述符。尽快释放 TCP 端口确实有好处。
In the Linux paradigm sockets are file descriptors. There are definite advantages to freeing up TCP ports as soon as possible.