Microsoft.Extensions.ObjectPool är en del av ASP.NET Core-infrastrukturen som stödjer att hålla en uppsättning objekt i minnet för återanvändning istället för att tillåta skräpsamling av objekt. Om objekten du vill hantera är det, kan du behöva använda objektpooler:
- Allokering/initialisering är kostsamt.
- Representerar en begränsad resurs.
- Använd det förutsägbart och ofta.
Återanvändning är ett viktigt ämne och ett oundvikligt problem som vi ofta stöter på i vår dagliga utveckling.
För att ta det enklaste och mest bekanta exemplet är databasanslutningspooler återanvända databasanslutningar.
Så vad är poängen med återanvändning?
Enkelt uttryckt minskar det onödig resursförlust.
Utöver databasanslutningar kan det finnas många andra objekt som behöver återanvändas under olika scenarier eller krav, och det finns en så kallad objektpool.
Du borde ha implementerat liknande funktioner själv, antingen med ConcurrentBag, ConcurrentQueue eller med andra lösningar.
Detta delar också en implementation i Microsofts dokumentation
Hur man gör: Skapa en objektpool med en ConcurrentBag
Inloggningen med hyperlänken är synlig.
Självklart, i .NET Core har Microsoft hjälpt oss att implementera en enkel Object Pool.
Skapa först ett nytt .NET Core-konsolprojekt och använd nuget-kommandot för att lägga till följande paket:
All kod är som följer:
Användning 1
Innan vi skapar en pool behöver vi definiera en policy. Här använder vi direkt den medföljande DefaultPooledObjectPolicy för att konstruera den.
Objektpoolen kommer att ha ett maximalt antal trådar som underhålls.
Använd Get-metoden för poolobjektet för att ta ett objekt ur objektpoolen.
Koden ovan kör resultatet
#1-464d2e03-604d-4451-b68a-8a3a2abdfccc-itsvse.com-1/1/0001 00:00:00 #2-70122aa0-a949-4c63-b878-321efe64c234-itsvse.com-01/1/0001 00:00:00 #3-de717815-796a-4349-a571-047acc125104-itsvse.com-01/1/0001 00:00:00 #4-3a404341-a560-47f7-a3b0-0d477a8ae17f-itsvse.com-01/1/0001 00:00:00 #5-51c96126-d424-4b58-b07c-6408e6c4cea6-itsvse.com-1/1/0001 00:00:00 #6-7ea4d596-fd2a-43b3-959a-9e48da58a758-itsvse.com-01/1/0001 00:00:00 #7-6874c64b-532d-4f92-a4fb-ff472da574a1-itsvse.com-01/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-01/1/0001 00:00:00 #10-fe89ed8b-4dfd-4eef-b876-b2a60ee50958-itsvse.com-01/1/0001 00:00:00 Detta resultat visar att objekten i objektpoolen är direkt nya, och vissa egenskaper är inte devalverade, vilket ofta inte har mycket praktisk betydelse just nu.
Eftersom DefaultPooledObjectPolicy är ett nytt objekt direkt, är detta många gånger inte vad vi förväntar oss!
Om du vill uppfylla vår faktiska användning måste du själv definiera en försäkring!
Låt oss titta på användning 2
Användning 2
Create-metoden används för att skapa Demo-objektet, och Return-metoden är att kasta tillbaka Demo-objektet i Object Pool (lånat och returnerat).
Objektpoolen definieras här för att endast innehålla ett objekt.
Eftersom det finns en enstegs returoperation efter att den tagits ut ur objektpoolen, bör element1 och item2 vara samma objekt.
Efter att item2 tagits ut ur objektpoolen returneras det inte, så objektpoolen skapar ett nytt objekt baserat på den policy vi definierade.
Här är utgångsresultatet av användning 2:
985b3232-0a45-4115-8480-ad3d42c0ae10-itsvse.com-15/4/2020 03:31:15 985b3232-0a45-4115-8480-ad3d42c0ae10-itsvse.com-15/4/2020 03:31:15
True 8912424a-15c5-4891-b625-25b17eee5c8b-itsvse.com-15/4/2020 03:31:15
False Du kan se att de individuella egenskaperna för punkt1, objekt2 och objekt3 är desamma, och att objekt1 och objekt2 faktiskt är samma objekt. Item3 och item1 är inte samma sak.
Användning 3
Du kan se att objekt1 och objekt2 är samma objekt. När du hämtar ett objekt från Objektpoolen tas det första objektet, så om du returnerar det och hämtar det igen får du fortfarande originalet först.
item3 tas direkt från objektpoolen där och skapas inte igen, eftersom objektpoolen här underhåller flera objekt, inte bara ett i användning 2, så det tas direkt från poolen.
Här är utgångsresultatet
f3cd5467-536b-4ffe-9c71-de53027b4869-itsvse.com-2020-04-15 03:33:58 f3cd5467-536b-4ffe-9c71-de53027b4869-itsvse.com-2020-04-15 03:33:58
True b933b593-af6d-4ebe-b21b-e8784d124764-itsvse.com-15/4/2020 03:33:58
False Samma som i användning 2, essensen är densamma.
Användning 4
Det verkar som att ovanstående användning inte är så lik vår normala användning. Vi måste fortfarande förlita oss på injektioner.
Så låt oss slutligen titta på hur man kombinerar beroendeinjektion. Självklart är essensen här fortfarande oskiljaktig från de två sakerna policy och leverantör.
Vi behöver först registrera Providern och sedan direkt ta dess instans för att skapa en Object Pool.
Om du vill använda den någon annanstans kan du injicera den genom konstruktorn.
Resultatet här är också detsamma som tidigare, det finns inte mycket att säga.
sammanfattning
Men oavsett vilken typ av användning det är måste vi förstå att Object Pool är oskiljaktigt från de tre personerna Pool, Policy och Provider.
Med de här tre kanske vi kan göra vad vi vill.
Självklart erbjuder den också flera speciella saker som du kan kolla in om du är intresserad.
LeakTrackingObjectPool
StringBuilderPooledObjectPolicy
|