据我所知,fclose()基本上类似于分配内存时的free(),但我也读到,操作系统会为您关闭该文件,并在其终止后立即清除所有打开的流。我甚至在没有使用fclose()的情况下测试了几个程序,它们似乎都工作得很好。
发布于 2015-11-09 05:28:14
长时间运行的进程(例如数据库或web浏览器)可能需要在其生命周期内打开许多文件;保持未使用的文件处于打开状态会浪费资源,并可能锁定其他进程,使其无法使用这些文件。
此外,fclose会刷新在写入文件时经常使用的用户空间缓冲区,以提高性能;如果进程退出时没有刷新该缓冲区(使用fflush/fclose),则仍在缓冲区中的数据将丢失。
发布于 2015-11-09 05:32:36
大多数现代的OSes也会回收你malloc()的内存,但是在合适的时候使用free()仍然是一个很好的做法。要点是,一旦你不再需要一个资源,你就应该放弃它,这样系统就可以重新利用任何被回收以供其他应用程序使用的后备资源(通常是内存)。此外,你可以同时打开的文件描述符的数量也有限制。
除此之外,在open()和朋友的情况下还有更多的考虑因素,特别是在默认情况下,打开的文件描述符是跨线程和fork()的进程边界继承的。这意味着如果你无法close()文件描述符,你可能会发现一个子进程可以访问父进程打开的文件。这通常是不可取的,如果你想要一个有特权的父进程产生一个具有较小特权的从属进程,这是一个微不足道的安全漏洞。
此外,unlink()和朋友的语义是,只有当文件的最后一个打开的文件描述符被close()'d时,文件内容才会被‘删除’,所以再次:如果你保持文件打开的时间超过了严格必要的时间,你会导致整个系统中的次优行为。
最后,在套接字的情况下,close()也对应于断开与远程对等体的连接。
https://stackoverflow.com/questions/33599177
复制相似问题