由于内存耗尽而从NULL == malloc()恢复的策略

Question

阅读Martin Sustrick撰写的有关在C++中防止"未定义行为"的问题的博客,特别是由于内存耗尽而导致malloc()失败的问题,我被提醒了很多次,我很沮丧地知道是什么在这种情况下做.

对于虚拟系统来说,这种情况很少见,但是在嵌入式平台上,或者在击中虚拟系统时伴随着性能下降等同于失败的情况,正如Martin对ZeroMQ的情况一样,我决定找到一个可行的解决方案,并且做到了.

我想向StackOverflow的读者询问他们是否尝试过这种方法,以及他们使用它的经验.

解决方案是在程序开始时调用malloc()从堆中分配一块备用内存,然后使用该备用内存池来避免内存耗尽.这个想法是为了防止投降有利于有序撤退(我正在阅读Kesselring昨晚对意大利的辩护的说法),其中错误信息和IP套接字等工作时间足够长(希望)至少告诉用户发生了什么.

#define SPARE_MEM_SIZE (1<<20)  // reserve a megabyte
static void *gSpareMem;

// ------------------------------------------------------------------------------------------------
void *tenacious_malloc(int requested_allocation_size)   {
    static int remaining_spare_size = 0;    // SPARE_MEM_SIZE;
    char err_msg[512];
    void *rtn = NULL;

    // attempt to re-establish the full size of spare memory, if it needs it
    if (SPARE_MEM_SIZE != remaining_spare_size) {
        if(NULL != (gSpareMem = realloc(gSpareMem, SPARE_MEM_SIZE))) {
            remaining_spare_size = SPARE_MEM_SIZE;
            // "touch" the memory so O/S will allocate physical memory
            meset(gSpareMem, 0, SPARE_MEM_SIZE);
            printf("\nSize of spare memory pool restored successfully in %s:%s at line %i :)\n",
                            __FILE__, __FUNCTION__, __LINE__);
        }   else   {
            printf("\nUnable to restore size of spare memory buffer.\n");
        }
    }
    // attempt a plain, old vanilla malloc() and test for failure
    if(NULL != (rtn = malloc(requested_allocation_size))) {
        return rtn;
    }   else  {
        sprintf(err_msg, "\nInitial call to malloc() failed in %s:%s at line %i",
                                                __FILE__, __FUNCTION__, __LINE__);
        if(remaining_spare_size < requested_allocation_size)    {
            // not enough spare storage to satisfy the request, so no point in trying
            printf("%s\nRequested allocaton larger than remaining pool. :(\n\t --- ABORTING --- \n", err_msg);
            return NULL;
        }   else   {
            // take the needed storage from spare memory
            printf("%s\nRetrying memory allocation....\n", err_msg);
            remaining_spare_size -= requested_allocation_size;
            if(NULL != (gSpareMem = realloc(gSpareMem, remaining_spare_size))) {
                // return malloc(requested_allocation_size);
                if(NULL != (rtn = malloc(requested_allocation_size))) {
                    printf("Allocation from spare pool succeeded in %s:%s at line %i :)\n",
                                            __FILE__, __FUNCTION__, __LINE__);
                    return rtn;
                }   else  {
                    remaining_spare_size += requested_allocation_size;
                    sprintf(err_msg, "\nRetry of malloc() after realloc() of spare memory pool "
                        "failed in %s:%s at line %i  :(\n", __FILE__, __FUNCTION__, __LINE__);
                    return NULL;
                }
            }   else   {
                printf("\nRetry failed.\nUnable to allocate requested memory from spare pool. :(\n");
                return NULL;
            }
        }
    }   
}
// ------------------------------------------------------------------------------------------------
int _tmain(int argc, _TCHAR* argv[])    {
    int     *IntVec = NULL;
    double  *DblVec = NULL;
    char    *pString = NULL;
    char    String[] = "Every good boy does fine!";

    IntVec = (int *) tenacious_malloc(100 * sizeof(int));
    DblVec = (double *) tenacious_malloc(100 * sizeof(double));
    pString = (char *)tenacious_malloc(100 * sizeof(String));

    strcpy(pString, String);
    printf("\n%s", pString);


    printf("\nHit Enter to end program.");
    getchar();
    return 0;
}

Answer 1

最好的策略是以无需分配即可运行的代码为目标。特别是，对于正确、健壮的程序，所有故障路径都必须是无故障情况的，这意味着您不能在故障路径中使用分配。

我的偏好是，只要有可能，就避免在操作开始后进行任何分配，而是在操作开始之前确定所需的存储并全部分配。这可以极大地简化程序逻辑并使测试变得更加容易（因为您必须测试可能存在的单点故障）。当然，在其他方面也可能会更贵；例如，您可能必须对输入数据进行两次传递才能确定需要多少存储空间，然后使用该存储空间对其进行处理。

关于预先分配一些紧急存储以在malloc失败时使用的解决方案，基本上有两个版本：

1. 只需调用free紧急存储，然后希望malloc之后能再次工作。
2. 遍历您自己的包装层，了解包装层可以直接使用紧急存储而无需释放它的所有内容。

第一种方法的优点是，即使标准库和第三方库代码也可以利用紧急空间，但它的缺点是释放的存储空间可能会被其他进程或您自己进程中的线程窃取，从而争夺它。如果您确定内存耗尽将来自耗尽虚拟地址空间（或进程资源限制）而不是系统资源，并且您的进程是单线程的，则不必担心竞争，并且可以相当安全地假设这种方法会起作用。不过，总的来说，第二种方法要安全得多，因为你有绝对的保证可以获得所需的应急存储量。

我不太喜欢这两种方法，但它们可能是您能做的最好的方法。