Происходит ли "утечка памяти" при повторном выполнении: Bitmap bm1 = new Bitmap

@Win-ni · Регистрация: 16.08.2011

Студворк — интернет-сервис помощи студентам

Здравствуйте !

Подскажите, пожалуйста, происходит ли "утечка памяти"
при создании объекта bm1 и, если не сложно - как её избежать.

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
       private void timer1_Tick(object sender, EventArgs e)
        {
            if (num < 5)
                num++;
            else
                timer1.Enabled = false;
 
            FName = buf2.FilePath8 + @"\" + num.ToString() + ".Jpeg";
            Text = num.ToString() + ".Jpeg";
            Bitmap bm1 = new Bitmap(FName, true);
            pB1.Image = bm1;
 
        }

@Noob.net · 02.08.2012, 22:15

Объяви его Битмап за пределами тика
а в тике делай так

C#
1
bm1 = new Bitmap(FName, true);

ВАСИЛЕВС · 02.08.2012, 22:22

Win-ni, можно глобально объявить

C#
1
Bitmap bm1;

, а потом в timer1_Tick перезаписывать

C#
1
bm1 = new Bitmap(FName, true);

Не по теме:

Noob.net, опередил...

@kolorotur · 02.08.2012, 22:23

Да, просиходит. Только не памяти, а GDI-дескрипторов, которых на приложение выдается ограниченное количество.

Сообщение от Noob.net

Объяви его Битмап за пределами тика

Разницы никакой.
Можно вообще без объявления отдельной переменной:

C#
1
pB1.Image = new Bitmap(FName, true);

Утечка все равно будет происходить, т.к. предыдущее изображение не удаляется.

C#
1
2
if (pB1.Image != null) pB1.Image.Dispose();
pB1.Image = new Bitmap(FName, true);

@Noob.net · 02.08.2012, 22:33

Сообщение от kolorotur

Разницы никакой.
Можно вообще без объявления отдельной переменной:

А разве если инициализация происходит за пределами метода мы не создаем один объект,
которому просто будем менять ссылки а предыдущие будут обозначены для удаления,так как ссылок на них не останется ??

@Win-ni · 02.08.2012, 23:32 **[ТС]**

Спасибо !

Жаль, что нельзя всё это проверить измеряя оставшуюся память, как в Паскале.
Завтра попробую экспериментировать, меняя свойство - имя файла в PictureBox.
Только подберусь ли я тогда к Bitmap, а он мне нужен, чтобы получать пикселы
по координатам.

Добавлено через 24 минуты
Всё-таки набрался терпения и через Диспетчер задач Windows проследил за доступным объёмом физической памяти во время выполнения этого кода. Наблюдается вот что:
- действительно, доступная память уменьшается при каждом new (код пока не исправлял)
- однако временами объём памяти увеличивался скачком. Может быть это и есть работа
сборщика мусора или что-то в этом роде?
Вывод по этим наблюдениям такой - утечка происходит, но ограниченная и нестрашная.
Однако что думают об этом опытные программисты на C#?

@kolorotur · 03.08.2012, 00:53

Сообщение от Noob.net

А разве если инициализация происходит за пределами метода мы не создаем один объект,
которому просто будем менять ссылки а предыдущие будут обозначены для удаления,так как ссылок на них не останется ??

Старый объек-то будет удаляться, но не будут удаляться неуправляемые ресурсы, им используемые. В случа с Bitmap этими ресурсами является GDI-дескриптор, который не находится на учете у сборщика мусора, а потому уничтожать его нужно самостоятельно вызовом метода Dispose.
При этом не играет никакой роли место, где объявлена переменная.

Сообщение от Win-ni

Всё-таки набрался терпения и через Диспетчер задач Windows проследил за доступным объёмом физической памяти во время выполнения этого кода.

Диспетчер - не очень хороший инструмент для профилирования памяти - он ведь показывает текущий рабочий сет, а не фактически потребляемую память. Даже если добавить колонку с фактически потребляемой памятью (Private set или что-то вроде того), то все равно вы не будете знать что именно потребляет эту память внутри приложения. Так что используйте инструменты для профилирования, доступные в студии, или сторонние приложения (у RedGate очень хороший профайлер, но платный).

@Win-ni · 03.08.2012, 10:07 **[ТС]**

Спасибо.

Буду пробовать Dispose по Вашей подсказке. В справке об этом почитал, но только голова циркулем пошла. До капитальных средств отладки Visual Studio ещё не добрался, но буду иметь в виду. Конечно, мои опыты измерения доступной памяти очень приближённы, ясно что одновременно крутится много процессов.

@turbanoff · 03.08.2012, 10:55

Сообщение от kolorotur

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

На самом деле это не совсем верно. У всех .NET классов из FCL, работающих с неуправляемыми ресурсами, перегружен деструктор (метод Filnalize) в котором и вызывается Dispose.
То есть собрщик сможет убрать и неуправляемые ресурсы.
Из этого следует, что руками вызывать Dispose нужно только при большом количестве одновременно выделенных Bitmap'ов, которые сборщие не может/не успел подчистить.
Учитывая лимит GDI в 10000 на приложение, о вызове Dispose можно не беспокоиться, сборщик сделает всю работу сам.

@kolorotur · 03.08.2012, 13:41

turbanoff, это-то так, но тогда объект будет удаляться за два обхода сборщика, а когда они будут, эти обходы?
Метод с "деструктоом" - это защита от дурака, не стоит на нее полагаться.

@Egr66001 · 03.08.2012, 13:56

попробуй во так

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
        private void timer1_Tick(object sender, EventArgs e)
        {
            if (num < 5)
                num++;
            else
                timer1.Enabled = false;
 
            FName = buf2.FilePath8 + @"\" + num.ToString() + ".Jpeg";
            Text = num.ToString() + ".Jpeg";
            using (Bitmap bm1 = new Bitmap(FName, true))
            {
                pB1.Image = bm1;
            }
        }

@kolorotur · 03.08.2012, 14:11

Egr66001, он жеж сразу уничтожится, не отобразившись на форме. pB1 - это ведь, насколько я понял, PictureBox.

@turbanoff · 03.08.2012, 14:16

Сообщение от kolorotur

Метод с "деструктоом" - это защита от дурака, не стоит на нее полагаться.

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

@kolorotur · 03.08.2012, 14:21

turbanoff, потому что нет стандарта использования деструктора в этом сценарии - в том же фреймворке не все классы используют этот паттерн (могу, конечно, ошибаться).
Если паттерн используется - отлично, если нет - надо вручную удалять. Так как лезть в исходники класса для того, чтобы это узнать - идиотизм, то лучше заиметь привычку вручную вызывать Dispose на всех объектах, реализующих соответствующий интерфейс.
Согласны?

@turbanoff · 03.08.2012, 14:36

Сообщение от kolorotur

в том же фреймворке не все классы используют этот паттерн

Все, что работают с неуправляемыми ресурсами.
Нет, не согласен, зачем бездумно каждый раз руками набивать лишние строки усложняя и нагромождая код, хотя это можно и не делать?
Кроме того ручной вызов Dispose - тоже не всегда полезен, ведь он может затянуться на неопределнное время, что не всегда приемлемо.

Сообщение от kolorotur

то лучше заиметь привычку вручную вызывать Dispose на всех объектах, реализующих соответствующий интерфейс.

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

@Win-ni · 03.08.2012, 16:23 **[ТС]**

В связи с тем, что мне нужен объект Bitmap, пришлось сделать так:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
       private void timer1_Tick(object sender, EventArgs e)
        {
            if (num < 20)
                num++;
            else
            timer1.Enabled = false;
 
            FName = buf2.FilePath8 + @"\" + num.ToString() + ".Jpeg";
            Text = num.ToString() + ".Jpeg";
            if (buf2.bm1 != null) buf2.bm1.Dispose(); 
            // if (pB1.Image != null) pB1.Image.Dispose();
            buf2.bm1 = new Bitmap(FName, true);
            pB1.Image = buf2.bm1;
        }
 
    public static class buf2
    {
        public static string FilePath8 ;
        public static Bitmap bm1;
    }

Моя методика не обнаруживает утечки памяти при работе этого кода,
так же как и при работе исходного варианта:

C#
1
2
if (pB1.Image != null) pB1.Image.Dispose();
pB1.Image = new Bitmap(FName, true);

Новые блоги и статьи Все статьи Все блоги /
http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .	http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит переходные токи и напряжения на элементах схемы. . . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .
Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .

@Win-ni 11 / 11 / 1 Регистрация: 16.08.2011 Сообщений: 70
	02.08.2012, 23:32 [ТС]
	Спасибо ! Жаль, что нельзя всё это проверить измеряя оставшуюся память, как в Паскале. Завтра попробую экспериментировать, меняя свойство - имя файла в PictureBox. Только подберусь ли я тогда к Bitmap, а он мне нужен, чтобы получать пикселы по координатам. Добавлено через 24 минуты Всё-таки набрался терпения и через Диспетчер задач Windows проследил за доступным объёмом физической памяти во время выполнения этого кода. Наблюдается вот что: - действительно, доступная память уменьшается при каждом new (код пока не исправлял) - однако временами объём памяти увеличивался скачком. Может быть это и есть работа сборщика мусора или что-то в этом роде? Вывод по этим наблюдениям такой - утечка происходит, но ограниченная и нестрашная. Однако что думают об этом опытные программисты на C#? 0

@Win-ni 11 / 11 / 1 Регистрация: 16.08.2011 Сообщений: 70
	03.08.2012, 10:07 [ТС]
	Спасибо. Буду пробовать Dispose по Вашей подсказке. В справке об этом почитал, но только голова циркулем пошла. До капитальных средств отладки Visual Studio ещё не добрался, но буду иметь в виду. Конечно, мои опыты измерения доступной памяти очень приближённы, ясно что одновременно крутится много процессов. 0

@kolorotur 17823 / 12973 / 3382 Регистрация: 17.09.2011 Сообщений: 21,261
	03.08.2012, 13:41
	turbanoff, это-то так, но тогда объект будет удаляться за два обхода сборщика, а когда они будут, эти обходы? Метод с "деструктоом" - это защита от дурака, не стоит на нее полагаться. 0

@kolorotur 17823 / 12973 / 3382 Регистрация: 17.09.2011 Сообщений: 21,261
	03.08.2012, 14:11
	Egr66001, он жеж сразу уничтожится, не отобразившись на форме. pB1 - это ведь, насколько я понял, PictureBox. 0

@kolorotur 17823 / 12973 / 3382 Регистрация: 17.09.2011 Сообщений: 21,261
	03.08.2012, 14:21
	turbanoff, потому что нет стандарта использования деструктора в этом сценарии - в том же фреймворке не все классы используют этот паттерн (могу, конечно, ошибаться). Если паттерн используется - отлично, если нет - надо вручную удалять. Так как лезть в исходники класса для того, чтобы это узнать - идиотизм, то лучше заиметь привычку вручную вызывать Dispose на всех объектах, реализующих соответствующий интерфейс. Согласны? 1