Sprzątanie klas/kolekcji przez GC

Witam. Zastanawia mnie kilka rzeczy.
Jeśli mamy dwie klasy które zawierają w sobie siebie nawzajem czyli np:

• w klasie A jest obiekt przez który dostaniemy się do klasy B
• w klasie B jest obiekt przez który dostaniemy się do klasy A
  i te obie klasy są wewnątrz klasy C to jeśli do klasy C pozbędziemy się wszelkich referencji to czy klasy A i B zostaną także usunięte?
  Wbrew pozorom one dalej są referencjami między sobą.
  Po usunięciu referencji do klasy C nie mamy dostępu do klas A i B więc logiczne byłoby je usunąć ale czy GC tak zrobi? Przecież dalej są referencjami do samych siebie.
  Trzeba takie coś ręcznie null'ować jeszcze?

I drugi scenariusz. Czy jeśli posiadamy kolekcje w klasie a do tejże klasy pozbywamy się wszelkich referencji to czy kolekcje też się usuwają? Czy zostają?
Dzięki za wszelkie odpowiedzi.

http://stackoverflow.com/questions/400706/circular-references-cause-memory-leak

Łapka w górę. Dzięki za link. Czyli jak mam jakiś wyciek to problem najprawdopodobniej jest w eventhandlerach (z tym GC sobie nie radzi?)?

To nie jest tak, że GC sobie nie radzi z event handlerami, tylko GC operuje na referencjach i nie jest wróżką. Problemy zaczynają się wtedy, gdy mamy obiekty A i B oraz do zdarzenia X obiektu B podpinamy metodę Y obiektu A, to nawet jeśli ustawimy obiekt A na null, nie zostanie on usunięty przez GC, bo nadal jest podpięty do zdarzenia B.X.
Aby się przed tym zabezpieczyć należy użyć weak event pattern czy czegoś takiego. (Nie programuję ze zdarzeniami, więc nie jestem pewien.)

UnlimitedPL napisał(a):

Łapka w górę. Dzięki za link. Czyli jak mam jakiś wyciek to problem najprawdopodobniej jest w eventhandlerach (z tym GC sobie nie radzi?)?

Jest to jedna z opcji. Ale mozesz tez miec cos co wymaga manualnego zwolnienia pamieci a tego nie robisz. Albo mozesz miec wlasna (sprytna inaczej) implementacje stosu ktora przy resetowaniu nie wywala referencji ze szczytu itd itp

Czyli jak mam jakiś wyciek to problem najprawdopodobniej jest w eventhandlerach (z tym GC sobie nie radzi?)?

Tu nie chodzi o "radzenie sobie". Nie może zwolnić obiektu, do którego wciąż istnieje referencja, a podczepiony event handler się do takich też zalicza.

somekind napisał(a):

To nie jest tak, że GC sobie nie radzi z event handlerami, tylko GC operuje na referencjach i nie jest wróżką. Problemy zaczynają się wtedy, gdy mamy obiekty A i B oraz do zdarzenia X obiektu B podpinamy metodę Y obiektu A, to nawet jeśli ustawimy obiekt A na null, nie zostanie on usunięty przez GC, bo nadal jest podpięty do zdarzenia B.X.
Aby się przed tym zabezpieczyć należy użyć weak event pattern czy czegoś takiego. (Nie programuję ze zdarzeniami, więc nie jestem pewien.)

Ale jesli w tym wypadku A i B są wewnątrz klasy C i tą klasę C wy-null-uje to czy A i B z tymi zdarzeniami się wyczyszczą (bez tak - według linku wyżej ale z?)?

UnlimitedPL napisał(a):

somekind napisał(a):

To nie jest tak, że GC sobie nie radzi z event handlerami, tylko GC operuje na referencjach i nie jest wróżką. Problemy zaczynają się wtedy, gdy mamy obiekty A i B oraz do zdarzenia X obiektu B podpinamy metodę Y obiektu A, to nawet jeśli ustawimy obiekt A na null, nie zostanie on usunięty przez GC, bo nadal jest podpięty do zdarzenia B.X.
Aby się przed tym zabezpieczyć należy użyć weak event pattern czy czegoś takiego. (Nie programuję ze zdarzeniami, więc nie jestem pewien.)

Ale jesli w tym wypadku A i B są wewnątrz klasy C i tą klasę C wy-null-uje to czy A i B z tymi zdarzeniami się wyczyszczą (bez tak - według linku wyżej ale z?)?

jak najbardziej, tak wlasnie to dziala

UnlimitedPL napisał(a):

Ale jesli w tym wypadku A i B są wewnątrz klasy C i tą klasę C wy-null-uje to czy A i B z tymi zdarzeniami się wyczyszczą (bez tak - według linku wyżej ale z?)?

Jeśli do A i B nie będzie się dało dojść od innych korzeni, to tak.