Dziwny wyciek pamięci wpf
Mam dziwny problem z wyciekiem pamięci przez MenuItem w wpf.
Mogę obserwować ten wyciek pamięci w profilerze pamięci .net.
Nasza aplikacja ma następującą architekturę:
MainWindow, w którym dane szablonują ApplicationPresenter. ApplicationPresenter działa przez cały okres użytkowania aplikacji. ApplicationPresenter ma MainPresenter, który zasadniczo reprezentuje plik i jego zawartość. Po załadowaniu pliku (rozwiązania) tworzony jest nowy główny prezenter, a stary wyrzucany.
Szablon danych dla prezentera aplikacji wygląda tak:
<DataTemplate DataType="{x:Type ApplicationPresenter}">
<ContentPresenter Content="{Binding Presenter}"/>
</DataTemplate>
MainPresenter ma wiele kart, ale zasadniczo jego szablon danych jest dużym menu wewnątrz DockPanel. Menu zawiera kilka zagnieżdżonych elementów, np. Plik, Edycja, Widok ... u góry i wewnątrz Pliku masz Nowe, Otwarte ..., a następnie podmenu, takie jak Import, który następnie ma ładunek samych elementów.
Wszystkie te prezentery implementują INotifyPropertyChanged i mamy implementację ICommand, która omija szaleństwo związane z tym (generalnie polecenia nie przeciekają w aplikacji).
Jednak widzę, że podczas otwierania nowego rozwiązania (lub dowolnej innej operacji, która tworzy nowy MainPresenter), oryginalny MainPresenter (pierwszy, który jest tworzony podczas ładowania aplikacji) zawiesza się w pamięci poprzez pole _submenuPopup MenuItem! Załączam zdjęcie z profilera, aby pokazać, co mam na myśli:
Liczba instancji nie przekracza dwóch podczas wykonywania większej liczby operacji i zawsze jest to pierwszy prezenter w pamięci. Wszystkie menu działają (w tym pozycje w podmenu)
Czy ktoś zna ten problem i wie, jak go rozwiązać?
Nie jest to tak krytyczne, jak tylko jedno rozwiązanie, co oznacza, że nie doprowadzi do wyjątku OutOfMemoryException. Jednak może to być dość kosztowne, ponieważ program można otworzyć przez podwójne kliknięcie plików (co oznacza, że pierwszy prezenter może trzymać dużą ilość danych), potencjalnie podwajając wykorzystanie pamięci niepotrzebnie.