Для 64-битной ОС утечка памяти все еще актуальна?

Question

Если у вас 64-битная ОС, у вас адресное пространство практически неограниченного размера. Мой вопрос таков: имеет ли значение в таких системах освобождение памяти? Даже если у вас есть ограниченная оперативная память, скажем, 4 ГБ, в схеме подкачки по требованию (память, которую вводят только при прикосновении), небольшие накладные расходы, которые вы получите по сравнению с освобождением памяти, - это несколько дополнительных перестановок страниц, которые, как я полагаю, будут не трогать в течение длительного времени, будет автоматически поменяться местами. Я что-то здесь упускаю? Или мой аргумент действителен?

Практически, если это не сильно ухудшает производительность, то, я думаю, это хорошо для программистов на C / C ++, так как утечка памяти больше не будет важной проблемой для решения!

Answer 1

накладные расходы ... это несколько дополнительных перестановок страниц ... так как память ... будет автоматически заменена

Автоматически поменяться местами? Эфир? Файлы страниц конечны, как и хранилище, в котором они существуют.

Считаете ли вы хорошей идеей никогда не освобождать память в долго работающем сервисном приложении?

Answer 2

Я думаю, что ключевое слово здесь «виртуально», определение которого сводится к «нет, на самом деле». У вас есть пространство памяти, которое на самом деле не ограничено. Все, что действительно изменилось с ростом доступности памяти, - это область применения приложения, с которым вы можете позволить себе бездушно относиться к управлению памятью.

Другими словами, если вы пишете «Hello World», то, конечно, вы можете оставить свой мусор памяти на месте. В наши дни вы могли бы , вероятно, уйти с небольшим приложением, которое не управляло собственной памятью. Но если вы напишите драйвер устройства или сервисный демон, который будет работать так же долго, как и операционная система ... ну, я не хочу останавливать рабочий компьютер раз в неделю, чтобы вручную очистить чужую память утечки.

Answer 3

Адресное пространство может показаться практически бесконечным, но физическое хранилище на любом текущем компьютере определенно нет. ОС (любая ОС, не только Linux) не может знать, что приложение выполняется со страницей памяти, если оно явно не освобождено. Для выгруженных страниц по-прежнему требуется место на диске и время CPU + I / O для обработки.

По моему опыту, даже в очень немногих случаях, когда какой-то учтивый маркетолог умел продавать компьютерные системы, которые значительно превышали требования, доступная память все еще стала проблемой через некоторое время.

Кроме того, если вы хотите знать, что произойдет, если приложение перестанет освобождать память, просто взгляните на приложение, которое просто теряет / чрезмерно использует память, а не прямо отказывается освободить ее. Например, Firefox после нескольких часов интенсивной работы с табуляцией скоро превысит 3 ГБ в моей системе на 8 ГБ. Я даже не хочу представить, как высоко это число может пойти без освобождения памяти вообще.

Теперь представьте, о-о, десять приложений делают одно и то же одновременно - у меня нет 30 ГБ физической или виртуальной памяти в моей настольной системе. И если моя система уже работает с одним экземпляром Firefox, я боюсь, что произойдет в предложенном вами сценарии ...

Answer 4

Да, это может быть полезно для инструментов с коротким временем жизни, таких как утилиты командной строки, такие как ls.

Например, Busybox даже имеет параметр конфигурации, который определяет, будет ли free память обычным или позволить ОС автоматически очищать ее при выходе.

FEATURE_CLEAN_UP

Как оптимизация размера, busybox обычно завершается без явного освобождение динамически выделяемой памяти или закрытие файлов. Это экономит пространство, так как ОС очистит нас, но это может запутать отладчики как valgrind, который сообщает о множестве утечек памяти и ресурсов.

Не включайте это, если у вас нет действительно веской причины для очистки все вручную.

Answer 5

Это зависит от приложения.Некоторые приложения выделяют большой лот (например, несколько сотен мегабайт в секунду).Если вы считаете, что вы никогда не освободите это, но используете пространство подкачки, вы заполняете многигабайтный обмен за несколько часов.

См. Огромную литературу о сборке мусора, например, сборка мусорасправочник для начала.

Старая статья Эндрю Аппеля сборка мусора может быть быстрее, чем выделение стека должна дать вам интересные идеи.

Однако вы могли бы рассмотретьсборщик мусора с небольшой утечкой, тогда скорость утечки будет составлять всего несколько мегабайт в минуту (после GC), и ситуация будет иной.

И если рассматривать только недолговечные приложения, утечка памяти действительноменее важно.Но как только у вас будут длительные серверные процессы, вам следует заботиться о памяти, и никогда не освобождать (или повторно использовать) это плохая идея.

Answer 6

Разве это не просто лучший способ очистки памяти, выделенной ранее.

Если все программы прекратят освобождать блок памяти по причинам производительности, вы увидите, что происходит.

Да, это важномного.

Answer 7

Если вы думаете, что худшее, что может случиться, если не free() память - это сбой, вам следует подумать о том, что происходит, когда:

• Вы не можете выделить буфер сокета, и вы должны начать отбрасывать пакеты.
• Вы испытываете снижение производительности (всегда, как всегда, утечка) из-за побоев.
• Возможно, вы больше не можете создавать журналы отладки / диагностики и / или сообщения.
• Вы исчерпали дескрипторы файлов.

Суть в том, освободить выделенную память. Это спасет ваше здравомыслие.

Answer 8

Если у вас 64-битная ОС, у вас адресное пространство практически неограниченного размера

Часть, которую вы, похоже, пропускаете, - это часть virtual.

Прежде всего, вы всегда «ограничены» фактической оперативной памятью, которая у вас есть.

И я имею в виду ограничение следующим образом:
В примере с 4 ГБ, о котором вы упомянули, если ни один процесс не освобождает память и продолжает запрашивать новую память, ОС начнет использовать HD для обмена виртуальными страницами.

У вас будут сбои страниц и доступ к HD, что приведет к значительным накладным расходам на производительность процесса и всей системы, если это произойдет для всех запущенных процессов (следуя подходу, который вы считаете приемлемым).
В результате, чтобы у пользователя была «работоспособная» система, ему пришлось бы покупать все больше и больше оперативной памяти.
Как, по вашему мнению, будет реагировать пользователь, если вы скажете, что ваша система не отвечает, но вам просто нужнокупить больше оперативной памяти, например, 16 ГБ или 32 ГБ или .....