C #: Есть ли преимущество в размещении ресурсов в обратном порядке их распределения?

Question

Много лет назад я был предупрежден, когда это возможно, высвобождать ресурсы в порядке, обратном тому, как они были распределены.То есть:

block1 = malloc( ... );
block2 = malloc( ... );

... do stuff ...

free( block2 );
free( block1 );

Я предполагаю, что на машине MS-DOS 640K это может минимизировать фрагментацию кучи.Есть ли какое-либо практическое преимущество для этого в приложении на C # / .NET, или эта привычка изжила свою актуальность?

Answer 1

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

Однако многие плохо созданные библиотеки не выполняют надлежащей проверки. Распоряжение ресурсами в обратном порядке их распределения обычно означает, что вы сначала избавляетесь от ресурсов, зависящих от других ресурсов, что может предотвратить возникновение проблем из-за плохо написанных библиотек. (Вы никогда не распоряжаетесь ресурсом, а в этом случае используете тот, который зависит от существования первого.)

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

Вот пример: посмотрите на операцию базы данных. Вы не хотите закрывать / утилизировать ваше соединение перед закрытием / удалением вашей команды (которая использует соединение).

Answer 2

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

Кроме того, если вы удаляете ссылки A и B и A B, не должно иметь значения, если A удаляет B при удалении A, поскольку метод Dispose должен вызываться более одного раза без исключения.

Answer 3

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

Если вы имеете в виду вызов IDisposable.Dispose (), то это зависит от поведения объектов, реализующих интерфейс IDisposable.

В общем, порядок не имеет значения для большинства объектов Framework, за исключением того, что он имеет значение для вызывающего кода. Но если объект A поддерживает зависимость от объекта B, а объект B удаляется, то вполне может быть важно не делать определенные вещи с объектом A.

В большинстве случаев Dispose () не вызывается напрямую, а вызывается неявно как часть оператора using или foreach, и в этом случае шаблон обратного порядка естественным образом возникает в соответствии с вложенным оператором.

using(Foo foo = new Foo())
using(FooDoodler fooDoodler = new FooDoodler(foo))
{
  // do stuff
  // ...
  // fooDoodler automatically gets disposed before foo at the end of the using statement.
}

Answer 4

"Среда выполнения не дает никаких гарантий относительно порядка вызова методов Finalize. Например, скажем, есть объект, который содержит указатель на внутренний объект. Сборщик мусора обнаружил, что оба объекта Кроме того, скажем, что метод Finalize внутреннего объекта вызывается первым. Теперь метод Finalize внешнего объекта разрешен для доступа к внутреннему объекту и вызова для него методов, но внутренний объект завершен, и результаты могут быть непредсказуемыми. По этой причине настоятельно рекомендуется, чтобы методы Finalize не обращались ни к каким внутренним объектам-членам. "

http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

Таким образом, вы можете беспокоиться о семантике утилизации LIFO столько, сколько вам хочется, но если вы ее утечете, Dispose () будут вызываться в любом порядке, который придет CLR.

(Это более или менее то, что сказал Уилл, выше)

Answer 5

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

[Несмотря на некоторые попытки MSDN.com и Duffius заставить его исчезнуть, вы знаете, как управлять всем этим для вас, разница между кучей и стеком. Что за умная идея .. в космосе]