WeakReference - ссылки пропадают каждые 1-10 секунд

@SergBokh · Регистрация: 03.09.2009

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

Создаю несколько объектов и работаю с ними через слабые ссылки (WeakReference). Обнаружилось, что даже если я обращаюсь к этим объектам по 10 раз в секунду, то примерно в половине случаев приходится пересоздавать объекты, т.к. уже через 1/10 секунды они зачастую почему-то пропадают.
Почему так быстро? Можно ли увеличить как-либо время жизни?

@SPOON · 16.07.2011, 08:34

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

Создаю несколько объектов и работаю с ними через слабые ссылки (WeakReference). Обнаружилось, что даже если я обращаюсь к этим объектам по 10 раз в секунду, то примерно в половине случаев приходится пересоздавать объекты, т.к. уже через 1/10 секунды они зачастую почему-то пропадают.
"Почему так быстро? Можно ли увеличить как-либо время жизни?

Познакомившись с мягкими ссылками, разработчики сразу
же считают, что они хорошо подходят для сценариев кеширования.
Порядок рассуждений примерно таков: «Хорошо бы создать много
объектов, содержащих много данных, а затем создать для них мягкие ссылки.
Когда программе понадобятся эти данные, она с помощью мягкой ссылки
проверит, есть ли поблизости объект, содержащий эти данные, и, если
он рядом, она воспользуется нужными данными. Это обеспечит высокую
производительность приложения». Однако после сбора мусора объекты,
содержащие данные, будут уничтожены, и когда программе придется
заново создавать данные, ее производительность упадет.
Недостаток такого подхода в том, что сбор мусора не происходит,
когда память переполнена или почти переполнена. Напротив, он
происходит, когда поколение 0 заполнено, что бывает примерно после
выделения очередных 256 байт памяти. Поэтому объекты удаляются из
памяти гораздо чаще, чем нужно, что сильно ухудшает
производительность приложения.
Мягкие ссылки могут быть очень эффективными при кешировании,
но очень сложно создать хороший алгоритм кеширования с правильным
равновесием между расходованием памяти и скоростью. В сущности,
необходимо, чтобы в кеше были жесткие ссылки на все объекты, а
затем, когда памяти становится мало, жесткие ссылки должны превращаться
в мягкие. На сегодняшний момент CLR не поддерживает механизм,
позволяющий уведомлять приложение об исчерпании ресурсов памяти. Но
некоторые разработчики приспособились периодически вызывать Win32-
функцию GlobalMemoryStatusEx и проверять член dwMemoryLoad
возвращенной структуры MEMORYSTATUSEX. Если его значение больше 80,
память на исходе и настало время преобразовывать жесткие ссылки в мягкие
по выбранному алгоритму — по давности, частоте, времени
использования объектов или по другим алгоритмам."
Рихтер Джеффри
CLR via C#. Программирование на платформе Microsoft .NET Framework 2.0 на языке С#.
Возможно вам будет интересно.
Покажите как вы их используете?

@SergBokh · 16.07.2011, 11:10 **[ТС]**

Да, я так и понял, что мягкие ссылки в .нет слегка не доработаны. Очистка объектов идет без связи с их размером, да и вообще без необходимости в этом. Зачем удалять обьект размером в 15кб, тем более через секунду после его создания.

@CookieMonsta · 16.07.2011, 15:26

GC.SupressFinalize(s) где s - ссылка которая не должна очищаться сборщиком мусора
когда ссылки станут не нужны GC.Collect(0)

@SergBokh · 16.07.2011, 18:49 **[ТС]**

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

@VKabanov · 18.07.2014, 13:52

SergBokh, возможно можно залочить Lock(obj) слабую ссылку и тогда она останется живой до тех пор, пока не сдохнет нить не нее ссылающаяся?

Добавлено через 37 минут
SergBokh,

И совсем хардкорный метод в стиле Рихтера, это :
1) Завести глобальную переменную - флаг сигнализирующий о реальной необходимости чистить кэш.
2) Объекты помещаемые в организованный с помощью слабых ссылок кэш имеют метод finalize.
3) В деструкторе в зависимости от состояния флага помечать объекты на которые ссылаются слабые ссылки к удалению (GC.ReRegisterForFinalize(this) "Горец" от Рихтера) или не помечать(если надо чтобы GC таки снес...).

@jetyb · 18.07.2014, 18:54

Можно как-то так это сделать

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class MyWeakReference
        {
            static List<MyWeakReference> referenceList = new List<MyWeakReference>();
            static ArrayList objectList = new ArrayList();
            public readonly WeakReference WeakReference;
 
            public MyWeakReference(object obj)
            {
                WeakReference = new WeakReference(obj);
                objectList.Add(obj);
                referenceList.Add(this);
            }
 
            public static void Clean()
            {
                objectList = new ArrayList();
                referenceList = new List<MyWeakReference>();
            }
        }

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

@kolorotur · 18.07.2014, 21:39

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

GC.SupressFinalize(s) где s - ссылка которая не должна очищаться сборщиком мусора

Это просто финализатор не будет запускаться

Добавлено через 25 секунд

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

GC.SupressFinalize(s) где s - ссылка которая не должна очищаться сборщиком мусора

Это просто финализатор не будет запускаться

Psilon · 19.07.2014, 20:17

Microsoft советует не использовать слабые ссылки. Как правило, больше 99% прикладных программистов с их помощью стреляют себе в ногу и не умеют правильно использовать. Этот класс нужен для прикладных нужд команды .Net и 0.0..01% тех, кто знает, как ими пользоваться

Добавлено через 1 минуту

Avoid using weak references as an automatic solution to memory management problems. Instead, develop an effective caching policy for handling your application's objects.

http://msdn.microsoft.com/en-u... 04247.aspx

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	Установка Emscripten SDK (emsdk) и CMake на Windows для сборки C и C++ приложений в WebAssembly (Wasm) 8Observer8 30.01.2026 Чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. Система контроля версиями Git. . .	Подключение Box2D v3 к SDL3 для Android: физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .
Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .	Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL3_image 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .	Влияние грибов на сукцессию anaschu 26.01.2026 Бифуркационные изменения массы гриба происходят тогда, когда мы уменьшаем массу компоста в 10 раз, а скорость прироста биомассы уменьшаем в три раза. Скорость прироста биомассы может уменьшаться за. . .	Воспроизведение звукового файла с помощью SDL3_mixer при касании экрана Android 8Observer8 26.01.2026 Содержание блога SDL3_mixer - это библиотека я для воспроизведения аудио. В отличие от инструкции по добавлению текста код по проигрыванию звука уже содержится в шаблоне примера. Нужно только. . .

@SergBokh 85 / 77 / 13 Регистрация: 03.09.2009 Сообщений: 346

	.NET 3.x WeakReference - ссылки пропадают каждые 1-10 секунд 15.07.2011, 22:56. Показов 3502. Ответов 8 Метки нет (Все метки) Создаю несколько объектов и работаю с ними через слабые ссылки (WeakReference). Обнаружилось, что даже если я обращаюсь к этим объектам по 10 раз в секунду, то примерно в половине случаев приходится пересоздавать объекты, т.к. уже через 1/10 секунды они зачастую почему-то пропадают. Почему так быстро? Можно ли увеличить как-либо время жизни? 0

@SergBokh 85 / 77 / 13 Регистрация: 03.09.2009 Сообщений: 346
	16.07.2011, 11:10 [ТС]
	Да, я так и понял, что мягкие ссылки в .нет слегка не доработаны. Очистка объектов идет без связи с их размером, да и вообще без необходимости в этом. Зачем удалять обьект размером в 15кб, тем более через секунду после его создания. 0

@CookieMonsta 16 / 16 / 1 Регистрация: 12.06.2011 Сообщений: 41
	16.07.2011, 15:26
	GC.SupressFinalize(s) где s - ссылка которая не должна очищаться сборщиком мусора когда ссылки станут не нужны GC.Collect(0) 2

@SergBokh 85 / 77 / 13 Регистрация: 03.09.2009 Сообщений: 346
	16.07.2011, 18:49 [ТС]
	CookieMonsta, буду знать. А вообще конечно тогда уж обычные ссылки использовать, разницы никакой а возни намного меньше. Вот если б можно было бы задать время, на которое блокируется удаление объекта, это было бы уже интересней. 0

@VKabanov -4 / 5 / 1 Регистрация: 06.01.2014 Сообщений: 67
	18.07.2014, 13:52
	SergBokh, возможно можно залочить Lock(obj) слабую ссылку и тогда она останется живой до тех пор, пока не сдохнет нить не нее ссылающаяся? Добавлено через 37 минут SergBokh, И совсем хардкорный метод в стиле Рихтера, это : 1) Завести глобальную переменную - флаг сигнализирующий о реальной необходимости чистить кэш. 2) Объекты помещаемые в организованный с помощью слабых ссылок кэш имеют метод finalize. 3) В деструкторе в зависимости от состояния флага помечать объекты на которые ссылаются слабые ссылки к удалению (GC.ReRegisterForFinalize(this) "Горец" от Рихтера) или не помечать(если надо чтобы GC таки снес...). 0