Scénarios d’utilisation abusive courants : afin d’éviter le paiement en double des commandes causé par des utilisateurs cliquant accidentellement plusieurs fois sur le bouton de paiement, nous utilisons le verrou (numéro de commande) pour garantir qu’un seul fil de discussion soit autorisé à effectuer l’opération sur la commande.
Cette idée est bonne, du moins meilleure que le verrouillage (un objet statique privé pour traiter les classes), car l’effet du numéro d’ordre de verrouillage est de verrouiller uniquement l’opération de l’ordre 1 actuel, et si la variable statique verrouille, c’est-à-dire verrouiller tous les ordres, fera que tous les ordres seront mis en file d’attente, ce qui est évidemment déraisonnable.
Alors, la méthode du numéro de commande (serrure) mentionnée au début de cet article peut-elle atteindre l’effet souhaité ? Utilisons d’abord un peu de code pour restaurer le scénario d’utilisation.
Si vous ignorez les informations utilisateur et autres validations, le code ressemble à ceci :
Pour le mot-clé de la serrure, MSDN inclut des informations que l’on peut trouver sur Baidu, et il semble qu’il soit recommandé de ne pas utiliser la serrure (string), la raison étant la même. Le passage suivant est tiré des conseils de MSDN sur les cordons de serrure :
Le problème de lock(« myLock ») survient parce que tout autre code utilisant la même chaîne dans le processus partagera le même verrou. Cette phrase cache un énorme mécanisme, c’est-à-dire « la même chaîne ».
Qu’est-ce que « la même chaîne » ? Voir le code :
Est-ce que str1 et str2 sont la même corde ci-dessus ? La réponse est OUI.
Voir encore :
Est-ce que la section 1 et la tension 2 au-dessus sont toujours la même corde ? La réponse est NON.
D’accord, revenons à la question du paiement de notre commande. Dans notre code, lock(orderNumber), lorsque l’utilisateur clique accidentellement quelques fois de plus après avoir glissé sa main, est-ce que le numéro d’ordre qui entre cette action correspond à chaque fois ? La réponse est NON. C’est-à-dire
Le code qui gère l’ordre ci-dessus n’agit pas réellement comme un verrou.
En fait, il existe deux types de comparaisons de chaînes, voir le code :
La première ligne du code ci-dessus donne Vrai, et la deuxième ligne donne Faux. Je pense que vous comprenez ce que MSDN entend par « la même chaîne » sans que je m’explique ça.
La meilleure solution
Solutions pour des cordages de verrouillage optimaux :
Code de démo :
Sur le site web, parfois une variable globale peut être utilisée, cette variable globale, lorsque plusieurs utilisateurs accèdent simultanément, peut sembler anormale, à ce stade, nous allons définir un verrou global, mais l’inconvénient est que tous les accès attendent à tour de rôle.
Dans certains scénarios, par exemple, le même utilisateur ne peut commenter qu’une seule fois en 15 secondes ; si le verrou global est utilisé, la fonction de commentaire sera très lente à traiter lorsque le nombre d’utilisateurs augmente, ce qui affectera grandement l’expérience utilisateur.
À ce moment-là,Nous pouvons définir le verrou pour chaque utilisateur individuellement, lock(string){...}, et le nom du verrou peut être défini comme suit :Nom de la méthode + ID utilisateurAinsi, chaque utilisateur dispose d’un verrou indépendant, et lors de l’évaluation de l’intervalle des commentaires, cela n’affectera pas les commentaires des autres utilisateurs.
(Fin)
|