Munkaállomás és kiszolgáló szemétgyűjtése
A szemétgyűjtő önhangoló, és számos forgatókönyvben használható. A szemétgyűjtés típusát azonban a számítási feladat jellemzői alapján állíthatja be. A CLR a következő típusú szemétgyűjtést biztosítja:
A munkaállomás szemétgyűjtése (GC), amelyet ügyfélalkalmazásokhoz terveztek. Ez az önálló alkalmazások alapértelmezett GC-íze. Az üzemeltetett alkalmazások esetében, például az ASP.NET által üzemeltetett alkalmazások esetében a gazdagép határozza meg az alapértelmezett GC-ízt.
A munkaállomás szemétgyűjtése lehet egyidejű vagy nem egyidejű. Az egyidejű (vagy háttérbeli) szemétgyűjtés lehetővé teszi, hogy a felügyelt szálak folytatják a műveleteket a szemétgyűjtés során. A háttérbeli szemétgyűjtés felváltja az egyidejű szemétgyűjtést .NET-keretrendszer 4- és újabb verziókban.
Kiszolgálói szemétgyűjtés, amely olyan kiszolgálóalkalmazásokhoz készült, amelyek nagy átviteli sebességet és méretezhetőséget igényelnek.
A .NET Core-ban a kiszolgáló szemétgyűjtése lehet nem egyidejű vagy háttér.
A .NET-keretrendszer 4.5-ös és újabb verzióiban a kiszolgáló szemétgyűjtése nem lehet egyidejű vagy háttér. A .NET-keretrendszer 4-ben és az előző verziókban a kiszolgáló szemétgyűjtése nem egyidejű.
Az alábbi ábrán azok a dedikált szálak láthatók, amelyek elvégzik a szemétgyűjtést egy kiszolgálón:
A teljesítménnyel kapcsolatos megfontolások
Munkaállomás GC
A munkaállomás szemétgyűjtésével kapcsolatos szálkezelés és teljesítménybeli szempontok a következők:
A gyűjtemény azon a felhasználói szálon történik, amely aktiválta a szemétgyűjtést, és ugyanazon a prioritáson marad. Mivel a felhasználói szálak általában normál prioritással futnak, a szemétgyűjtőnek (amely normál prioritású szálon fut) versenyeznie kell más szálakkal a processzoridőhöz. (A natív kódot futtató szálak nem függeszthetők fel sem a kiszolgálón, sem a munkaállomás szemétgyűjtésén.)
A munkaállomás szemétgyűjtése mindig olyan számítógépen használatos, amely csak egy logikai PROCESSZORt használ, a konfigurációs beállítástól függetlenül.
Kiszolgálói GC
A kiszolgálói szemétgyűjtés szálkezelésével és teljesítményével kapcsolatos szempontok a következők:
A gyűjtemény több dedikált szálon történik. Windows rendszeren ezek a szálak prioritási
THREAD_PRIORITY_HIGHEST
szinten futnak.Minden logikai PROCESSZORhoz egy halom és egy dedikált szál tartozik, amely szemétgyűjtést végez, és a halomokat egyszerre gyűjti össze. Minden halom tartalmaz egy kis objektum halom és egy nagy objektum halom, és minden halom elérhető a felhasználói kóddal. A különböző halomokon lévő objektumok hivatkozhatnak egymásra.
Mivel több szemétgyűjtési szál is működik együtt, a kiszolgálói szemétgyűjtés gyorsabb, mint a munkaállomás szemétgyűjtése azonos méretű halomra.
A kiszolgálói szemétgyűjtés gyakran nagyobb méretű szegmensekkel rendelkezik. Ez azonban csak általánosítás: a szegmens mérete implementációspecifikus, és változhat. Az alkalmazás finomhangolása során ne tegyen feltételezéseket a szemétgyűjtő által lefoglalt szegmensek méretéről.
A kiszolgálói szemétgyűjtés erőforrás-igényes lehet. Tegyük fel például, hogy 12 folyamat használja a kiszolgálói GC-t egy olyan számítógépen, amely négy logikai CPU-val rendelkezik. Ha az összes folyamat egyszerre gyűjti a szemetet, akkor zavarják egymást, mivel 12 szál lenne ütemezve ugyanazon a logikai CPU-n. Ha a folyamatok aktívak, nem jó ötlet, ha mindegyik kiszolgálói GC-t használ.
Ha több száz alkalmazáspéldányt futtat, fontolja meg a munkaállomás szemétgyűjtésének használatát egyidejűleg letiltott szemétgyűjtéssel. Ez kevesebb környezetváltást eredményez, ami javíthatja a teljesítményt.
Lásd még
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: