有没有办法确定 free() 是否会失败？

Question

有没有办法确定如果在某个内存块指针上调用 free() 是否会失败？

我遇到以下情况：访问共享资源的线程失败而它可能处于释放所述资源的状态。现在我需要设计一种安全的方法来清理这个共享资源。

当然，我已经为正常情况分配了资源的所有权，但是上述极限情况又如何呢？

更新：如果我使用额外的同步机制，它只会需要做更多的清理工作，并且可能涉及额外的限制条件。如果可能的话，我想限制/避免这些。

解决方案：我最终决定进行重构。感谢所有贡献者。你们摇滚！

Answer 1

我见过各种各样的尝试，包括这个：

void m_free(void **p)
{
        if (*p != NULL) {
                free(*p);
                *p = NULL;
        }
}

取消引用类型双关指针不仅会破坏各种平台，而且只有在初始化、释放和重新初始化每个现有的每个指针时，“插入此示例”才能起作用。函数（包括编译的库）并使用具有相同功能的 C 库。

然后，处理优化和无锁线程安全问题。呸！

简而言之，如果您无法跟踪在单个函数中分配的内容，那么是时候重构该函数了。做得足够多......你会发现对更安全的 free() 的需求很快就消失了。如果 Valgrind 在它支持的平台上工作，那么它就是您的朋友。根据你的标签，它确实是你的朋友:)

或者，使用 malloc()进行垃圾收集需要您自费，具体取决于您如何分配事物并完全摆脱 free() 。之后，调试几乎变得非常有趣。

希望您要进行重构吗？虽然您似乎也遇到了互斥问题，但它只会导致重构。即，让 free() 之前的行阻塞，或者在尝试获取锁时失败......并在具有锁的线程中将释放的指针设置为 NULL，至少在您实现的结构中。

Answer 2

我不相信有一个符合您要求的界面。

不过，我可以想到一些技巧。您可以让容易失败的线程调用 free() 的包装器，而不是直接调用 free() ；包装器可以保存地址或最后几个地址，以便您可以确定该块是否被释放。您还可以阻止信号、建立临界区或处理任何可能中断*线程的事情。

更新：垂死的线程在退出/清理之前是否释放过该内存？我经常为不需要在稳定状态下释放的内存编写 malloc 前端（作为速度优化）。如果线程只是自行设置，则可以在线程启动之前分配内存，并让线程调用前端，该前端仅分发动态块中未链接的、不可释放的部分。它会运行得更快，然后当线程终止时，您可以立即释放整个块。这里的总体想法是让容易失败的线程通过调用可以事后清理的服务来获取其内存。

还有一个想法：每线程堆怎么样？如果可以说服线程从自己的堆中分配仅在其生命周期内所需的内存，那么可以很好地组织清理任务，以便在线程重新加入父级时释放整个线程堆。

Answer 3

我认为没有办法完全按照你的要求去做。

问题在于，无法确定正在死亡的线程死亡时处于什么状态。它是否只是简单地调用了 free() 就不再继续了？ free() 是否将该块添加回空闲列表？你说不出来。

---

如果线程以这种方式终止的情况非常罕见（因此可以保留未释放的内存 - 您只是想知道不要使用它），那么以下（使用 Windows 调用）会释放内存并“标记” ' 它对其他线程来说是免费的：

void* ptr;
...
void* desiredPtr = ptr;
if(InterlockedCompareExchangePointer(&ptr, NULL, desiredPtr) == desiredPtr)
  free(desiredPtr);

它的作用是确保只有一个线程正在尝试释放内存，并且在释放内存之前将地址设置为 NULL，这样其他线程就不会尝试 free() 它。

---

如果偶尔保留内存是不可接受的，那么最好的方法可能是使用一个单独的线程，其唯一的工作就是释放内存。然后，其他线程可以将空闲内存线程的空闲请求排队。由于释放内存线程非常简单，因此它永远不会死亡并且可以正确完成释放操作。

Answer 4

如果您使用有效指针调用free，我不知道它会如何失败。如果失败，则一定是由于指针无效。

除了同步对共享内存的访问（例如使用互斥体）之外，所有权还必须是也清除以避免诸如双重释放之类的情况。双重释放是指两个或多个线程拥有有效指针，但随后多个线程尝试释放内存。尽管第二个线程具有非空指针，但它不再有效。

如果您在 C/C++ 中遇到内存问题，您可以尝试使用内存库，例如 HeapAgent 。像这样的内存库将检测并初始化每个内存分配。在释放内存之前，它首先检查内存指针是否有效以及是否存在缓冲区溢出错误。不应该有任何代码更改，因为它可以简单地替换内置的 malloc/free。此外，该库还可以帮助查找内存泄漏、覆盖和无效引用。

解决问题的另一种策略可能是将资源清理集中到一个线程。当线程使用完资源后，它只是将其标记为可供垃圾收集器线程清理。

当然，还有C计划——使用Java……开玩笑。