Jeśli jest to prawdziwy wyciek pamięci niezarządzanego i nie można zmienić kodu, to niewiele można zrobić. Struktura nie może tego podnieść, ani też nie może wyczyścić tego kodu.
Podejście w tym przypadku byłoby izolacją tego komponentu. Oznacza to, że będzie dużo do zrobienia, ale nic więcej nie można zrobić.
Nie można uruchomić kodu w innej domenie aplikacji, ponieważ kod niezarządzany nie ma koncepcji domeny aplikacji.
To pozostawia poziom procesu. Zalecam utworzenie umowy serwisowej w WCF, która naśladuje połączenia do ExternalWidget
wraz z metodą Shutdown
.
Następnie należy utworzyć plik EXE, który ujawniłby tę umowę (z sesją, dzięki czemu można trzymać instancję ExternalWidget
, chyba że każde wywołanie jest bezpaństwowe) za pośrednictwem nazwanych wiązań potoków.
Jako parametr dla EXE, musiałby mieć unikalny identyfikator (użyj Guid
) i użyć go jako części konfiguracji punktu końcowego dla usługi WCF.
Następnie wykonasz połączenia, a kiedy skończysz z tym wystąpieniem ExternalWidget
, zadzwoń pod numer Shutdown
; EXE będzie wiedział, aby przestać czekać, a następnie proces zostanie zakończony, a system operacyjny odzyska pamięć.
Oczywiście, mamy tu ogromny koszt , więc jeśli zauważysz, że wykonujesz wiele połączeń i nie potrzebujesz nowego procesu dla każdego zestawu połączeń, możesz rozwinąć pomysł w usługa, która zlicza połączenia, a następnie przetwarza proces (usługa nadal będzie musiała wyłapać lub w razie potrzeby zabraknie zasobów).
Należy pamiętać, że jeśli okaże się, że problem dotyczy pamięci managed, zawsze można wyrejestrować nową domenę aplikacji, uruchomić tam kod (zbierając wyniki w razie potrzeby), a następnie zwolnić domenę aplikacji .
Utwórz mały przykładowy program demonstrujący problem i skontaktuj się z autorem biblioteki. – Henrik
Jeśli znasz przyczynę wycieku pamięci, prawdopodobnie możesz użyć odbicia, aby to naprawić (musieliśmy to zrobić ze starszą wersją biblioteki kontrolnej Infragistics). – sloth
Skąd wiadomo, że nie oczyszcza niezarządzanych zasobów? –