Comment le modèle de conception Singleton est-il implémenté en Visual Basic, que faut-il prendre en compte pour la sécurité des threads et quelle est la différence entre la variante classique et la variante paresseuse (lazy) ?

Réponse.

Le modèle Singleton garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès global à celle-ci. En VB.NET, on utilise souvent un constructeur privé et une propriété statique pour stocker l'unique instance :

Public Class Singleton
    Private Shared _instance As Singleton
    Private Sub New()
        ' Constructeur privé
    End Sub
    Public Shared ReadOnly Property Instance() As Singleton
        Get
            If _instance Is Nothing Then
                _instance = New Singleton()
            End If
            Return _instance
        End Get
    End Property
End Class

Sécurité des threads : Dans un environnement multi-threadé, il est possible que deux instances soient créées lors d'appels simultanés. Solution : utiliser un verrou ou la construction Lazy(Of T) :

' Implémentation paresseuse et sécurisée par les threads
Public Class Singleton
    Private Shared ReadOnly _instance As New Lazy(Of Singleton)(Function() New Singleton())
    Private Sub New()
    End Sub
    Public Shared ReadOnly Property Instance() As Singleton
        Get
            Return _instance.Value
        End Get
    End Property
End Class

Différence :

• Le Singleton classique crée une instance lors du premier accès, mais nécessite une synchronisation manuelle.
• La variante "paresseuse" utilise les mécanismes intégrés de .NET pour créer l'instance de manière sécurisée pour les threads.

Question piège.

Quel est le danger d'un tel code pour implémenter Singleton ?

Public Shared ReadOnly Property Instance() As Singleton
    Get
        If _instance Is Nothing Then
            _instance = New Singleton()
        End If
        Return _instance
    End Get
End Property

Réponse : Dans un environnement multi-threadé, il peut y avoir une situation où deux threads voient simultanément que _instance est Nothing, et les deux créent un objet. Par conséquent, cette approche n'est pas entièrement sécurisée pour les threads. Il est recommandé d'utiliser Lazy(Of T) ou SyncLock pour le verrouillage.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.

---

Histoire

Système ERP : Le logger Singleton, lorsqu'il était lancé depuis des services, était parfois créé deux fois, et les logs étaient perdus. La raison - absence de synchronisation dans la propriété, bien que l'application soit multi-threadée.

---

Histoire

Application Windows Forms : Dans le projet, le travail avec la base de données a été transféré dans un Singleton, mais la création paresseuse n'a pas été implémentée. Au démarrage de l'application, une connexion lourde se produisait, ralentissant le chargement de l'UI pour tout le monde.

---

Histoire

Plugin pour la plateforme journalistique : Ils ont tenté d'utiliser une variable statique dans un module pour le Singleton, non protégée contre l'accès multi-threadé, résultant en plusieurs instances du gestionnaire d'e-mails pendant les charges de travail élevées, ce qui a entraîné des e-mails en double.