Microsoft.Extensions.ObjectPool е част от инфраструктурата на ASP.NET Core, която поддържа съхранение на набор от обекти в паметта за повторна употреба, вместо да се позволява събиране на обекти без отпадъци. Ако обектите, които искате да управлявате, са, може да се наложи да използвате object pools:
- Разпределението/инициализацията е скъпо.
- Представлява ограничен ресурс.
- Използвайте го предвидимо и често.
Повторната употреба е важна тема и неизбежен проблем, с който често се сблъскваме в ежедневното си развитие.
За да вземем най-простия и най-познат пример, пуловете за връзки към бази данни са повторно използвани бази данни.
Тогава какъв е смисълът от повторната употреба?
Просто казано, това намалява ненужната загуба на ресурси.
Освен връзките към база данни, може да има много други обекти, които трябва да се използват повторно при различни сценарии или изисквания, и съществува така нареченият Object Pool.
Трябваше да си имплементирал подобни функции сам, било с ConcurrentBag, ConcurrentQueue или с други решения.
Това също споделя имплементация в документацията на Microsoft
Как да: Създам пул от обекти чрез използване на ConcurrentBag
Входът към хиперлинк е видим.
Разбира се, в .NET Core Microsoft ни помогна да реализираме прост Object Pool.
Първо, създайте нов конзолен проект за .NET Core и използвайте командата nuget, за да добавите следния пакет:
Целият код е следният:
Употреба 1
Преди да създадем пул, трябва да дефинираме Политика. Тук директно използваме включената DefaultPooledObjectPolicy, за да го конструираме.
Обектният пул ще има максимален брой поддържани нишки.
Използвайте метода Get на обекта пул, за да извадите обект от обектния пул.
Горният код изпълнява резултата
#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 ч. #3-de717815-796a-4349-a571-047acc125104-itsvse.com-1/1/0001 00:00 ч. #4-3a404341-a560-47f7-a3b0-0d477a8ae17f-itsvse.com-1/1/0001 00:00 ч. #5-51c96126-d424-4b58-b07c-6408e6c4cea6-itsvse.com-1/1/0001 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 ч. #8-ca767674-2c07-4f26-975f-4711a31d795d-itsvse.com-1/1/0001 00:00 ч. #9-a9cd1859-a919-46a0-ae5d-85b6d3d11ccb-itsvse.com-1/1/0001 00:00 ч. #10-fe89ed8b-4dfd-4eef-b876-b2a60ee50958-itsvse.com-1/1/0001 00:00 ч. Този резултат показва, че обектите в Object Pool са директно нови и някои свойства не се обезценяват, което често няма много практическо значение в момента.
Тъй като DefaultPooledObjectPolicy е нов обект директно, често това не е това, което очакваме!
Ако искате да отговаряте на нашата реална употреба, трябва сами да дефинирате полица!
Нека разгледаме употреба 2
Употреба 2
Методът Create се използва за създаване на Demo обекта, а Return е да се върне Demo обектът обратно в Object Pool (зает и върнат).
Тук пулът от обекти е дефиниран да съдържа само един обект.
Тъй като има едностъпкова операция за връщане след изваждане от пула с обекти, item 1 и item2 трябва да са един и същ обект.
След като извадите productem2 от object pool, той не се връща, така че object pool-ът ще създаде нов обект въз основа на политиката, която дефинирахме.
Ето изходния резултат от употреба 2:
985b3232-0a45-4115-8480-ad3d42c0ae10-itsvse.com-15.04.2020 3:31:15 ч. 985b3232-0a45-4115-8480-ad3d42c0ae10-itsvse.com-15.04.2020 3:31:15 ч.
True 8912424a-15c5-4891-b625-25b17eee5c8b-itsvse.com-15.04.2020 3:31:15 ч.
False Виждате, че отделните свойства на item1, item2 и item3 са еднакви, и item 1 и item 2 наистина са един и същ обект. Предмет 3 и предмет 1 не са едно и също нещо.
Употреба 3
Виждате, че item 1 и item 2 са един и същ обект. Когато изтеглите обект от Object Pool, първият ще бъде взет, така че ако го върнете и вземете отново, пак ще получите оригиналния първи.
item3 се взема директно от Object Pool там и не се създава отново, защото Object Pool тук поддържа множество обекти, а не само един в use 2, затова се взема директно от Pool.
Ето изходния резултат
f3cd5467-536b-4ffe-9c71-de53027b4869-itsvse.com-15.04.2020 3:33:58 ч. f3cd5467-536b-4ffe-9c71-de53027b4869-itsvse.com-15.04.2020 3:33:58 ч.
True b933b593-af6d-4ebe-b21b-e8784d124764-itsvse.com-15.04.2020 3:33:58 ч.
False Същото като при употреба 2, същността е същата.
Употреба 4
Изглежда, че горната употреба не е толкова подобна на обичайната ни. Все още трябва да разчитаме на инжекции.
Нека най-накрая разгледаме как да комбинираме инжекцията на зависимост. Разбира се, същността тук все още е неразделна от двете правила – Политика и Доставчик.
Първо трябва да регистрираме доставчика, а след това директно да вземем неговия инстанс, за да създадем Object Pool.
Ако искаш да го използваш другаде, можеш да го инжектираш през конструктора.
Резултатът тук също е същият като преди, няма много какво да се каже.
резюме
Но независимо от вида на употреба, трябва да разберем, че Object Pool е неразделна връзка с тримата души – Pool, Policy и Provider.
С тези трима може би можем да правим каквото си искаме.
Разбира се, предлага и няколко специални неща, които можете да разгледате, ако се интересувате.
LeakTrackingObjectPool
StringBuilderPooledObjectPolicy
|