Расположение Битового массива через его Финализатор
У меня есть сложная программа, в которой я должен сначала создать, затем использовать обертки вокруг битовых массивов и отправить их через большое количество различных классов. Проблема в конце решает, какие классы должны расположить битовые массивы. Большую часть времени классы конца не знают, могут ли они действительно расположить битовый массив, поскольку тот же битовый массив может использоваться в нескольких местах. Кроме того, я не могу только скопировать битовые массивы, потому что это - своего рода интенсивно использующий ресурсы алгоритм, и выполнение его было бы мертво медленный.
Я искал на отражателе для реализаций Изображения/Битового массива, и они, кажется, используют Расположить Шаблон. Так, даже если я не звоню, Располагают (), CLR в конечном счете назовет это некоторым другим временем.
Это слишком плохо, если я просто позволяю битовым массивам быть, как они и позволяют финализатору заботиться о них?
4 ответа
Кажется, ваша основная проблема здесь в вашем дизайне, но, вероятно, сейчас уже слишком поздно и / или слишком дорого исправить. Но в целом избегайте слишком долго удерживать ресурсы.
Поскольку вы используете оболочки, вы можете взглянуть на подсчет ссылок в качестве шаблона проектирования. Любой удерживающий объект может зарегистрировать и отменить регистрацию своего интереса к битовой карте, и вы можете Dispose, когда счетчик ссылок упадет до 0.
Но самый простой способ - просто позволить сборщику мусора делать эту работу. Просто убедитесь, что все поля, ссылающиеся на оболочки, обнулены как можно скорее.
Итак, даже если я не вызову Dispose(), CLR в конце концов вызовет ее в другой раз.
Финализатор и метод Dispose - это две разные вещи. Он "должен" сделать это, но вы не можете сказать наверняка, что он это сделает. Вы не можете предположить это, вам придется проверять в каждом конкретном случае. Судя по тому, что вы говорите, в данном случае похоже, что так и есть.
Не слишком ли плохо, если я просто оставлю растровые изображения такими, какие они есть, и позволю финализатору позаботиться о них?
Да, плохо, потому что указание финализатора создает дополнительную работу для сборщика мусора. Он автоматически переводит его в следующее поколение CG, что означает, что ресурсы не будут освобождены так быстро, как могли бы. Обычно, когда кто-то реализует Dispose, он подавляет вызов финализатора, что предотвращает это.
Всякий раз, когда объект реализует IDisposable, он должен быть заключен в оператор using.
using(var bitmap = new BitMap())
{
....
}
В данном случае, поскольку метод dispose находится в финализаторе, а вам действительно очень нужно, вы можете не использовать метод dispose и позволить финализатору позаботиться об этом. Это не очень хорошо, но вы можете это сделать. Исходя из того, что вы говорите, это может быть лучшим вариантом действий без рефакторинга кода.
Каков срок жизни растровых изображений? Другими словами, что запускает создание растровых изображений и какие «события» происходят между тем моментом и моментом, когда они могут быть безопасно уничтожены?
Если между созданием и окончанием жизненного цикла не происходит никаких пользовательских / внешних событий, это будет Лучше всего, если бы код можно было структурировать таким образом, чтобы код, создающий растровые изображения, также разрушал их.
В C # было бы лучше заключить их в с использованием оператора :
using (Bitmap bitmap = CreateBitmap())
{
DoWork(bitmap);
}
Это гарантирует, что битовая карта будет сохраняться столько, сколько необходимо, и не более того.
Если пользовательские / внешние события происходят между созданием и окончанием срока службы (и при обработке этих событий необходимо получить доступ к растровым изображениям), ситуация не так проста, но это также будет означать, что вы сохраняете постоянную ссылку к растровым изображениям где-нибудь, что в любом случае предотвратит их сборку мусора.
Основываясь на том, что я понял из вашего вопроса, я предлагаю вам, следуя
Расширить интерфейс IDisposable в классах, в которых вы сохраняете уровень класса переменной объекта изображения и удалите этот объект изображения в методе Dispose ().
Я также считаю, что вам не нужно беспокоиться об объекте растрового изображения, который вы передаете другим методам, вам не нужно удалять его в этом конкретном классе. Просто убедитесь, что вы удаляете его в классе, который создает экземпляр растрового изображения.
Надеюсь, это поможет вам.