Ручное управление памятью
 | В данной статье поднимается несколько вопросов. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
В информатике ручное управление памятью означает использование программистом ручных инструкций для идентификации и освобождения неиспользуемых объектов или мусора . Вплоть до середины 1990-х годов большинство языков программирования , используемых в промышленности, поддерживали ручное управление памятью, хотя сбор мусора существовал с 1959 года, когда он был представлен вместе с Lisp . Однако сегодня языки со сборкой мусора, такие как Java, становятся все более популярными, а языки Objective-C и Swift предоставляют аналогичную функциональность посредством автоматического подсчета ссылок . Основными языками с ручным управлением, которые до сих пор широко используются, являются C и C++ – см. распределение памяти C. динамическое
Описание [ править ]
Многие языки программирования используют ручные методы, чтобы определить, когда выделить новый объект из свободного хранилища. C использует mallocфункция; C++ и Java используют newоператор; и многие другие языки (например, Python) размещают все объекты из свободного хранилища. Определение того, когда объект должен быть создан ( создание объекта ), как правило, тривиально и несложно, хотя такие методы, как пулы объектов, означают, что объект может быть создан до немедленного использования. Настоящей проблемой является уничтожение объекта : определение того, когда объект больше не нужен (т. е. является мусором), и организация его базового хранилища, которое должно быть возвращено в свободное хранилище для повторного использования. При выделении памяти вручную это также указывается программистом вручную; с помощью таких функций, как free() на языке C или delete оператор в C++ — это контрастирует с автоматическим уничтожением объектов, хранящихся в автоматических переменных , особенно (нестатических) локальных переменных функций, которые уничтожаются в конце их области действия в C и C++.
памятью Методы ручного управления
![[икона]](/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | Этот раздел нуждается в расширении . Вы можете помочь, дополнив это . ( январь 2022 г. ) |
Например
- malloc/бесплатно
- Арена памяти
- рабочий буфер
- ...
Ручное корректность управление и
Известно, что ручное управление памятью приводит к появлению в программе нескольких основных классов ошибок при неправильном использовании, в частности, нарушений безопасности памяти или утечек памяти . Это существенный источник ошибок безопасности .
- Когда неиспользуемый объект никогда не возвращается в свободное хранилище, это называется утечкой памяти . В некоторых случаях утечки памяти могут быть терпимыми, например, программа, которая «утекает» ограниченный объем памяти в течение своего существования, или кратковременная программа, которая полагается на то, что операционная система освобождает свои ресурсы при завершении работы. Однако во многих случаях утечки памяти происходят в долго работающих программах, и в таких случаях происходит утечка неограниченного объема памяти. Когда это происходит, размер доступного бесплатного хранилища продолжает со временем уменьшаться; когда он наконец исчерпан, программа выходит из строя.
- Катастрофический сбой системы управления динамической памятью может произойти, если резервная память объекта будет удалена из-под него более одного раза; объект явно уничтожается более одного раза; когда при использовании указателя для манипулирования объектом, не выделенным в свободной памяти, программист пытается освободить резервную память целевого объекта указанного указателя; или когда, манипулируя объектом через указатель на другую произвольную область памяти, управляемую неизвестной внешней задачей, потоком или процессом, программист искажает состояние этого объекта, возможно, таким образом, что запись выходит за его пределы и повреждает данные управления его памятью. Результатом таких действий может быть повреждение кучи , преждевременное уничтожение другого ( и вновь созданного) объекта, который занимает то же место в памяти, что и многократно удаленный объект, сбой программы из-за ошибки сегментации (нарушение защиты памяти ) и другие формы неопределенного поведения .
- Указатели на удаленные объекты становятся дикими указателями, если используются после удаления; попытка использовать такие указатели может привести к трудно диагностируемым ошибкам.
Известно, что языки, использующие исключительно сборку мусора , избегают двух последних классов дефектов. Утечки памяти все еще могут возникать (и ограниченные утечки часто возникают при поколенческой или консервативной сборке мусора), но обычно они менее серьезны, чем утечки памяти в ручных системах.
Приобретение ресурсов инициализация это —
Ручное управление памятью имеет одно преимущество корректности: оно позволяет автоматически управлять ресурсами с помощью парадигмы сбора ресурсов — инициализации (RAII).
Это возникает, когда объекты владеют ограниченными системными ресурсами (например, графическими ресурсами, дескрипторами файлов или подключениями к базе данных), от которых необходимо отказаться при уничтожении объекта — когда срок владения ресурсом должен быть привязан к сроку существования объекта. Языки с ручным управлением могут организовать это, получая ресурс во время инициализации объекта (в конструкторе) и освобождая его во время разрушения объекта (в деструкторе ) , которое происходит в определенное время. Это известно как инициализация получения ресурсов.
Это также можно использовать с детерминированным подсчетом ссылок . В C++ эта возможность используется для дальнейшего использования для автоматизации освобождения памяти в среде, которая в противном случае выполняется вручную, с использованием метода shared_ptr Шаблон в стандартной библиотеке языка для управления памятью является распространенной парадигмой. shared_ptr Однако он подходит не для всех шаблонов использования объектов.
Этот подход непригоден для большинства языков со сборкой мусора (особенно для трассировки сборщиков мусора или более продвинутого подсчета ссылок) из-за того, что финализация недетерминирована, а иногда и не происходит вообще. То есть трудно определить (или определить), когда и можно ли финализатора вызывать метод ; это широко известно как проблема финализатора . Java и другие языки, использующие сборщик мусора, часто используют ручное управление ограниченными системными ресурсами, помимо памяти, с помощью шаблона удаления : ожидается, что любой объект, который управляет ресурсами, реализует dispose()метод, который освобождает любые такие ресурсы и помечает объект как неактивный. Ожидается, что программисты будут вызывать dispose()вручную, если это необходимо, чтобы предотвратить «утечку» дефицитных графических ресурсов. В зависимости от finalize() метод (как Java реализует финализаторы) для освобождения графических ресурсов широко рассматривается среди Java-программистов как плохая практика программирования, и аналогичный метод __del__()На метод Python нельзя полагаться при высвобождении ресурсов. Для ресурсов стека (ресурсов, приобретаемых и выпускаемых в рамках одного блока кода) это можно автоматизировать с помощью различных языковых конструкций, таких как Python with, C# using или Java try-с-ресурсами.
Производительность [ править ]
Многие сторонники ручного управления памятью утверждают, что оно обеспечивает более высокую производительность по сравнению с автоматическими методами, такими как сбор мусора . Традиционно самым большим преимуществом была задержка, но сейчас это не так. Ручное распределение часто имеет превосходную локальность ссылки . [ нужна цитата ]
Также известно, что ручное выделение более подходит для систем, где память является дефицитным ресурсом, из-за более быстрого освобождения. программы Системы памяти могут и часто «терпят сбой», когда размер рабочего набора приближается к размеру доступной памяти; неиспользуемые объекты в системе со сбором мусора остаются в неутилизированном состоянии дольше, чем в системах, управляемых вручную, поскольку они не удаляются немедленно, что увеличивает эффективный размер рабочего набора.
Ручное управление имеет ряд документально подтвержденных недостатков производительности :
- Звонки в
deleteи такие накладные расходы возникают каждый раз, когда они создаются, эти накладные расходы могут быть амортизированы в циклах сборки мусора. Это особенно актуально для многопоточных приложений, где вызовы удаления должны быть синхронизированы. - Процедура распределения может быть более сложной и медленной. Некоторые схемы сбора мусора, например схемы с уплотнением кучи , могут поддерживать свободное хранилище как простой массив памяти (в отличие от сложных реализаций, требуемых схемами ручного управления).
Задержка — это дискуссионный вопрос, который со временем менялся: ранние сборщики мусора и простые реализации работали очень плохо по сравнению с ручным управлением памятью, но сложные современные сборщики мусора часто работали так же хорошо или даже лучше, чем ручное управление памятью.
Ручное распределение не страдает от длительных пауз, которые возникают при простой сборке мусора с остановкой мира, хотя современные сборщики мусора имеют циклы сбора, которые часто незаметны. [ нужна цитата ]
Ручное управление памятью и сборка мусора страдают от потенциально неограниченного времени освобождения - ручное управление памятью, поскольку освобождение одного объекта может потребовать освобождения его членов, а также рекурсивно членов его членов и т. д., в то время как сбор мусора может иметь длительные циклы сбора. Это особенно актуально для систем реального времени , где неограниченные циклы сбора данных обычно неприемлемы; сбор мусора в реальном времени возможен путем приостановки сборщика мусора, в то время как ручное управление памятью в реальном времени требует избегать крупных освобождений или приостанавливать освобождение вручную.
Ссылки [ править ]
- Бергер, Эд; Цорн, Б.Г.; МакКинли, Канзас (ноябрь 2002 г.). «Пересмотр специального распределения памяти» (PDF) . Материалы 17-й конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям . ООПСЛА '02. стр. 1–12. CiteSeerX 10.1.1.119.5298 . дои : 10.1145/582419.582421 . ISBN 1-58113-471-1 .
См. также [ править ]
Внешние ссылки [ править ]
- Справочник по управлению памятью
- Ричард Джонс и Рафаэль Линс, Сбор мусора: алгоритмы автоматического управления динамической памятью , Wiley and Sons (1996), ISBN 0-471-94148-4
