Мусор (информатика) - Garbage (computer science)

Мусор может также относиться к искаженным данным; Видеть Повреждение данных.

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

Классификация

Мусор обычно делится на два типа: синтаксический мусор, любой объект или данные, которые находятся в области памяти программы, но недоступны из корневой набор; и семантический мусор, любой объект или данные, к которым никогда не обращается запущенная программа при любой комбинации входных данных программы. Объекты и / или данные, которые не являются мусором, считаются жить.

Случайно сказано, что синтаксический мусор - это данные, которые не можешь быть достигнутым, а семантический мусор - это данные, которые не буду быть достигнут. Точнее, синтаксический мусор - это данные, которые недоступны из-за ссылочного графа (к нему нет пути), который может быть определен многими алгоритмами, как описано в Отслеживание сборки мусора, и требует только анализа данных, а не кода. Семантический мусор - это данные, к которым не будет доступа, либо потому, что они недоступны (следовательно, также синтаксический мусор), либо потому, что они доступны, но не будут доступны; последнее требует анализа кода и, как правило, неразрешимая проблема.

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

Пример

В следующей простой реализации стека на Java каждый элемент, извлекаемый из стека, становится семантическим мусором, если на него нет внешних ссылок:[а]

общественный учебный класс Куча {    частный Объект[] элементы;    частный int размер;    общественный Куча(int емкость) {        элементы = новый Объект[емкость];    }    общественный пустота толкать(Объект е) {        элементы[размер++] = е;    }    общественный Объект поп() {        возвращаться элементы[--размер];    }}

Это потому что элементы [] по-прежнему содержит ссылку на объект, но объект никогда можно снова получить доступ через эту ссылку, потому что элементы [] является частным для класса, а поп Метод возвращает только ссылки на элементы, которые он еще не получил. (После уменьшения размер, этот класс никогда доступ к этому элементу снова.) Однако знание этого требует анализа кода класса, который в общем случае неразрешим.

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

Автоматический сбор мусора

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

>>> учебный класс Фу:...     "" "Это пустой тестовый класс." ""...     проходить...>>> бар = Фу()>>> бар<__main__.Foo object at 0x54f30>>>> дель бар

В этом сеансе создается объект, отображается его местоположение в памяти, а затем уничтожается единственная ссылка на объект - с этого момента невозможно использовать объект снова, поскольку на него нет ссылок. . Это становится очевидным, когда мы пытаемся получить доступ к исходной ссылке:

>>> барОтслеживание (последний вызов последний):  Файл "", линия 1, в ?NameError: имя 'bar' не определено

Поскольку теперь невозможно обратиться к объекту, объект стал бесполезным; это фигня. Поскольку Python использует сборку мусора, он автоматически освобождает память, которая использовалась для объекта, чтобы его можно было использовать снова:

>>> учебный класс Бар:...     "" "Это еще один класс тестирования." ""...     проходить...>>> баз = Бар()>>> баз<__main__.Bar object at 0x54f30>

В Бар экземпляр теперь находится в ячейке памяти 0x54f30; в том же месте, что и наш предыдущий объект, Фу экземпляр, был найден. Поскольку Фу экземпляр был уничтожен, освобождая память, используемую для его хранения, интерпретатор создает Бар объект в той же ячейке памяти, что и раньше, эффективно используя доступные ресурсы.

Последствия

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

Однако сбор мусора требует времени и, если он выполняется вручную, требует дополнительных затрат на кодирование. Кроме того, сбор мусора разрушает объекты и, следовательно, может вызывать вызовы финализаторы, выполняя потенциально произвольный код в произвольной точке выполнения программы. Неправильная сборка мусора (освобождение памяти, которая не является мусором), в первую очередь из-за ошибок при ручной сборке мусора (а не ошибок в сборщиках мусора), приводит к безопасность памяти нарушения (которые часто создают дыры в безопасности) из-за использования висячие указатели.

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

Устранение мусора

Проблема управления удалением мусора хорошо известна в компьютерных науках. Применяются несколько подходов:

  • Много операционные системы освободить память и ресурсы, используемые процессом или программой, когда они завершаются. Простые или недолговечные программы, предназначенные для работы в таких средах, могут завершиться и позволить операционной системе выполнить любое необходимое восстановление.
  • В системах или языки программирования с ручное управление памятью, программист должен явно организовать освобождение памяти, когда она больше не используется. C и C ++ - два хорошо известных языка, поддерживающих эту модель.
  • Вывоз мусора использует различные алгоритмы для автоматического анализа состояния программы, выявления мусора и его удаления без вмешательства программиста. Многие современные языки программирования, такие как Ява и Haskell обеспечить автоматический сбор мусора. Однако это не недавняя разработка, так как она также использовалась в более старых языках, таких как LISP.
  • В настоящее время ведутся исследования теоретико-типичный подходы (такие как региональный вывод ) к выявлению и удалению мусора из программы. Никакого общего теоретико-типового решения проблемы разработано не было.

Примечания

  1. ^ Упрощено от Эффективная Java Пункт 6, пропустив изменение размера и явные исключения.

внешняя ссылка

  • Бенджамин Пирс (редактор), Продвинутые темы по типам и языкам программирования, MIT Press (2005), ISBN  0-262-16228-8
  • Ричард Джонс и Рафаэль Линс, Сборка мусора: алгоритмы автоматического управления динамической памятью, Уайли и сыновья (1996), ISBN  0-471-94148-4