Co to jest Bajty prywatne, Bajty wirtualne, zestaw roboczy?

Krótka odpowiedź na to pytanie jest taka, że żadna z tych wartości nie jest wiarygodnym wskaźnikiem ilości pamięci używanej przez program wykonywalny i żadna z nich nie jest odpowiednia do debugowania wycieku pamięci.

Prywatne bajty odnoszą się do ilości pamięci, o jaką proces wykonywalny poprosił - niekoniecznie takiej ilości, jaką jest faktycznie używająca . Są one "prywatne", ponieważ (zazwyczaj) wykluczają pliki mapowane pamięcią (tj. współdzielone biblioteki DLL). Ale-tu jest haczyk - niekoniecznie wykluczają pamięć przydzieloną przez te pliki . Nie da się stwierdzić, czy zmiana w prywatnych bajtach była spowodowana samym programem wykonywalnym, czy też powiązaną biblioteką. Prywatne bajty są również nie wyłącznie pamięcią fizyczną; mogą być wysyłane na dysk lub na listę stron w trybie gotowości(tzn. nie są już używane, ale jeszcze nie są wysyłane).

Zbiór roboczy odnosi się do całkowitej fizycznej PAMIĘCI (RAM) używanej przez proces. Jednak w przeciwieństwie do prywatnych bajtów, obejmuje to również pliki mapowane w pamięci i różne inne zasoby, więc jest to jeszcze mniej dokładny pomiar niż prywatne bajty. Jest to ta sama wartość, która jest zgłaszana w Menedżerze Zadań "użycie Mem" i była źródłem niekończących się nieporozumień w ostatnich latach. Pamięć w zestawie roboczym jest "fizyczna" w tym sensie, że może być adresowana bez błędu strony; jednak lista stron w trybie gotowości jest również nadal fizycznie w pamięci, ale nie raportowane w zestawie roboczym i dlatego może się zdarzyć, że "użycie Mem" nagle spadnie, gdy zminimalizujesz aplikację.

Wirtualne bajty są całkowitą wirtualną przestrzenią adresową zajmowaną przez cały proces. Jest to jak zestaw roboczy, w tym sensie, że zawiera pliki mapowane w pamięci (współdzielone biblioteki DLL), ale zawiera również dane z listy gotowości i dane, które zostały już wysłane i znajdują się w pliku stron na dysku gdzieś. Całkowita liczba użytych wirtualnych bajtów przez każdy proces w systemie pod dużym obciążeniem doda znacznie więcej pamięci niż maszyna faktycznie ma.

Więc relacje są:

Pliki prywatne są tym, co Twoja aplikacja faktycznie przydzieliła, ale zawierają użycie pliku stron; Zbiór roboczy to nie stronicowane prywatne bajty plus pliki mapowane w pamięci;
• wirtualne bajty są zestawem roboczym plus paged prywatnych bajtów i listy gotowości.

Tu jest jeszcze jeden problem; tak samo jak shared biblioteki mogą przydzielać pamięć wewnątrz modułu aplikacji, co prowadzi do potencjalnych fałszywych alarmów zgłaszanych w prywatnych bajtach aplikacji, Twoja aplikacja {[8] } może również skończyć alokacją pamięci wewnątrz modułówwspółdzielonych , co prowadzi do fałszywych negatywów {8]}. Oznacza to, że aplikacja może mieć wyciek pamięci, który nigdy nie przejawia się w prywatnych bajtach. Mało prawdopodobne, ale możliwe.

Prywatne bajty są rozsądnym przybliżeniem z ilości pamięci, której używa Twój plik wykonywalny i może być użyty do pomocy zawęzić listę potencjalnych kandydatów do wycieku pamięci; jeśli widzisz, że liczba rośnie i rośnie stale i bez końca, chcesz sprawdzić ten proces pod kątem wycieku. Nie może to jednak udowodnić , że istnieje lub nie jest przeciek.

Jednym z najskuteczniejszych narzędzi do wykrywania / korygowania wycieków pamięci w systemie Windows jest w rzeczywistości Visual Studio (link idzie do strony na using VS for wycieków pamięci, Nie strony produktu). Racjonalne oczyszczenie to inna możliwość. Microsoft ma również bardziej ogólny dokument dotyczący najlepszych praktyk na ten temat. Istnieje więcej narzędzi wymienionych w tym poprzednie pytanie .

Mam nadzieję, że to wyjaśni kilka rzeczy! Śledzenie wycieków pamięci jest jedną z najtrudniejszych rzeczy do zrobienia w debugowaniu. Powodzenia.