Pourquoi «Lock (this)» est-il dangereux dans la programmation multithread?

Évitez l'utilisation de

: dangers cachés dans la programmation multi-thread lock(this) Les documents Microsoft sont clairement recommandés pour éviter l'utilisation de

à volonté et comprendre les raisons et les conséquences potentielles derrière.

lock(this) Le problème du verrouillage incontrôlé

Le cœur du problème est qu'il est impossible de contrôler les autres threads qui peuvent verrouiller le même objet. Cela peut facilement conduire à des serrures mortes.

Supposons qu'un objet est exposé publiquement, n'importe qui peut obtenir sa référence. Si l'une de ces références est utilisée pour verrouiller l'objet, le créateur de l'objet peut ne rien savoir, qui compliquera l'exécution parallèle et peut provoquer des erreurs d'accident.

Détruisez l'encapsulation et réduisez la clarté

En utilisant le principe d'emballage illégal, le mécanisme de verrouillage est exposé à l'accès public. Cela rend difficile de comprendre l'utilisation et le comportement attendus de l'objet. Au contraire, le verrouillage avec des champs privés peut fournir une séparation plus claire des points d'attention et s'assurer que le verrouillage en interne sans exposition à des détails de mise en œuvre inutiles. Danger des malentendus et de la chaîne

lock(this) Certains malentendus ont contribué par inadvertance à l'utilisation de

. Un malentendu est que l'objet de verrouillage lui-même est donc de rendre l'objet non échangeable ou d'éviter la modification. Ce n'est pas le cas. L'objet de paramètre transmis à l'instruction

est uniquement pour identifier la clé pour identifier l'objet de verrouillage. Un autre piège consiste à essayer d'utiliser une chaîne comme clé dans l'instruction

. Étant donné que la chaîne est inchangée et partagée entre les applications, cette approche peut conduire à des conflits de verrouillage inattendus. Au lieu de cela, il est préférable d'utiliser des objets privés comme touches pour mieux contrôler le mécanisme de verrouillage.

lock(this) Étude de cas: la sécurité du thread dans le traitement parallèle lock

Afin d'expliquer le problème potentiel, veuillez considérer le code C # suivant: lock

Dans la méthode principale, créez plusieurs threads et chaque thread essaie d'effectuer des opérations sur l'objet . Méthode pour essayer d'utiliser le verrouillage de l'objet de

obtenir l'objet. Cependant, les méthodes et essaient également de verrouiller l'objet directement ou indirectement, et utilisez le

comme clé. Cela entraînera des conflits de verrouillage inattendus et des verrous morts, car le code essaie d'effectuer des opérations dessus lors du verrouillage de l'objet d'un autre fil. (Il est supposé que les méthodes TimeWarp et NameChaange utilisent également le verrouillage et utilisent ce ou personne.

En bref, utilisez

<code class="language-csharp">public class Person
{
    public int Age { get; set; }
    public string Name { get; set; }

    public void LockThis()
    {
        lock (this)
        {
            System.Threading.Thread.Sleep(10000);
        }
    }
}</code>

pour détruire la sécurité des threads et créer des blocs de blocage potentiels. En utilisant des mécanismes de verrouillage des emballages de champ privés et en utilisant des objets privés comme touches dans l'instruction

, il peut fournir une méthode de synchronisation de thread plus robuste et fiable. Person

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!