Почему этот код не вызывает утечку памяти?
Я хотел симулировать утечку памяти в моем приложении. Я пишу следующий код, и попытался увидеть в Perfmon.
int main()
{
int *i;
while(1)
{
i = (int *) malloc(1000);
//just to avoid lazy allocation
*i = 100;
if(i == NULL)
{
printf("Memory Not Allocated\n");
}
Sleep(1000);
}
}
Когда я вижу использованную память в диспетчере задач, это колебаться между 52К и 136К, но не выходя за рамки этого. Значит, что-то показывает 52K, а иногда 136K, я не понимаю, как этот код однажды переходит к 136K, возвращается к 52K и не выходит за рамки этого.
Я пытался использовать Perfmon, но не в состоянии точно, что увидеть в Perfmon, снимок счетчиков,
Подскажите пожалуйста, как симулировать утечку памяти и как ее обнаружить.
Решение
Строго говоря, утечка памяти немного зависит от контекста: что-то в вашей программе постоянно выделяет память и не освобождает ее, когда это должно было быть освобождено.
Ваш код вызывает «утечку» при каждом последующем прохождении цикла while, потому что ваша программа теряет знание о ранее выделенном указателе в этой точке. Это видно только при осмотре, однако в этом случае; Судя по опубликованному коду, похоже, что вы на самом деле делаете, хотя и очень медленно, попытку создать стрессовую ситуацию с памятью.
Чтобы «найти» утечку без проверки, вам нужно запустить такой инструмент, как Valgrind (Unix / Linux / OSX) или в Visual Studio включить отслеживание распределения с макросом DEBUG_NEW и просмотрите выходные данные с помощью отладчика.
если ты действительно хочу поторопить память в спешке, выделять 1024 x 1024 x 1024 байта за раз …
Другие решения
Хотя ОС может откладывать фактическое выделение динамически распределенной памяти до тех пор, пока она не будет использована, оптимизатор компилятора может исключить выделения, которые только записываются и никогда не считываются. Поскольку ваши записи не имеют четко определенного наблюдаемого поведения (вы никогда не читаете из него), компилятор вполне может их оптимизировать. Я бы предложил изучить сгенерированный код сборки, чтобы увидеть, что на самом деле генерирует компилятор. На самом деле, это должно быть одним из первых шагов при ответе на вопросы типа «почему этот код не ведет себя так, как я думаю?».