A Microsoft.Extensions.ObjectPool a ASP.NET Core infrastruktúrájának része, amely támogatja az objektumok memóriában való újrahasználat céljából történő megtartását a szemétgyűjtés helyett. Ha azokat az objektumokat, amiket kezelni szeretnél, akkor esetleg objektumkészleteket kell használnod:
- Az elosztás/inicializáció költséges.
- Korlátozott erőforrást képvisel.
- Használd kiszámíthatóan és gyakran.
Az újrahasznosítás fontos téma és elkerülhetetlen probléma, amellyel gyakran találkozunk a mindennapi fejlődésünkben.
A legegyszerűbb és legismertebb példával nézzük, az adatbázis-kapcsolati poolok újrahasznosított adatbázis-kapcsolatok.
Szóval mi értelme az újrahasználatnak?
Egyszerűen fogalmazva, csökkenti a felesleges erőforrás-veszteséget.
Az adatbázis-kapcsolatokon kívül számos más objektum is lehet, amelyet különböző helyzetek vagy követelmények esetén újra kell használni, és létezik egy úgynevezett Objektum Pool.
Neked is hasonló funkciókat kellett volna megvalósítanod, akár ConcurrentBag-kel, akár ConcurrentQueue-val, vagy más megoldásokkal.
Ez is hasonló a Microsoft dokumentációjában található megvalósításhoz
Hogyan hozz létre objektumkészletet ConcurrentBag használatával
A hiperlink bejelentkezés látható.
Természetesen a .NET Core-ban a Microsoft segített egy egyszerű Object Pool megvalósításában.
Először hozz létre egy új .NET Core konzolprojektet, és a nuget parancsot használjuk a következő csomag hozzáadásához:
Az összes kód a következő:
Használat 1
Mielőtt egy poolt hoznunk létre, meg kell határoznunk egy Szabályzatot. Itt közvetlenül a mellékelt DefaultPooledObjectPolicy rendszert használjuk a felépítéshez.
Az objektum pool maximális számú szálat tart fenn.
Használd a pool objektum Get metódusát, hogy kivegyél egy objektumot az objektum poolból.
A fenti kód futtatja az eredményt
#1-464d2e03-604d-4451-b68a-8a3a2abdfccc-itsvse.com-1/1/0001 00:00:00 #2-70122aa0-a949-4c63-b878-321efe64c234-itsvse.com-1/1/0001 00:00:00 #3-de717815-796a-4349-a571-047acc125104-itsvse.com-1/1/0001 00:00:00 #4-3a404341-a560-47f7-a3b0-0d477a8ae17f-itsvse.com-1/1/0001 00:00 00:00 #5-51c96126-d424-4b58-b07c-6408e6c4cea6-itsvse.com-01/1/0001 00:00:00 #6-7ea4d596-fd2a-43b3-959a-9e48da58a758-itsvse.com-1/1/0001 00:00:00 #7-6874c64b-532d-4f92-a4fb-ff472da574a1-itsvse.com-1/1/0001 00:00:00 #8-ca767674-2c07-4f26-975f-4711a31d795d-itsvse.com-1/1/0001 00:00:00 #9-a9cd1859-a919-46a0-ae5d-85b6d3d11ccb-itsvse.com-1/1/0001 00:00:00 #10-fe89ed8b-4dfd-4eef-b876-b2a60ee50958-itsvse.com-1/1/0001 00:00 00:00 Ez az eredmény azt mutatja, hogy az Objektum Pool objektumai közvetlenül újítottak, és egyes tulajdonságok nem kerülnek leértékelhetővé, ami jelenleg gyakran nem bír sok gyakorlati jelentőséggel.
Mivel a DefaultPooledObjectPolicy közvetlenül új objektum, sokszor ez nem az, amire számítunk!
Ha szeretnéd megfelelni a tényleges felhasználásunknak, neked kell meghatároznod egy kötvényt!
Nézzük meg a 2. használatot
Használat 2
A Create módszert használják a Demo objektum létrehozására, a Return módszer pedig a Demo objektumot visszadobva az Object Poolba (kölcsönzött és visszaküldve).
Az objektumkészlet itt csak egy objektumot tartalmaz.
Mivel az objektum poolból való kilépés után egylépéses visszatérési művelet van, az item 1 és az item 2 ugyanaz az objektum kell, hogy legyen.
Miután kivettük az item 2-t az objektumpoolból, nem tér vissza, így az objektumpool új objektumot hoz létre az általunk meghatározott szabályzat alapján.
Íme a 2. használat kimenete:
985b3232-0a45-4115-8480-ad3d42c0ae10-itsvse.com-2020.04.15. 3:31:15 985b3232-0a45-4115-8480-ad3d42c0ae10-itsvse.com-2020.04.15. 3:31:15
True 2020.8912424a-15c5-4891-b625-25b17eee5c8b-itsvse.com.04.15. 3:31:15
False Láthatod, hogy az 1, a 2. és a 3. elem egyedi tulajdonságai ugyanazok, és az 1. és a 2. elem valóban ugyanaz az objektum. A 3. és az 1. elem nem ugyanaz.
Használat 3
Láthatod, hogy az 1. és 2. elem ugyanaz a tárgy. Amikor egy tárgyat a Tárgy Poolból hozol le, az elsőt veszik el, így ha visszaszerzed és visszaszerzed, akkor is az eredetit kapod meg először.
az item 3 közvetlenül az Objektum Poolból származik, és nem hozza létre újra, mert az Objektum Pool több objektumot tart fenn, nem csak egyet a 2. használatban, tehát közvetlenül a Poolból származik.
Íme a kimeneti eredmény
2020.f3cd5467-536b-4ffe-9c71-de53027b4869-itsvse.com.04.15. 3:33:58 2020.f3cd5467-536b-4ffe-9c71-de53027b4869-itsvse.com.04.15. 3:33:58
True 2020.04.b933b593-af6d-4ebe-b21b-e8784d124764-itsvse.com 04.15. 3:33:58
False Ugyanúgy, mint a második használatnál, az esszenciája ugyanaz.
Használat 4
Úgy tűnik, hogy a fent említett használat nem annyira hasonlít a szokásos használatunkhoz. Még mindig az injekcióra kell támaszkodnunk.
Szóval nézzük meg végül, hogyan lehet kombinálni a függőségi injekciót. Természetesen a lényeg itt még mindig elválaszthatatlan a Policy és a Szolgáltató két dologtól.
Először regisztrálnunk kell a szolgáltatót, majd közvetlenül el kell vinnünk az instance-ját, hogy létrehozzunk egy Objektum Poolt.
Ha máshol szeretnéd használni, befecskendezheted a konstruktoron keresztül.
Az eredmény itt is ugyanaz, mint korábban, nincs sok mondanivaló.
összefoglalás
De bármilyen használatról is legyen szó, meg kell értenünk, hogy az Object Pool elválaszthatatlan a Pool, a Policy és a Provider három figurától.
Ezzel a hármal talán azt csinálhatunk, amit csak akarunk.
Természetesen több különleges dolgot is kínál, amelyeket megnézhetsz, ha érdekel.
LeakTrackingObjectPool
StringBuilderPooledObjectPolicy
|