dsi*_*cha 6 garbage-collection operating-system file resource-management
在关于垃圾收集是否是一件好事的神圣战争中,人们经常指出它不处理释放文件句柄之类的事情.将此逻辑放在终结器中被认为是一件坏事,因为资源会被非确定性地释放.然而,似乎一个简单的解决方案是操作系统只需要确保有大量的文件句柄可用,这样它们就是一种廉价而丰富的资源,你可以在任何给定的时间浪费一些.为什么这不是在实践中完成的?
实际上,它无法完成,因为操作系统必须分配更多的内存开销来跟踪不同进程正在使用哪些句柄.在如下所示的示例C代码中,我将演示一个存储在循环队列中的简单OS过程结构,以示例...
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是一个指向整数数组的指针,每个整数都包含位于操作系统表中磁盘存储位置的偏移量的位置(可能采用编码格式).
现在想象一下,由于不得不跟踪正在使用的文件句柄的数量,因为系统的"多任务"概念会失效,因此会占用多少内存并且可能会减慢整个内核的速度,从而导致系统不稳定.并且提供一种动态增加/减少指向整数的指针的机制,如果操作系统在用户程序的需求基础上抛出文件句柄,则可能在减慢用户程序时产生连锁效应.
我希望这可以帮助您理解为什么它没有实现也不实用.
希望这是有道理的,最好的问候,汤姆.
关闭文件也会将写入内容刷新到磁盘 - 无论如何,从应用程序的角度来看。关闭文件后,应用程序可能会崩溃,只要系统本身不崩溃,更改就不会丢失。因此让 GC 随意关闭文件并不是一个好主意。即使现在技术上可能是可行的。
而且,说实话,旧习难改。文件句柄曾经很昂贵,并且由于历史原因仍然可能被认为是昂贵的。
| 归档时间: |
|
| 查看次数: |
1035 次 |
| 最近记录: |