Jaki jest prawidłowy sposób na uwolnienie pamięci w C#

. NET garbage collector zajmuje się tym wszystkim za Ciebie.

Jest w stanie określić, kiedy obiekty nie są już odwoływane i (ostatecznie) uwolni przydzieloną im pamięć.

Obiekty są kwalifikowane do zbierania śmieci, gdy wyjdą poza zakres stają się nieosiągalne (dzięki ben!). Pamięć nie zostanie uwolniona, chyba że Śmieciarz uwierzy, że kończy ci się pamięć.

Dla zarządzanych zasobów, garbage collector będzie wiedział, kiedy to jest, i nie musisz nic robić.

Dla niezarządzanych zasobów (takich jak połączenia z bazami danych lub otwartymi plikami) garbage collector nie ma możliwości sprawdzenia, ile pamięci zużywają, i dlatego musisz zwolnić je ręcznie (używając dispose, lub znacznie lepiej używając bloku)

Jeśli obiekty nie są zwalniane, albo masz dużo pamięci i nie ma takiej potrzeby, albo zachowujesz odniesienie do nich w swojej aplikacji, a zatem garbage collector ich nie uwolni (w przypadku, gdy faktycznie użyjesz tego odniesienia, które utrzymałeś)

1. Tak
Co masz na myśli mówiąc to samo? Zostanie ona ponownie wykonana za każdym razem, gdy metoda zostanie uruchomiona.
2. Tak, moduł. Net garbage collector używa algorytmu, który zaczyna się od dowolnych zmiennych globalnych/in-scope, przemierza je, podążając rekurencyjnie za dowolnym odniesieniem, i usuwa dowolny obiekt w pamięci uznany za nieosiągalny. zobacz tutaj, aby uzyskać więcej informacji na temat zbierania śmieci
3. tak, pamięć wszystkich zmiennych zadeklarowanych w metodzie jest zwalniana, gdy metoda kończy się, ponieważ wszystkie są nieosiągalne. Ponadto wszelkie zmienne zadeklarowane, ale nigdy nie używane, zostaną zoptymalizowane przez kompilator, więc w rzeczywistości twoja zmienna Foo nigdy nie zajmie pamięci.
4. Instrukcja using po prostu wywołuje dispose na IDisposable obiekcie, gdy się kończy, więc jest to równoważne z drugim podpunktem. Oba wskażą, że skończyłeś z obiektem i poinformują GC, że jesteś gotowy, aby go puścić. Nadpisanie jedynego odniesienia do obiektu będzie miał podobny efekt.

Odpowiedzmy na twoje pytania jeden po drugim.

1. tak, tworzysz nowy obiekt za każdym razem, gdy ta instrukcja jest wykonywana, jednak wychodzi on "poza zakres" po wyjściu z metody i kwalifikuje się do usunięcia śmieci.
2. cóż, to będzie to samo co #1, z tym wyjątkiem, że użyłeś typu string. Typ string jest niezmienny i otrzymujesz nowy obiekt za każdym razem, gdy wykonujesz przypisanie.
3. tak, garbage collector zbiera obiekty poza zakresem, chyba że przypiszesz obiekt do zmiennej o dużym zakresie, takiej jak zmienna klasy.
Tak.
4. Instrukcja using dotyczy tylko obiektów implementujących interfejs IDisposable. Jeśli tak jest, najlepszym rozwiązaniem jest użycie obiektów z zakresu metody. Nie umieszczaj Foo o w większym zakresie, chyba że masz ku temu dobry powód. Najlepiej jest ograniczyć zakres dowolnej zmiennej do najmniejszego zakresu, który ma sens.

Oto krótki przegląd:

• Gdy referencje znikną, Twój obiekt prawdopodobnie zostanie wyrzucony na śmietnik.
• możesz liczyć tylko na statystyczną kolekcję, która utrzyma rozmiar sterty w normie, pod warunkiem, że wszystkie odniesienia do śmieci naprawdę znikną. Innymi słowy, nie ma gwarancji, że konkretny obiekt zostanie kiedykolwiek zbierany.
  • wynika z tego, że Twój finalizer również nigdy nie będzie miał gwarancji, że zostanie wywołany. Unikaj finalizatorów.
• dwa wspólne źródła przecieków:
  • procedury obsługi zdarzeń i delegatów są odniesieniami. Jeśli subskrybujesz Zdarzenie obiektu, odnosisz się do niego. Jeśli masz delegata do metody obiektu, odwołujesz się do niej.
  • zasoby niezarządzane z definicji nie są zbierane automatycznie. Do tego służy IDisposable pattern.
• na koniec, jeśli chcesz referencji, która nie zapobiega zbieraniu obiektu, spójrz na WeakReference.

One ostatnia rzecz: jeśli zadeklarujesz Foo foo; bez przypisania go nie musisz się martwić - nic nie wyciekło. Jeśli Foo jest typem odniesienia, nic nie zostało utworzone. Jeśli Foo jest typem wartości, jest ona przydzielana na stosie i w ten sposób zostanie automatycznie oczyszczona.

Śmieciarz przyjdzie i wyczyści wszystko, co nie ma już odniesień do niego. Jeśli nie masz niezarządzanych zasobów wewnątrz Foo, wywołanie Dispose lub użycie instrukcji using na nim nie pomoże Ci zbytnio.

Jestem całkiem pewien, że to dotyczy, ponieważ to było jeszcze w C#. Ale brałem udział w kursie projektowania gier przy użyciu XNA i spędziliśmy trochę czasu rozmawiając o garbage collector dla C#. Wywóz śmieci jest drogi, ponieważ trzeba sprawdzić, czy nie ma żadnych odniesień do obiekt, który chcesz zebrać. Więc GC stara się odkładać to tak długo, jak to możliwe. Tak długo, jak nie zabrakło fizycznej pamięci, gdy twój program poszedł do 700MB, to może być po prostu GC jest leniwy i nie martwiąc się o to jeszcze.

Ale jeśli po prostu użyjesz Foo o poza pętlą i stworzysz o = new Foo() za każdym razem, wszystko powinno działać dobrze.

Jak wskazuje Brian, GC może zbierać wszystko, co jest nieosiągalne, w tym obiekty, które nadal są w zasięgu, a nawet gdy metody instancji tych obiektów są nadal wykonywane. rozważmy następujący kod:

class foo
{
    static int liveFooInstances;

    public foo()
    {
        Interlocked.Increment(ref foo.liveFooInstances);
    }

    public void TestMethod()
    {
        Console.WriteLine("entering method");
        while (Interlocked.CompareExchange(ref foo.liveFooInstances, 1, 1) == 1)
        {
            Console.WriteLine("running GC.Collect");
            GC.Collect();
            GC.WaitForPendingFinalizers();
        }
        Console.WriteLine("exiting method");
    }

    ~foo()
    {
        Console.WriteLine("in ~foo");
        Interlocked.Decrement(ref foo.liveFooInstances);
    }

}

class Program
{

    static void Main(string[] args)
    {
        foo aFoo = new foo();
        aFoo.TestMethod();
        //Console.WriteLine(aFoo.ToString()); // if this line is uncommented TestMethod will never return
    }
}

Jeśli zostanie uruchomiony z kompilacją debugera, z dołączonym debugerem lub z podaną linią, nieaktywny TestMethod nigdy nie powróci. Ale uruchamianie bez dołączonego debuggera TestMethod powróci.