静态函数范围指针和内存泄漏

Question

我编写了一个简单的库文件，其中包含从任意大小的文件中读取行的函数。该函数是通过传入堆栈分配的缓冲区和大小来调用的，但如果行太大，则会初始化一个特殊的堆分配的缓冲区并用于传回较大的行。

这个堆分配的缓冲区是函数范围的并声明为静态，当然在开始时初始化为 NULL。我在函数的开头编写了一些检查，以检查堆缓冲区是否为非空；如果是这种情况，则前一行读取的时间太长。当然，我释放堆缓冲区并将其设置回 NULL，认为下一次读取可能只需要填充堆栈分配的缓冲区（即使在我们的应用程序中，也很少会看到超过 1MB 长的行！）。

我仔细阅读了代码并进行了一些测试，并对其进行了相当彻底的测试。我有相当的信心维持以下不变式：

• 如果堆栈缓冲区是所需要的，则函数返回时堆缓冲区将为空（并且不会泄漏任何内存）。
• 如果堆缓冲区不为空，因为需要它，它将在下一个函数调用时释放（并且如果需要在下一行中可能会重用）。

但我想到了一个潜在的问题：如果文件中的最后一行太长，那么由于该函数可能不会再次被调用，所以我不确定是否有任何方法来释放堆缓冲区——它是函数毕竟，是有范围的。

所以我的问题是，如何释放函数范围的静态指针中动态分配的内存，最好不要再次调用该函数？ （理想情况下也不要将其设为全局变量！）

可根据要求提供代码。 （抱歉，我现在还没有访问权限。我希望这个问题足够普遍并且解释得很好，因此不需要它，但无论如何请随意消除我的这个想法！）

---

编辑：我感觉我应该添加一些关于该函数的使用的注释。

此特定函数以从文件中串行读取行的形式使用，然后立即复制到 POD 结构中，每个结构一行。这些结构是在读取文件时在堆上创建的，每个结构都有一个 char 指针，其中包含文件中的一行（其清理版本）。为了使这些持续存在，必须已经发生副本。 （这是许多答案中提出的重大反驳之一 - 哦不，该行需要复制，哦亲爱的我）。

至于多线程，正如我所说，它是设计用于串行使用的。不，它不是线程安全的，但我不在乎。

不过还是谢谢大家的回复！当我有时间时，我会更仔细地阅读它们。目前，我倾向于传递一个额外的指针或重新设计该函数，以便当 fgets 显示 EOF 时，我可能只是在那里构建释放逻辑，并且用户希望不需要担心它。

Answer 1

如果可以更改功能，我建议更改功能界面本身。我知道你花了很多时间调试和测试它，但是你当前的实现存在一些问题：

• 它不是线程安全的，
• 用户无法控制数据，所以如果需要，他必须复制它稍后，很可能在将被 malloc()ed 的缓冲区中，从而抵消在函数中选择性使用 malloc() 所获得的任何优势，
• 最重要的是正如您所发现的，对于很长的最后一行，用户必须采取特殊操作。

您的用户不应该担心您的函数的实现奇怪，他们应该能够“只是使用它”。

除非您出于教育目的而这样做，否则我建议您查看此页面，它有一个“从流中读取任意长的行”的实现，并链接到其他此类实现（每个实现都与其他实现略有不同，因此您应该能够找到您喜欢的实现）。

根据您的编辑，MT 安全不是必需的，并且总是会发生副本。因此，最明显的设计是两者之一：

• 让用户使用 malloc()< 的组合提供一个 char **，它指向您的函数将分配的缓冲区。 /code> 和 realloc() （如果需要）。用户有责任在完成后free()它。这样，用户就不必再次复制数据，因为他可以将指针传递到数据的最终目的地所在的位置。
• 返回由您的函数分配的 char *。同样，用户有责任free()它。

两者几乎是等价的。

对于当前的实现，如果最后一行很长并且不以换行符结尾，则始终可以返回“非文件结尾”。然后，用户将再次调用您的函数，然后您可以释放缓冲区。就我个人而言，我会更高兴有一个功能，它允许我读取尽可能多的行，而不是强迫我转到文件末尾。

Answer 2

除了释放动态分配的缓冲区的困难之外，还有另一个潜在的问题。它不是线程安全的。既然是库函数，那么以后总有可能在多线程环境中使用它。

要求调用函数通过相关的库函数释放缓冲区可能会更好。

Answer 3

如果您使用标准技术来指示文件结束（即让您的读取行函数返回 NULL），那仍然可以。

在这种情况下，在读取最后一行后，将需要再次调用 read-line 函数，以便它可以返回 NULL 来指示已到达文件末尾。在最后一次调用中，您可以释放缓冲区。

Answer 4

立即发生的两个选择：

1. 将指向堆分配的缓冲区的指针设置为静态，但在文件范围内。添加一个（静态）函数来检查它是否不为空，如果不为空则释放它。在程序开始时调用atexit(free_func)，其中free_func是静态函数。您可以使用一些全局设置例程（由 main() 调用）来完成此操作。

2. 不用担心；当您的进程退出时，操作系统会释放堆分配的内存，并且内存泄漏不会累积，因此即使您的程序寿命很长，也不会引发 OOM 异常（除非您有其他错误）。

我假设你的应用程序不是多线程的；在这种情况下，您根本不应该使用静态缓冲区，或者应该使用线程本地数据。

Answer 5

您选择的接口使得这是一个无法解决的问题：

• 客户端不得知道返回值是否指向静态或动态内存。

• 返回值必须指向比调用寿命更长的内存。

• 任何调用都可能是最后一个。

我不知道你为什么对这次泄漏感到困扰。毕竟，如果客户端读取很长的行，对该行执行某些操作，然后在读取下一行之前进行大量计算和分配，那么您仍然有一大块内存未使用，从而堵塞系统。如果这对你来说没问题（在回收内存之前进行任意计算），你可以承认你愿意无限期地保留死内存。

如果您无法忍受泄漏，最简单的方法就是扩大接口，以便客户端可以在客户端使用完内存时通知您的函数。 （现在与客户端的合同规定客户端拥有内存，直到它再次调用您的函数，此时所有权恢复到您的函数。）当然，更改接口意味着

• 添加一个新函数，这需要您将指针提升为静态，但对于编译单元而言是本地的，或者

• 向现有函数添加一些参数（或重载参数），以便您有一个调用，这意味着“我现在已经完成了您的记忆，但我不想要另一个 向现有函数添加

更根本的改变是重写该函数以在其整个生命周期中使用动态分配的内存，根据需要逐渐扩大块，直到它与有史以来读取的最大块一样大（或者可能四舍五入到下一个 2 的幂）。根据实际情况，此策略可能比保留大的静态缓冲区消耗更少的地址空间。

无论如何，我不相信您应该担心这个极端情况。如果您认为此案例很重要，请编辑您的问题以向我们展示证据。

Answer 6

不要给它函数作用域，而是给它模块作用域（即在文件作用域，但是静态的，所以它在该文件之外不可见。添加一个释放缓冲区的小函数，并使用 atexit() 来确保它是或者，不用担心——仅发生一次并在程序退出时自动释放的泄漏并不是特别有害

。然而，当您释放缓冲区时，几乎无法猜测它是否仍在使用中，用户（显然）必须跟踪数据返回的位置，并将数据复制到新的缓冲区。如果（且仅当）您在多线程环境中动态分配一个，则需要使内部指针成为线程本地的，以便有机会正确工作，该函数可能完全执行以下两种操作之一。不同的事情——要么返回用户拥有的缓冲区，要么返回函数拥有的缓冲区，并且只能通过分配另一个缓冲区并在再次调用函数之前将数据复制到另一个缓冲区来安全地使用。

Answer 7

我能想到一些技巧，尽管两者都需要将静态声明移出函数。我无法想象为什么这会成为一个问题。

使用 GCC扩展，

static char *buffer;
void use_buffer(size_t n) {
    buffer = realloc(buffer, n);
}
void cleanup_buffer() __attribute__((destructor)) {
    free(buffer);
}

使用C++，

static char *buffer;
static class buffer_guard {
    ~buffer_guard() { free(buffer); }
} my_buffer_guard;

无论如何，我不太喜欢这个设计。在 C 中，通常调用者负责分配/释放它需要使用的内存，即使它是由被调用者填充的。

顺便说一句，与 Glibc 的非标准 getline 进行比较。它从不使用静态内存。

Answer 8

我本来想在马克的回答下面发表评论，但可能感觉有点局促。不过，这个答案本质上是对他的答案的评论，我发现除了快速之外，它还非常好:)。

您的函数不仅不是 MT 安全的，而且即使没有线程，正确使用它的接口也很复杂。调用者必须先完成先前的结果，然后才能再次调用该函数。如果这个代码两年后仍在使用，有人会摸不着头脑试图正确使用它……或者更糟糕的是，不假思索地使用它就错误了。那人甚至可能是你......

马克的建议（要求调用者释放缓冲区）是恕我直言最合理的。但也许您不相信 malloc 和 free 从长远来看不会导致碎片，或者有其他原因更喜欢静态缓冲区解决方案。
在这种情况下，您可以保留普通长度行的静态缓冲区，定义一个布尔标志来指示静态缓冲区当前是否繁忙，并记录应该调用以下函数（而不是free）当调用者不再使用缓冲区时，使用缓冲区的地址：

char static_buffer[512];
int buffer_busy;

void free_buffer(char *p)
{
  if (p == static_buffer)
  {
     assert(buffer_busy);
     buffer_busy=0;
  }
  else free(p);
}

char *get_line(...)
{
  char *result;
  if (..short line..)
  {
     result = static_buffer;
     assert(!buffer_busy);
     buffer_busy=1;
  }
  else result = malloc(...);
  ...
  return result;
}

触发断言的唯一情况是您以前的实现会默默地出错的情况，并且与您现有的解决方案相比，开销非常低（只需切换标志，并要求调用者在完成后调用 free_buffer，这样更干净）。如果 get_line 中的断言特别触发，则意味着您毕竟需要动态分配，因为调用者在请求另一个缓冲区时无法完成缓冲区。

注意：这仍然不是 MT 安全的。