Это главный недостаток традиционного подсчета ссылок на сборку мусора . Свойство сборщика мусора, описывающее это поведение, является неполным сборщиком. Другие сборщики в значительной степени попадают в категорию под названием трассировка сборщиков мусора , которая включает в себя традиционную разметку, полупространство / сжатие и гибриды поколений, и не страдает от этих недостатков (но сталкивается с несколькими другими).
Все реализации JVM и CLI, о которых я знаю, используют полные сборщики , что означает, что они не страдают от конкретной проблемы, о которой вы здесь спрашиваете. Насколько мне известно, из этих Jikes RVM является единственным, снабжающим коллектор подсчета ссылок (один из его многочисленных).
Еще одна интересная вещь, на которую следует обратить внимание, - это решение проблемы полноты при сборке мусора при подсчете ссылок, и получившиеся в результате сборщики демонстрируют некоторые интересные характеристики производительности, которые трудно получить при трассировке сборщиков. К сожалению, самые эффективные алгоритмы сбора мусора с подсчетом ссылок и большинство модификаций полноты полагаются на помощь компилятора, поэтому перенести их в C ++ shared_ptr<T> сложно / не происходит. Вместо этого у нас есть weak_ptr<T> и документированные правила (извините за неоптимальную ссылку - очевидно, документация ускользает от меня) о простом избежании проблем. Это не первый раз (еще одна посредственная ссылка), мы видели этот подход, и надежда на то, что дополнительная работа по предотвращению проблем с памятью меньше, чем объем работы, необходимый для поддержки кода, который не ' т shared_ptr<T> и т. д.
Посредственные ссылки потому, что большая часть моего справочного материала разбросана в заметках из класса управления памятью прошлого семестра.