Evitarea greșelilor comune atunci când se pune în aplicare modelul Singleton în aplicații de inginerie multifilate

Introducere: Modelul Singleton în aplicații de inginerie multi-Threated

Modelul Singleton este unul dintre cele mai utilizate modele de creație în inginerie software. Se asigură că o clasă are doar un singur exemplu și oferă un punct global de acces la acest exemplu. În aplicații mono-neagregate, implementarea unui singleton este simplă: face constructorul privat, oferă o metodă statică care returnează un singur caz creat cu nerăbdare sau leneș. Cu toate acestea, în aplicații de inginerie multi-achitate cum ar fi sisteme integrate, platforme de tranzacționare de înaltă frecvență, sisteme de control în timp real și sisteme de bază distribuite devine considerabil mai complex. Vizibilitatea de bază, vizibilitatea memorie și constrângerile de performanță necesită design atent. Greșelile în implementarea singleton poate duce la condiții de rasă, crearea de mai multe cazuri, blocaje subtile sau bug-uri care sunt notoriu dificil de reprodus și depan.

Acest articol examinează cele mai frecvente greșeli pe care le fac dezvoltatorii atunci când pun în aplicare modelul Singleton în medii cu mai multe fire, explică cauzele subiacente, și oferă un set cuprinzător de bune practici și modele pentru a le evita. Acesta include, de asemenea, exemple de cod practic în Java, cu trimiteri la modele echivalente în C++ și C#, și recomandă resurse externe pentru lectură ulterioară.

Greşeli comune în implementarea Singleton

Chiar și dezvoltatorii experimentați pot cădea în capcane atunci când se implementează singletoni în sisteme concurente. Mai jos sunt cele mai frecvente erori, fiecare cu o explicație a motivului pentru care acestea sunt periculoase.

1. Nu facerea constructorului privat

Fundaţia oricărui singleton este un constructor privat care previne instanţiaţiarea externă. Dacă constructorul este accesibil (public, protejat sau privat), orice fir poate crea un nou exemplu, ruperea contractului singleton. În cod multi-fire, acest lucru se poate întâmpla accidental atunci când o clasă este readusă la normal şi vizibilitatea constructorului este schimbată accidental, sau când clasa este subclasat (deşi subclasarea unui singleton este în general descurajată). Declaraţi întotdeauna constructorul privat, şi dacă trebuie să sprijiniţi subclasele (rare), utilizaţi un constructor protejat cu precauţie extremă şi documentaţi comportamentul aşteptat.

2. În caz contrar pentru a se ocupa de siguranță filet

Într-un mediu cu un singur fir, o iniţializare simplă şi leneşă funcţionează bine:

public class Singleton {
 private static Singleton instance;
 private Singleton() {}
 public static Singleton getInstance() {
 if (instance == null) {
 instance = new Singleton();
 }
 return instance;
 }
}

Dar într-o aplicație multi-fire, două sau mai multe fire pot intra concomitent verifica înainte ca orice fir să fi creat instanța. Fiecare fir apoi începe să creeze propriul obiect , violând modelul. Aceasta este o condiție clasică rasă care duce în mai multe situații și poate duce la scurgeri de stare sau de resurse inconsecvente.

3. Folosirea iniţializarea leneşă fără sincronizarea corectă

Chiar şi dezvoltatorii care recunosc nevoia de siguranţă a filetului adaugă adesea sincronizare naiv. De exemplu, sincronizarea întregii metode funcţionează, dar introduce un blocaj performanţă:

public static synchronized Singleton getInstance() { ... }

Fiecare apel la ] dobândește și eliberează încuietoarea, chiar și după ce instanța este deja creată. În scenarii de mare conținut, acest plafon poate degrada grav prin intermediul. Abordarea mai bună este de a utiliza blocare dublu-verificat] (discutat mai jos), dar chiar și acest model are capcane dacă nu este implementat corect.

4. Utilizarea supra-sincronizării

Sincronizarea vine în multe forme: metode, [ blocuri, [, , și așa mai departe. Peste-sincronizare [aplicarea încuietorilor cu granulație brută atunci când controlul fin este disponibil [conduce la o avarii inutile. În unele aplicații de inginerie (de exemplu, sisteme în timp real cu bugete stricte de latență), chiar și câteva sute nanosecunde de blocare deasupra capului poate fi inacceptabile. Scopul este de a minimiza secțiunea critică, asigurând în același timp siguranța filetului.

5. Ignorarea cuvântului cheie volatile

În limbi precum Java, C# și C++ (cu ), volatil [] cuvântul cheie (sau echivalent) este esențial pentru vizibilitatea corectă în codul multifilat. Fără el, compilatorul sau procesorul poate reordona instrucțiuni, iar modificările făcute de un fir nu pot fi vizibile pentru altul. În modelul de blocare dublu-verificat, nedeclararea cazului de singular ca poate provoca un fir pentru a vedea un obiect parțial construit, ducând la un comportament imprevizibil. Aceasta este una dintre cele mai subtile și periculoase greșeli.

Cele mai bune practici pentru implementarea Singleton filet-safe

Pentru a evita aceste capcane, urmați aceste strategii dovedite. Fiecare abordare abordează siguranța firului, performanța și simplitatea.

Constructor privat și StaticCentral

Indiferent de strategia de inițializare, constructorul trebuie să fie privat. Cauza offton ar trebui să fie stocate într-un câmp static. Nu expune constructorul în nici un fel, și să ia în considerare realizarea clasei ] în Java (sau în C#) pentru a preveni subclasarea.

Utilizați blocuri sincronizate numai atunci când este necesar

Pentru iniţializarea lene, modelul de blocare dublu-verificat reduce sincronizarea deasupra capului:

public class Singleton {
 private static volatile Singleton instance;

 private Singleton() {}

 public static Singleton getInstance() {
 Singleton result = instance; // Local variable for performance
 if (result == null) {
 synchronized (Singleton.class) {
 result = instance;
 if (result == null) {
 instance = result = new Singleton();
 }
 }
 }
 return result;
 }
}

În acest cod, cecul în afara blocului sincronizat evită blocarea deasupra capului atunci când există deja. Verificarea interioară asigură că doar un singur fir creează instanţa. Cuvântul cheie previne reordonarea instrucţiunilor şi asigură că atribuirea este pe deplin vizibilă pentru alte fire. Reţineţi că am cache instanţa într-o variabilă locală pentru performanţă. Acest model este corect în Java 5+ (cu modelul de memorie adecvat) şi funcţionează în mod similar în C# şi C++ (folosind cu ordinea memoriei).

Iniţializare rapidă

Dacă singletonul este întotdeauna necesar și crearea este ieftină, inițializarea dornică este cea mai simplă abordare de siguranță:

public class Singleton {
 private static final Singleton INSTANCE = new Singleton();

 private Singleton() {}

 public static Singleton getInstance() {
 return INSTANCE;
 }
}

Încărcătura clasei este sincronizată inerent de către JVM, deci nu este necesară o coordonare suplimentară. Totuși, aceasta creează situația la timpul de încărcare de clasă, care poate fi nedorită în sistemele de conservare a resurselor sau atunci când singletonul depinde de configurația de funcționare care nu este încă disponibilă.

Model de titular static (inițializare la cerere)

Acest model combină iniţializarea leneşă cu siguranţa filetului fără sincronizare explicită:

public class Singleton {
 private Singleton() {}

 private static class Holder {
 static final Singleton INSTANCE = new Singleton();
 }

 public static Singleton getInstance() {
 return Holder.INSTANCE;
 }
}

Clasa este încărcată doar atunci când ] este numită pentru prima dată, iar JVM garantează publicarea în condiții de siguranță a câmpului static în timpul încărcării clasei. Aceasta este considerată pe scară largă ca fiind cea mai elegantă soluție pentru Java Singtons.

Singleton (Java)

Joshua Bloch . Efficient Java recomandă utilizarea unui enum:

public enum Singleton {
 INSTANCE;

 // methods and fields
}

Constantele de enum sunt implicit , iar limbajul Java garantează că instanţele de enum sunt create doar o singură dată, chiar şi în cazul atacurilor de serie sau de reflecţie. Aceasta este atât de fire-sigure cât şi concise. Cu toate acestea, enumurile nu pot extinde clasele (doar să implementeze interfeţe), astfel încât nu sunt potrivite pentru toate cazurile de utilizare.

Modele echivalente în C++ și C#

În C++, Meyer

Singleton& getInstance() {
 static Singleton instance;
 return instance;
}

public class Singleton {
 private static readonly Lazy<Singleton> _lazy =
 new Lazy<Singleton>(() => new Singleton());

 public static Singleton Instance => _lazy.Value;
}