Événements
Relevez le défi Microsoft Learn
19 nov., 23 h - 10 janv., 23 h
Ignite Edition - Créez des compétences dans Microsoft Azure et gagnez un badge numérique d’ici le 10 janvier !
S’inscrire maintenantCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Cet article vous aide à comprendre les problèmes de sécurité des threads lors de l’utilisation du SDK Azure. Il décrit également l’impact de la conception du SDK sur la gestion de la durée de vie des clients. Vous allez découvrir pourquoi il n’est pas nécessaire de supprimer les objets clients du SDK Azure.
Tous les objets clients du SDK Azure sont thread-safe et indépendants les uns des autres. Cette conception garantit que la réutilisation des instances clientes est toujours sécurisée, même entre threads. Par exemple, le code suivant lance plusieurs tâches, mais est thread-safe :
var client = new SecretClient(
new Uri("<secrets_endpoint>"), new DefaultAzureCredential());
foreach (var secretName in secretNames)
{
// Using clients from parallel threads
Task.Run(() => Console.WriteLine(client.GetSecret(secretName).Value));
}
Les objets de modèle utilisés par les clients SDK, qu’il s’agisse de modèles d’entrée ou de sortie, ne sont pas thread-safe par défaut. La plupart des cas d’usage impliquant des objets de modèle n’utilisent qu’un seul thread. Par conséquent, le coût d’implémentation de la synchronisation en tant que comportement par défaut est trop élevé pour ces objets. Le code suivant illustre un bogue dans lequel l’accès à un modèle à partir de plusieurs threads peut entraîner un comportement non défini :
KeyVaultSecret newSecret = client.SetSecret("secret", "value");
foreach (var tag in tags)
{
// Don't use model type from parallel threads
Task.Run(() => newSecret.Properties.Tags[tag] = CalculateTagValue(tag));
}
client.UpdateSecretProperties(newSecret.Properties);
Pour accéder au modèle à partir de différents threads, vous devez implémenter votre propre code de synchronisation. Par exemple :
KeyVaultSecret newSecret = client.SetSecret("secret", "value");
// Code omitted for brevity
foreach (var tag in tags)
{
Task.Run(() =>
{
lock (newSecret)
{
newSecret.Properties.Tags[tag] = CalculateTagValue(tag);
}
);
}
client.UpdateSecretProperties(newSecret.Properties);
Étant donné que les clients du SDK Azure sont thread-safe, il n’y a aucune raison de construire plusieurs objets clients de SDK pour un ensemble donné de paramètres de constructeur. Traitez les objets de client SDK Azure comme des singletons une fois construits. Cette recommandation est généralement implémentée en inscrivant des objets clients du SDK Azure en tant que singletons dans le conteneur Inversion of Control (IoC) de l’application. L’injection de dépendances (DI) est utilisée pour obtenir des références à l’objet de client SDK. L’exemple suivant montre une inscription d’objet client singleton :
var builder = Host.CreateApplicationBuilder(args);
var endpoint = builder.Configuration["SecretsEndpoint"];
var blobServiceClient = new BlobServiceClient(
new Uri(endpoint), new DefaultAzureCredential());
builder.Services.AddSingleton(blobServiceClient);
Pour plus d’informations sur l’implémentation de l’injection de dépendances à l’aide du kit SDK Azure, consultez Injection de dépendances avec le kit SDK Azure pour .NET.
Vous pouvez également créer une instance de client SDK et la fournir aux méthodes qui nécessitent un client. Le but est d’éviter les instanciations inutiles du même objet de client SDK avec les mêmes paramètres. C’est à la fois inutile et coûteux.
Les deux dernières questions qui reviennent souvent sont les suivantes :
En interne, tous les clients du SDK Azure utilisent une seule instance HttpClient
partagée. Les clients ne créent pas d’autres ressources qui doivent être libérées activement. L’instance partagée HttpClient
persiste pendant toute la durée de vie de l’application.
// Both clients reuse the shared HttpClient and don't need to be disposed
var blobClient = new BlobClient(new Uri(sasUri));
var blobClient2 = new BlobClient(new Uri(sasUri2));
Il est possible de fournir une instance personnalisée de HttpClient
à un objet client du SDK Azure. Dans ce cas, vous devenez responsable de la gestion de la durée de vie de HttpClient
et de sa suppression au moment adéquat.
var httpClient = new HttpClient();
var clientOptions = new BlobClientOptions()
{
Transport = new HttpClientTransport(httpClient)
};
// Both clients would use the HttpClient instance provided in clientOptions
var blobClient = new BlobClient(new Uri(sasUri), clientOptions);
var blobClient2 = new BlobClient(new Uri(sasUri2), clientOptions);
// Code omitted for brevity
// You're responsible for properly disposing httpClient some time later
httpClient.Dispose();
Vous trouverez des conseils supplémentaires sur la gestion et la suppression correctes des instances de HttpClient
dans la documentation HttpClient.
Commentaires sur .NET
.NET est un projet open source. Sélectionnez un lien pour fournir des commentaires :
Événements
Relevez le défi Microsoft Learn
19 nov., 23 h - 10 janv., 23 h
Ignite Edition - Créez des compétences dans Microsoft Azure et gagnez un badge numérique d’ici le 10 janvier !
S’inscrire maintenant