Войти
В компьютерном программировании, управление ресурсами относится к методам управления Ресурсы (компоненты с ограниченной доступностью).
Компьютерные программы могут управлять своими собственными ресурсами, используя функции, предоставляемые языками программирования ( Elder, Jackson amp; Liblit (2008) - обзорная статья, противопоставляющая различные подходы), или могут выбрать управление ими с помощью хоста - операционной системы или виртуальной машины - или другая программа.
Управление на основе хоста известно как отслеживание ресурсов и состоит из устранения утечек ресурсов: прекращения доступа к ресурсам, которые были получены, но не освобождены после использования. Это называется освобождением ресурсов и аналогично сборке мусора для памяти. Во многих системах операционная система восстанавливает ресурсы после того, как процесс выполняет системный вызов выхода.
Отсутствие освобождения ресурса после того, как программа завершила его использование, называется утечкой ресурса и является проблемой при последовательных вычислениях. Несколько процессов, желающих получить доступ к ограниченному ресурсу, могут быть проблемой при параллельных вычислениях и известны как конфликт ресурсов.
Управление ресурсами стремится контролировать доступ, чтобы предотвратить обе эти ситуации.
Формально управление ресурсами (предотвращение утечек ресурсов) заключается в обеспечении того, чтобы ресурс был освобожден тогда и только тогда, когда он был успешно получен. Эту общую проблему можно абстрагировать как код « до, основной и после », которые обычно выполняются в этом порядке, с условием, что код « после» вызывается тогда и только тогда, когда код « до» успешно завершается, независимо от того, выполняется ли основной код выполняется успешно или нет. Это также известно как выполнение или сэндвич с кодом и происходит в различных других контекстах, таких как временное изменение состояния программы или отслеживание входа и выхода в подпрограмму. Однако наиболее часто упоминаемое приложение - управление ресурсами. В аспектно-ориентированном программировании такое выполнение логики является формой совета.
В терминологии анализа потока управления высвобождение ресурса должно предшествовать успешному приобретению ресурса; неспособность гарантировать, что это ошибка, и путь кода, который нарушает это условие, вызывает утечку ресурсов. Утечки ресурсов часто являются незначительными проблемами, обычно не приводят к сбою программы, а вызывают некоторое замедление работы программы или всей системы. Однако они могут вызвать сбои - как самой программы, так и других программ - из-за исчерпания ресурсов: если в системе не хватает ресурсов, запросы на получение не выполняются. Это может представлять собой ошибку безопасности, если атака может вызвать исчерпание ресурсов. Утечки ресурсов могут происходить при обычном выполнении программы - например, при простом освобождении ресурса - или только в исключительных обстоятельствах, например, когда ресурс не освобождается, если в другой части программы есть исключение. Утечки ресурсов очень часто вызваны ранним выходом из подпрограммы либо return оператором, либо исключением, вызванным либо самой подпрограммой, либо более глубокой подпрограммой, которую она вызывает. В то время как освобождение ресурсов из-за операторов возврата может обрабатываться осторожным освобождением внутри подпрограммы перед возвратом, исключения не могут быть обработаны без некоторой дополнительной языковой возможности, которая гарантирует выполнение кода выпуска.
Говоря более тонко, успешное приобретение ресурса должно преобладать над высвобождением ресурса, поскольку в противном случае код попытается освободить ресурс, который он не получил. Последствия такого неправильного выпуска варьируются от молчаливого игнорирования до сбоя программы или непредсказуемого поведения. Эти ошибки обычно проявляются редко, так как они требуют выделения ресурсов для первого сбоя, что обычно является исключительным случаем. Кроме того, последствия могут быть несерьезными, поскольку программа уже может давать сбой из-за невозможности получить важный ресурс. Однако это может помешать восстановлению после сбоя или превратить плановое отключение в неупорядоченное. Это условие обычно обеспечивается путем первой проверки того, что ресурс был успешно получен перед его освобождением, либо наличием логической переменной для записи «успешно получен» - которой не хватает атомарности, если ресурс получен, но переменная флага не может быть обновлена, либо наоборот - или дескриптором ресурса, имеющего тип, допускающий значение NULL, где «null» означает «не удалось успешно получить», что обеспечивает атомарность.
Память можно рассматривать как ресурс, но управление памятью обычно рассматривается отдельно, прежде всего потому, что выделение и освобождение памяти происходит значительно чаще, чем сбор и освобождение других ресурсов, таких как дескрипторы файлов. Память, управляемая внешней системой, имеет сходство как с управлением (внутренней) памятью (поскольку это память), так и с управлением ресурсами (поскольку она управляется внешней системой). Примеры включают память, управляемую с помощью собственного кода и используемую из Java (через собственный интерфейс Java ); и объекты в объектной модели документа (DOM), используемые из JavaScript. В обоих этих случаях диспетчер памяти ( сборщик мусора ) среды выполнения (виртуальная машина) не может управлять внешней памятью (нет управления общей памятью), поэтому внешняя память рассматривается как ресурс и управляется аналогичным образом.. Однако циклы между системами (JavaScript относится к DOM, возвращается к JavaScript) могут сделать управление трудным или невозможным.
Ключевое различие в управлении ресурсами в программе заключается между лексическим управлением и явным управлением - может ли ресурс обрабатываться как имеющий лексическую область видимости, такую как переменная стека (время жизни ограничено одной лексической областью видимости, приобретается при входе в или в пределах определенной области и освобождается, когда выполнение выходит из этой области), или должен ли ресурс быть явно выделен и освобожден, например ресурс, полученный внутри функции и затем возвращенный из нее, который затем должен быть освобожден вне функции получения. Лексический менеджмент, когда это применимо, позволяет лучше разделить проблемы и менее подвержен ошибкам.
Базовый подход к управлению ресурсами заключается в том, чтобы получить ресурс, что-то с ним сделать, а затем выпустить его, получив код формы (проиллюстрирован открытием файла в Python):
f = open(filename)... f.close()
Это правильно, если промежуточный ... код не содержит раннего exit ( return), язык не имеет исключений и open гарантированно завершится успешно. Однако это вызывает утечку ресурса, если есть возврат или исключение, и вызывает некорректное освобождение незанятого ресурса, если open может произойти сбой.
Есть еще две фундаментальные проблемы: пара приобретение-выпуск не является смежной (код выпуска должен быть написан далеко от кода сбора) и управление ресурсами не инкапсулировано - программист должен вручную гарантировать, что они всегда сопряжены. В сочетании это означает, что получение и выпуск должны быть явно объединены в пару, но не могут быть объединены, что упрощает их неправильное объединение.
Утечка ресурсов может быть устранена на языках, которые поддерживают finally конструкцию (например, Python), поместив тело в try предложение, а релиз - в finally предложение:
f = open(filename) try:... finally: f.close()
Это гарантирует правильное освобождение, даже если есть возврат в теле или возникшее исключение. Кроме того, обратите внимание, что приобретение происходит до того в try статье, гарантируя, что finally условие выполняется только если open код успешно (без выбрасывания исключения), предполагая, что «не исключение» означает «успех» (как в случае open в Python). Если получение ресурса может завершиться неудачно без создания исключения, например, при возврате формы null, это также необходимо проверить перед выпуском, например:
f = open(filename) try:... finally: if f: f.close()
Хотя это обеспечивает правильное управление ресурсами, оно не обеспечивает смежности или инкапсуляции. Во многих языках есть механизмы, обеспечивающие инкапсуляцию, такие как with инструкция в Python:
with open(filename) as f:...
Вышеупомянутые методы - защита от размотки ( finally) и некоторая форма инкапсуляции - являются наиболее распространенным подходом к управлению ресурсами, который можно найти в различных формах, среди прочего, в C #, Common Lisp, Java, Python, Ruby, Scheme и Smalltalk ; они датируются концом 1970-х на диалекте NIL Lisp; см. Обработка исключений § История. Существует множество вариантов реализации, а также существенно разные подходы.
Наиболее распространенный подход к управлению ресурсами в разных языках - использование защиты от откручивания, которая вызывается, когда выполнение выходит из области видимости - путем выполнения, выполняемого за пределами конца блока, возврата изнутри блока или генерирования исключения. Это работает для ресурсов, управляемых стеком, и реализовано на многих языках, включая C #, Common Lisp, Java, Python, Ruby и Scheme. Основные проблемы с этим подходом заключаются в том, что код выпуска (чаще всего в finally предложении) может быть очень далек от кода получения (ему не хватает смежности ), и что код получения и выпуска всегда должен быть соединен вызывающим пользователем (в нем отсутствует инкапсуляция ). Их можно исправить либо функционально, используя замыкания / обратные вызовы / сопрограммы (Common Lisp, Ruby, Scheme), либо используя объект, который обрабатывает как получение, так и выпуск, и добавляя языковую конструкцию для вызова этих методов при входе и выходе управления. область видимости (C # using, Java try -with-resources, Python with); Смотри ниже.
Альтернативный, более императивный подход - написать асинхронный код в прямом стиле : получить ресурс, а затем в следующей строке отложить выпуск, который вызывается при выходе из области видимости - синхронное получение с последующим асинхронным выпуском. Он возник в C ++ как класс ScopeGuard, Андрей Александреску и Петру Марджинян в 2000 году, с улучшениями Джошуа Лерера, и имеет прямую языковую поддержку в D через scope ключевое слово ( ScopeGuardStatement ), где это один из подходов к безопасности исключений, в дополнение к RAII (см. Ниже). Он также был включен в Go в качестве defer заявления. В этом подходе отсутствует инкапсуляция - нужно явно сопоставлять получение и выпуск - но избегает необходимости создавать объект для каждого ресурса (с точки зрения кода, избегайте написания класса для каждого типа ресурса).
В объектно-ориентированном программировании ресурсы инкапсулируются в объекты, которые их используют, например в file объект, имеющий поле, значение которого является дескриптором файла (или более общим дескриптором файла ). Это позволяет объекту использовать и управлять ресурсом без необходимости делать это пользователям объекта. Однако существует множество способов связать объекты и ресурсы.
Во - первых, это вопрос о собственности: это объект имеет ресурс?
Объекты, у которых есть ресурс, могут получать и освобождать его по-разному, в разные моменты времени существования объекта ; они встречаются парами, но на практике они часто не используются симметрично (см. ниже):
open или dispose. Наиболее распространенным является получение ресурса во время создания объекта, а затем его явное освобождение с помощью обычно вызываемого метода экземпляра dispose. Это аналогично традиционному управлению файлами (получение во время open, явное освобождение close) и известно как шаблон удаления. Это основной подход, используемый в нескольких основных современных объектно-ориентированных языках, включая Java, C # и Python, и в этих языках есть дополнительные конструкции для автоматизации управления ресурсами. Однако даже в этих языках более сложные отношения объектов приводят к более сложному управлению ресурсами, как обсуждается ниже.
Естественный подход состоит в том, чтобы сделать сохранение ресурса инвариантом класса : ресурсы приобретаются во время создания объекта (в частности, инициализации) и высвобождаются во время уничтожения объекта (в частности, финализации). Это называется инициализацией получения ресурсов (RAII) и связывает управление ресурсами с жизненным циклом объекта, гарантируя, что живые объекты имеют все необходимые ресурсы. Другие подходы не делают сохранение ресурса инвариантным для класса, и, таким образом, объекты могут не иметь необходимых ресурсов (потому что они еще не получены, уже выпущены или управляются извне), что приводит к таким ошибкам, как попытка чтения. из закрытого файла. Этот подход связывает управление ресурсами с управлением памятью (в частности, с управлением объектами), поэтому, если нет утечек памяти (нет утечек объектов), утечек ресурсов нет. RAII естественно работает для ресурсов, управляемых кучей, а не только для ресурсов, управляемых стеком, и является компонуемым: ресурсы, удерживаемые объектами в произвольно сложных отношениях (сложный граф объектов ), прозрачно высвобождаются просто путем разрушения объекта (если это делается правильно!).
RAII - это стандартный подход к управлению ресурсами в C ++, но он мало используется за пределами C ++, несмотря на его привлекательность, потому что он плохо работает с современным автоматическим управлением памятью, в частности, с отслеживанием сборки мусора : RAII связывает управление ресурсами с управлением памятью, но у них есть существенные различия. Во-первых, поскольку ресурсы дороги, их желательно освободить как можно скорее, поэтому объекты, содержащие ресурсы, должны уничтожаться, как только они становятся мусором (больше не используются). Уничтожение объектов происходит быстро при детерминированном управлении памятью, например, в C ++ (объекты, выделенные стеком, уничтожаются при разматывании стека, объекты, выделенные в куче, уничтожаются вручную посредством вызова delete или автоматического использования unique_ptr) или при детерминированном подсчете ссылок (где объекты уничтожаются немедленно, когда их счетчик ссылок падает до 0), и поэтому RAII хорошо работает в этих ситуациях. Однако большинство современных систем автоматического управления памятью не является детерминированным и не дает никаких гарантий, что объекты будут уничтожены быстро или даже вообще! Это потому, что дешевле оставить выделенный мусор, чем точно собирать каждый объект сразу после того, как он становится мусором. Во-вторых, высвобождение ресурсов во время уничтожения объекта означает, что у объекта должен быть финализатор (в детерминированном управлении памятью, известный как деструктор ) - объект нельзя просто освободить, что значительно усложняет и замедляет сборку мусора.
Когда несколько объектов полагаются на один ресурс, управление ресурсами может быть сложным.
Фундаментальный вопрос заключается в том, является ли отношение «имеет» отношениями владения другим объектом ( композиция объекта ) или просмотра другого объекта ( агрегирование объектов ). Общий случай, когда один два объекта прикован, как в трубе и фильтр рисунке, шаблон делегирование, то шаблон декоратора, или шаблон адаптера. Если второй объект (который не используется напрямую) содержит ресурс, отвечает ли первый объект (который используется напрямую) за управление ресурсом? Обычно ответ на этот вопрос идентичен тому, владеет ли первый объект вторым объектом: если да, то объект-владелец также отвечает за управление ресурсами («наличие ресурса» является транзитивным ), а если нет, то это не так. Кроме того, один объект может «иметь» несколько других объектов, владея одними и просматривая другие.
Оба случая встречаются обычно, и соглашения различаются. Наличие объектов, которые косвенно используют ресурсы, несут ответственность за ресурс (состав), обеспечивает инкапсуляцию (нужен только объект, который используют клиенты, без отдельных объектов для ресурсов), но приводит к значительной сложности, особенно когда ресурс совместно используется несколькими объектами или объекты имеют сложные отношения. Если только объект, который напрямую использует ресурс, отвечает за ресурс (агрегация), отношения между другими объектами, которые используют ресурсы, можно игнорировать, но нет инкапсуляции (помимо непосредственно использующего объекта): ресурс должен управляться напрямую, и может быть недоступен косвенно использующему объекту (если он был выпущен отдельно).
С точки зрения реализации в композиции объекта, если используется шаблон удаления, объект-владелец, таким образом, также будет иметь dispose метод, который, в свою очередь, вызывает dispose методы принадлежащих объектов, которые должны быть удалены; в RAII это обрабатывается автоматически (до тех пор, пока принадлежащие объекты сами автоматически уничтожаются: в C ++, если они являются значением или a unique_ptr, но не необработанным указателем: см. владение указателем ). При агрегации объектов просматривающему объекту ничего не нужно делать, так как он не отвечает за ресурс.
Оба обычно встречаются. Например, в библиотеке классов Java, Reader#close() закрывает основной поток, и они могут быть соединены. Например, a BufferedReader может содержать a InputStreamReader , который, в свою очередь, содержит a FileInputStream , и вызов close этого, BufferedReader в свою очередь, закрывает InputStreamReader, который, в свою очередь, закрывает FileInputStream, что, в свою очередь, освобождает ресурс системного файла. Действительно, объект, который напрямую использует ресурс, может быть даже анонимным благодаря инкапсуляции:
try (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream(fileName)))) { // Use reader. } // reader is closed when the try-with-resources block is exited, which closes each of the contained objects in sequence. Однако также можно управлять только объектом, который напрямую использует ресурс, и не использовать управление ресурсами для объектов оболочки:
try (FileInputStream stream = new FileInputStream(fileName)))) { BufferedReader reader = new BufferedReader(new InputStreamReader(stream)); // Use reader. } // stream is closed when the try-with-resources block is exited. // reader is no longer usable after stream is closed, but so long as it does not escape the block, this is not a problem. Напротив, в Python csv.reader не владеет тем, file что он читает, поэтому нет необходимости (и это невозможно) закрывать читатель, и вместо этого file должен быть закрыт сам.
with open(filename) as f: r = csv.reader(f) # Use r. # f is closed when the with-statement is exited, and can no longer be used. # Nothing is done to r, but the underlying f is closed, so r cannot be used either.
В .NET соглашение предусматривает, что ответственность за это несет только непосредственный пользователь ресурсов: «Вы должны реализовывать IDisposable только в том случае, если ваш тип напрямую использует неуправляемые ресурсы».
В случае более сложного графа объектов, такого как несколько объектов, совместно использующих ресурс, или циклы между объектами, которые содержат ресурсы, правильное управление ресурсами может быть довольно сложным, и возникают точно такие же проблемы, как и при финализации объекта (через деструкторы или финализаторы); например, проблема пропущенного слушателя может возникнуть и вызвать утечку ресурсов при использовании шаблона наблюдателя (а наблюдатели удерживают ресурсы). Существуют различные механизмы, позволяющие лучше контролировать управление ресурсами. Например, в Closure Library Google, то goog.Disposable класс предоставляет registerDisposable метод для регистрации других объектов, которые будут расположен с этим объектом, вместе с различными методами экземпляра класса и более низкого уровня для управления утилизацией.
В структурированном программировании управление ресурсами стека осуществляется простым вложением кода, достаточным для обработки всех случаев. Для этого требуется только одно возвращение в конце коды, и может привести к сильно вложенной коде, если много ресурсов, должны быть приобретены, который считается анти-моделью каким - то - в шаблоне Стрелка анти, из - за треугольную форму из последовательных гнездование.
Еще один подход, который допускает ранний возврат, но объединяет очистку в одном месте, состоит в том, чтобы иметь единственный выход из функции, которому предшествует код очистки, и использовать goto для перехода к очистке перед выходом. Это нечасто встречается в современном коде, но встречается в некоторых случаях использования C.
