Microsoft.Extensions.ObjectPool fait partie de l’infrastructure ASP.NET Core, qui permet de conserver un ensemble d’objets en mémoire pour la réutilisation au lieu d’autoriser la collecte des objets par la mémoire.
Si les objets que vous souhaitez gérer le sont, vous devrez peut-être utiliser des pools d’objets :
- L’allocation/l’initialisation est coûteuse.
- Cela représente une ressource limitée.
- Utilisez-les de façon prévisible et fréquente.
La réutilisation est un sujet important et un problème inévitable que nous rencontrons souvent dans notre développement quotidien.
Pour prendre l’exemple le plus simple et le plus familier, les pools de connexions de bases de données sont des connexions de base de données réutilisées.
Alors, à quoi sert la réutilisation ?
En termes simples, cela réduit les pertes de ressources inutiles.
En plus des connexions à la base de données, il peut y avoir de nombreux autres objets qui doivent être réutilisés selon différents scénarios ou exigences, et il existe un soi-disant Object Pool.
Vous auriez dû implémenter des fonctions similaires vous-même, soit avec ConcurrentBag, soit ConcurrentQueue, ou avec d’autres solutions.
Cela partage également une implémentation dans la documentation Microsoft
Comment : Créer un pool d’objets en utilisant un ConcurrentBag
La connexion hyperlientérée est visible.
Bien sûr, dans .NET Core, Microsoft nous a aidés à implémenter un simple Object Pool.
Tout d’abord, créez un nouveau projet console .NET Core et utilisez la commande nuget pour ajouter le package suivant :
Tout le code est le suivant :
Utilisation 1
Avant de créer un pool, nous devons définir une politique. Ici, nous utilisons directement la DefaultPooledObjectPolicy incluse pour la construire.
Le pool d’objets aura un nombre maximal de threads maintenu.
Utilisez la méthode Get de l’objet pool pour retirer un objet du pool d’objets.
Le code ci-dessus exécute le résultat
#1-464d2e03-604d-4451-b68a-8a3a2abdfccc-itsvse.com-01/0001 00:00
#2-70122aa0-a949-4c63-b878-321efe64c234-itsvse.com-01/0001 00:00:00
#3-de717815-796a-4349-a571-047acc125104-itsvse.com-01/1/0001 00:00
#4-3a404341-a560-47f7-a3b0-0d477a8ae17f-itsvse.com-01/1/0001 00:00
#5-51c96126-d424-4b58-b07c-6408e6c4cea6-itsvse.com-1/1/0001 00:00 AM
#6-7ea4d596-fd2a-43b3-959a-9e48da58a758-itsvse.com-01/0001 00:00
#7-6874c64b-532d-4f92-a4fb-ff472da574a1-itsvse.com-01/1/0001 00:00 AM
#8-ca767674-2c07-4f26-975f-4711a31d795d-itsvse.com-01/0001 00:00:00
#9-a9cd1859-a919-46a0-ae5d-85b6d3d11ccb-itsvse.com-1/1/0001 00:00
#10-fe89ed8b-4dfd-4eef-b876-b2a60ee50958-itsvse.com-01/01/0001 00:00
Parce que DefaultPooledObjectPolicy est un nouvel objet directement, souvent, ce n’est pas ce à quoi nous nous attendons !
Si vous souhaitez répondre à notre usage réel, vous devez définir vous-même une politique !
Jetons un œil à l’utilisation 2
Utilisation 2
La méthode Create est utilisée pour créer l’objet Demo, et la méthode Return consiste à renvoyer l’objet Demo dans le pool d’objets (emprunté puis retourné).
Le pool d’objets est défini ici pour ne contenir qu’un seul objet.
Puisqu’il y a une opération de retour en une étape après l’avoir retiré du pool d’objets, l’item1 et l’item2 doivent être le même objet.
Après avoir retiré l’item2 du pool d’objets, il n’est pas retourné, donc le pool d’objets créera un nouvel objet selon la politique que nous avons définie.
Voici le résultat de sortie de l’utilisation 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
15/04/8912424a-15c5-4891-b625-25b17eee5c8b-itsvse.com 2020 03:31:15
False
Utilisation 3
Vous pouvez voir que l’item1 et l’item2 sont le même objet. En récupérant un objet dans le pool d’objets, le premier sera pris, donc si vous le retournez et le récupérez à nouveau, vous récupérerez toujours l’original en premier.
l’item3 est pris directement du Pool d’objets là-bas et n’est pas recréé, car le Pool d’objets ici maintient plusieurs objets, pas un seul en usage 2, donc il est pris directement du Pool.
Voici le résultat de sortie
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-4/15/2020 3:33:58
False
Utilisation 4
Il semble que l’utilisation ci-dessus ne soit pas si similaire à notre usage habituel. Nous devons toujours compter sur l’injection.
Voyons donc enfin comment combiner l’injection de dépendance. Bien sûr, l’essence ici reste indissociable des deux choses que sont la police et le prestataire.
Nous devons d’abord enregistrer le Fournisseur, puis prendre directement son instance pour créer un Object Pool.
Si vous voulez l’utiliser ailleurs, vous pouvez l’injecter via le constructeur.
Le résultat ici est aussi le même qu’avant, il n’y a pas grand-chose à dire.
résumé
Mais quel que soit le type d’utilisation, il faut comprendre qu’Object Pool est indissociable des trois personnes : Pool, Policy et Provider.
Avec ces trois-là, peut-être qu’on peut faire ce qu’on veut.
Bien sûr, il propose aussi plusieurs choses spéciales que vous pouvez découvrir si cela vous intéresse.
LeakTrackingObjectPool
StringBuilderPooledObjectPolicy
|
Publié le 15-04-2020 à 17:38:34
|
|
|
|
Propriétaire|
Publié le 30-08-2023 à 18:34:07
|
