Почему в .NET нет SoftReference, а также WeakReference, как в Java?

Я считаю, что фундаментальная причина того, что NET не имеет мягких ссылок, заключается в том, что она может полагаться на операционную систему с виртуальной памятью. Процесс Java должен указать максимальную память ОС (например, с помощью -Xmx128M), и он никогда не занимает больше памяти ОС, чем это. Принимая во внимание, что процесс NET продолжает занимать необходимую ему память ОС, которую ОС предоставляет виртуальной памяти на диске, когда заканчивается оперативная память. Если бы NET допускала программные ссылки, тогда среда выполнения NET не знала бы, когда их освобождать, если бы она либо не заглянула глубоко в ОС, чтобы увидеть, действительно ли ее память выгружается на диске (неприятная зависимость от ОС/CLR), либо не запросила бы среду выполнения для указать максимальный объем памяти процесса (например, эквивалент -Xmx). Я предполагаю, что Microsoft не хочет добавлять -Xmx в NET, потому что они считают, что ОС должна решать, сколько ОЗУ получает каждый процесс (выбирая, какие страницы виртуальной памяти хранить в ОЗУ или на диске), а не сам процесс.

Java SoftReferences используются при создании чувствительных к памяти кэшей (они не служат никакой другой цели).

Начиная с .NET 4, .NET имеет класс System.Runtime.Caching.MemoryCache, который, вероятно, удовлетворит любые такие потребности.

Наличие WeakReference с различными уровнями уязвимости (приоритета) звучит хорошо, но также может усложнить, а не облегчить работу GC. (Я понятия не имею о внутренностях GC, но) я бы предположил, что существует какая-то дополнительная статистика доступа, которая хранится для объектов WeakReference, чтобы GC мог эффективно их очищать (например, он может избавиться от наименее используемых элементов первый).

Более чем вероятно, что добавленная сложность не сделает ничего более эффективным, потому что самый эффективный способ — сначала избавиться от редко используемых WeakReferences. Если бы вы могли назначить приоритет, как бы вы это сделали? Это пахнет преждевременной оптимизацией: большую часть времени программист ничего не знает и только догадывается; результатом является более медленный цикл сбора GC, который, вероятно, восстанавливает неправильные объекты.

Однако возникает вопрос: если вы заботитесь об исправлении объекта WeakReference.Target, действительно ли это хорошее использование WeakReference?

Это как кеш. Вы засовываете данные в кеш и просите кеш сделать их устаревшими через x минут, но большинство кешей никогда не гарантирует их сохранение. Это просто гарантирует, что если это произойдет, срок его действия истечет в соответствии с запрошенной политикой.

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

Может быть, класс ASP.NET Cache (System.Web.Caching.Cache) может помочь достичь того, чего вы хотите? Он автоматически удаляет объекты, если памяти становится мало:

• Обзор кэширования ASP.NET

Вот статья, в которой показано, как использовать класс Cache в приложении Windows Forms.

цитата из: Эквивалентно SoftReference в .net?

Не забывайте, что у вас также есть свои стандартные ссылки (те, которые вы используете ежедневно). Это дает вам еще один уровень.

WeakReferences следует использовать, когда вам все равно, исчезнет ли объект, в то время как SoftReferences действительно следует использовать только тогда, когда вы будете использовать обычную ссылку, но вы предпочитаете, чтобы ваш объект был очищен, а не из-за нехватки памяти. Я не уверен в деталях, но подозреваю, что GC обычно отслеживает SoftReferences, но не WeakReferences при определении того, какие объекты активны, но при нехватке памяти также пропускает SoftReferences.

Я предполагаю, что разработчики .Net посчитали, что эта разница сбивает с толку большинство людей или что SoftReferences добавляют больше сложности, чем им действительно хотелось бы, и поэтому решили их не использовать.

В качестве примечания: AFAIK PhantomReferences в основном предназначены для внутреннего использования виртуальной машиной и не предназначены для фактического использования клиентом.

Возможно, должно быть свойство, в котором вы можете указать, в каком поколении объект >= перед его сборкой. Поэтому, если вы укажете 1, это будет самая слабая ссылка. Но если вы укажете 3, то он должен пережить как минимум 3 предыдущие коллекции, прежде чем его можно будет рассматривать как саму коллекцию.

Я думал флаг восстановления трека для этого не годится, потому что к тому моменту объект уже доработан? Хотя может ошибся...

(PS: я ОП, только что зарегистрировался. PITA, что он не наследует вашу историю от «незарегистрированных» учетных записей.)

Возможно, вы ищете параметр «trackResurrection», переданный конструктору?

Класс GC также предлагает некоторую помощь.

Не знаю, почему в .NET нет Softreferences. НО в Java Softreferences IMHO чрезмерно используются. Причина в том, что, по крайней мере, на сервере приложений вы хотели бы иметь возможность влиять на то, как долго живут ваши Softreferenzen для каждого приложения. В настоящее время это невозможно в Java.