假设我的程序中有多个函数需要将数据附加到某个文件。我在程序开头使用全局文件句柄打开文件，这样我就可以在需要的地方附加到它。 （请注意，我知道我可以将文件句柄作为参数传递给函数，但这不是这个问题的目的）。在程序开始时打开文件句柄，然后在程序结束时关闭它是否不好？或者最好有一个函数 void AppendFile(char *data_to_append); 然后打开文件并附加到它并在同一个函数中关闭它？如果程序死掉，FD 仍然会被使用，这是我看到的唯一不好的事情，但同时，如果您使用该函数，您将打开和关闭同一个文件数百次。
Lets say there are multiple functions throughout my program that need to append data to a certain file. I open the file at the beginning of the program with a global file handle so I can append to it wherever I need to. (Note that I know I could pass the file handle as an argument to the functions but that is not the purpose of this question). Is it bad to open the file handle at the beginning of a program, and then close it at the end; or is it better to have a function say void AppendFile(char *data_to_append); and then open the file and append to it and close it in this same function? If the program dies the FD would still be in use is the only bad thing I see, but at the same time you are opening and closing the same file hundreds and hundreds of times if you use the function.
发布评论
评论（7）
您可能最好执行一次开仓和一次平仓。不停的打开/关闭会导致大量的IO浪费。
您可能希望使用互斥锁来保护此函数，以便一次只有一个线程可以写入文件句柄。
请确保最终关闭文件。
You are probably best to do a single open and a single close. Opening/Closing non stop will lead to a lot of wasted IOs.
You will probably want to protect this function though with a mutex so only one thread can be writing to the file handle at a time.
Do make sure that you close your file though eventually.
如果你的程序是单线程的，那就没问题。如果它在文件句柄打开时终止，则无论如何它都可能被操作系统关闭。如果不是，如何保证它不会在 AppendFile 函数中消失？
我建议你做一下 AppendFile 函数。它将简化写入过程，并且您将能够比散布一堆 fwrite() 更轻松地更改有关文件句柄的内容。
If your program is single threaded, it's okay. If it dies while the file handle's open, it may be closed by the operating system anyway. If it isn't, what's to guarantee it won't die inside your AppendFile function?
I'd suggest you do make that AppendFile function though. It will simplify the write process and you'll be able to change things about the file handle more easily than with a bunch of fwrite()s sprinkled about.
取决于您对文件不被破坏或丢失数据的关心程度。如果程序崩溃，则无法保证所有尚未完成的写入（不仅仅是完成，而是刷新并提交到磁盘）会发生什么。如果有未提交的写入，它们可能会被丢弃或完成一半。关闭文件可以保证这些写入得到提交。
如果写入不频繁，则 open/append/close 是一个更好的主意（IMO）——但是 AppendFile 可以与已经打开的文件句柄一起使用，因此实际上无论哪种方式都可以更好地工作。
除此之外，如果您完全使用线程，您不希望随机写入文件——您希望有某种方法来同步它们。使用 AppendFile 或类似的函数可以为您提供同步点 - 您可以在其中添加代码以等待另一个线程完成。当您在一百个不同的地方直接写入文件时，请尝试这样做。
Depends on how much you care about your file not getting trashed or losing data. If the program crashes, there's no guarantee about what happens to all the writes that haven't been finished (not just done, but flushed and committed to disk) yet. If there are uncommitted writes, they could be tossed out or half-done. Closing the file guarantees those writes get committed.
If the writes will be infrequent, open/append/close is a better idea IMO -- but
AppendFilecould be made to work with an already open file handle, so it actually works better either way.Add to that, if you use threads at all, you don't want random writes to the file -- you want to have some way to synchronize them. Having an
AppendFileor similar function gives you that synchronization point -- you can add code in there to wait til another thread's finished. Just try doing that when you're directly writing to the file in a hundred different places.有时数据库是文本文件的一个非常好的替代品，特别是当数据库专门设计用于首先替代文本文件时:)
看看 SQLite ( http://www.sqlite.org/ ）。
Sometimes a database is a very good substitute for text files, expecially when the database was specifically designed to replace text files in the first place :)
Take a look at SQLite ( http://www.sqlite.org/ ).
全局变量通常不是一件好事。对于小程序来说这并不重要。
在仍然使用全局文件句柄时，请考虑仅通过 void AppendFile(char *data_to_append); 函数访问它，其中只有
AppendFile引用全局文件，而不是分散它遍布你的代码。如果经常访问文件，则每次访问时打开/关闭文件可能会非常耗时。
此外，当程序结束（终止或正常退出）时，文件句柄通常会关闭，因此如果程序崩溃，您不会泄漏任何内容。
global variables are usually not a good thing. For small programs it's doesn't matter though.
While still using a global file handle, consider accessing it only through a
void AppendFile(char *data_to_append);function, where onlyAppendFilereferences the global file, instead of scattering it all over your code.Opening/closing a file on every access can be a vaste if the file is accessed often.
Also, file handles are normally closed when your program ends (either dies, or exits normally), so you're not leaking anything if your program crashes.
是的。
这不是最有帮助的答案，但恐怕您的问题太笼统和模糊，无法为您提供任何详细信息。如果您可以访问分散在程序中的该 FD，则表明您的高层设计存在问题。这些单独的访问是否以某种方式相互关联？它们可以组合成更少数量的访问文件的点吗？您的程序中是否有某种隐含的数据结构，可以更好地在类中实现？
Yes.
Not the most helpful answer but I'm afraid that your question is too general and vague to give you anything detailed. If you have accesses to this FD scattered through your program then it suggests there is something wrong with your high-level design. Are these separate accesses related to each other in some way? Could they be combined into a smaller number of points that access the file? Do you have some kind of implied data-structure in your program that would better implemented in a class?
如果文件句柄指的是 FILE * ，那么只要您使用单个 stdio 进行写入，即使有多个线程，在开头打开并在结尾处关闭的大量用户也应该按预期工作POSIX 系统上的函数调用。
如果文件句柄是指操作系统的 open 调用返回的整数，那么这些文件通常在对 write （或类似）的单个调用中是线程安全的，因为操作系统在将数据传输到与该文件关联的缓冲区。
如果程序是单线程应用程序，那么您不必担心任何一种情况。
如果您要重复打开、追加和关闭文件，如果在多个线程中使用 stdio 的
FILE *或以某种方式调用AppendFile，您可能会遇到麻烦递归地，因为不同的 FILE * 不会在应用程序内共享缓冲区，因此当一个线程中的文件发生更改时，其他线程可能会覆盖这些更改。os 文件句柄（由 open 返回的整数）也会发生类似的情况，因为对
open的不同调用将产生不同的文件句柄，并且不会共享它们的查找位置，因此随着文件的增长，不同的文件描述符最终的查找位置实际上并不在文件末尾，除非您可以在仅附加模式（O_APPEND）中打开文件，操作系统会为您处理此问题。无论哪种方式，一遍又一遍地打开和关闭文件确实会产生大量额外的工作。
If by file handle you mean a
FILE *then opening at the beginning and closing at the end with lots of users should work as expected even if there are multiple threads as long as you do your writes with single stdio function calls on POSIX systems.If by file handle you mean an integer returned by the operating system's open call then these are usually thread safe within a single call to
write(or similar) since the operating system will lock the file while transferring data to buffers associated with that file.If the program is a single threaded application then you don't have much to worry about either way.
If you were to go with repeatedly opening, appending, and closing the file you could run into trouble if using stdio's
FILE *with multiple threads or if calls toAppendFilewere somehow made recursively because the differentFILE *s would not share buffers within the application and so as the file changed in one thread other threads might overwrite those changes.A similar thing can happen with os file handles (integers returned by open) since the different calls to
openwill produce different file handles with will not share their seek position, so as the file grew the different file descriptors would end up with seek positions that weren't actually at the end of the file unless you can open the file in append only mode (O_APPEND) where the OS handles this for you.Opening and closing the file over and over does generate a lot of extra work, either way.