Αποφυγή κοινών λαθών Όταν η εφαρμογή μοτίβο Singleton σε πολυ-διαβασμένες εφαρμογές μηχανικής

Εισαγωγή: Το μοτίβο Singleton σε πολυ-διαβασμένες εφαρμογές μηχανικής

Το μοτίβο Singleton είναι ένα από τα πιο ευρέως χρησιμοποιούμενα πρότυπα δημιουργίας σχεδιασμού στη μηχανική λογισμικού. Εξασφαλίζει ότι μια τάξη έχει μόνο ένα παράδειγμα και παρέχει ένα παγκόσμιο σημείο πρόσβασης σε αυτή την περίπτωση. Σε εφαρμογές με μονόπτυχο, η εφαρμογή ενός μονόπτυχου είναι απλή: να κάνει τον κατασκευαστή ιδιωτικό, να παρέχει μια στατική μέθοδο που επιστρέφει ένα μόνο περιστατικό που δημιουργήθηκε με ανυπομονησία ή τεμπελιά. Ωστόσο, σε πολυπλεγμένες εφαρμογές μηχανικής -όπως ενσωματωμένα συστήματα, πλατφόρμες συναλλαγών υψηλής συχνότητας, συστήματα ελέγχου σε πραγματικό χρόνο, και κατανεμημένες βάσεις δεδομένων ⁇ το πρόβλημα γίνεται σημαντικά πιο περίπλοκο. Ασφάλεια νήματος, προβολή μνήμης, και περιορισμοί απόδοσης απαιτούν προσεκτικό σχεδιασμό.

Αυτό το άρθρο εξετάζει τα πιο κοινά λάθη που κάνουν οι προγραμματιστές κατά την εφαρμογή του μοτίβου Singleton σε πολυ-διαβασμένο περιβάλλον, εξηγεί τις υποκείμενες αιτίες, και παρέχει ένα ολοκληρωμένο σύνολο βέλτιστων πρακτικών και προτύπων για να τις αποφύγει. Περιλαμβάνει επίσης πρακτικά παραδείγματα κώδικα στην Java, με αναφορές σε ισοδύναμα πρότυπα σε C++ και C#, και συνιστά εξωτερικούς πόρους για περαιτέρω ανάγνωση.

Συχνές Λάθη στην εφαρμογή Singleton

Ακόμα και έμπειροι προγραμματιστές μπορούν να πέσουν σε παγίδες κατά την εφαρμογή singletons σε ταυτόχρονα συστήματα. Παρακάτω είναι τα πιο συχνά λάθη, ο καθένας με μια εξήγηση του γιατί είναι επικίνδυνοι.

1. Δεν κάνει τον Κατασκευαστή Ιδιωτικό

Αν ο κατασκευαστής είναι προσβάσιμος (δημόσιος, προστατευμένος ή ιδιωτικός), οποιοδήποτε νήμα μπορεί να δημιουργήσει μια νέα περίπτωση, σπάζοντας τη σύμβαση του singleton. Σε πολυ-αναγνωσμένο κώδικα, αυτό μπορεί να συμβεί ακούσια όταν μια τάξη επαναπροσδιορίζεται και η ορατότητα του κατασκευαστή αλλάζει τυχαία, ή όταν η τάξη υποτάσσεται (αν και η υποταξινόμηση ενός singleton είναι γενικά αποθαρρυνόμενη). Πάντα δηλώστε τον κατασκευαστή ιδιωτικό, και αν πρέπει να υποστηρίξετε υποτάγματα (σπάνια), χρησιμοποιήστε έναν προστατευόμενο κατασκευαστή με εξαιρετική προσοχή και τεκμηριώστε την αναμενόμενη συμπεριφορά.

2. Αποτυχία χειρισμού της ασφάλειας νημάτων

Σε ένα μονότονο περιβάλλον, μια απλή τεμπέλικη αρχικοποίηση λειτουργεί μια χαρά:

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

Αλλά σε μια πολυ-διαβαζόμενη εφαρμογή, δύο ή περισσότερα νήματα μπορούν ταυτόχρονα να εισέλθουν στον [[LFT:1] έλεγχο πριν από οποιοδήποτε νήμα έχει δημιουργήσει την περίπτωση. Κάθε νήμα στη συνέχεια προχωρά στη δημιουργία του αντικειμένου [[LFT:2], παραβιάζοντας το μοτίβο. Αυτή είναι μια κλασική [[LFT:0]] κατάσταση αγώνα[[LFT:1]] που οδηγεί σε πολλαπλές περιπτώσεις και μπορεί να οδηγήσει σε ασυνεπείς καταστάσεις ή διαρροές πόρων.

3. Χρησιμοποιώντας τεμπέλη αρχικοποίηση χωρίς κατάλληλη συγχρονισμό

Ακόμα και οι προγραμματιστές που αναγνωρίζουν την ανάγκη για ασφάλεια νημάτων συχνά προσθέτουν τον συγχρονισμό αφελώς. Για παράδειγμα, ο συγχρονισμός ολόκληρης της μεθόδου [[LFT:3] λειτουργεί αλλά εισάγει ένα εμπόδιο απόδοσης:

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

Κάθε κλήση προς αποκτά και απελευθερώνει την κλειδαριά, ακόμη και μετά την εμφάνιση της υπόθεσης. Σε σενάρια υψηλής συγκέντρωσης, αυτό το γενικό πλαίσιο μπορεί να υποβαθμίσει σοβαρά την απόδοση. Η καλύτερη προσέγγιση είναι να χρησιμοποιήσετε ] διπλό έλεγχο κλειδώματος (αναφέρεται παρακάτω), αλλά ακόμα και αυτό το μοτίβο έχει παγίδες αν δεν εφαρμοστεί σωστά.

4. Υπερβολή συγχρονισμού

Ο συγχρονισμός έρχεται σε πολλές μορφές: μέθοδοι, μπλοκ, , , και ούτω καθεξής. Υπερσυγχρονισμός ⁇ εφαρμόζοντας χοντροκοκκαλωτές κλειδαριές όταν είναι διαθέσιμος λεπτοκοκκαλωμένος έλεγχος ⁇ οδηγεί σε περιττές διαμάχες. Σε ορισμένες εφαρμογές μηχανικής (π.χ., συστήματα σε πραγματικό χρόνο με αυστηρά προϋπολογισμούς λανθάνουσας ισχύος), ακόμη και μερικές εκατοντάδες νανοδευτερόλεπτα του κλείδωμα πάνω από τα ύψη μπορεί να είναι απαράδεκτος. Ο στόχος είναι να ελαχιστοποιηθεί το κρίσιμο τμήμα, ενώ εξακολουθεί να εξασφαλίζει την ασφάλεια των νημάτων.

5. Αγνοώντας το πτητικό Λέξη κλειδί

Σε γλώσσες όπως η Java, η C#, και η C++ (με ]), η βολάτιλη[[LFT:1]] λέξη-κλειδί (ή ισοδύναμη) είναι απαραίτητη για την ορθή ορατότητα σε πολυ-διαβασμένο κώδικα. Χωρίς αυτό, ο μεταγλωττιστής ή η CPU μπορεί να αναδιατάξει οδηγίες, και οι αλλαγές που γίνονται από ένα νήμα μπορεί να μην είναι ορατές σε ένα άλλο. Στο διπλό-ελέγχον πρότυπο κλειδώματος, μη δηλώνοντας το φαινόμενο singleton ως [[LFT:11]] μπορεί να προκαλέσει ένα νήμα για να δει ένα μερικώς κατασκευασμένο αντικείμενο, οδηγώντας σε απρόβλεπτη συμπεριφορά. Αυτό είναι ένα από τα πιο λεπτά και επικίνδυνα λάθη.

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;
 }
}

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

 private Singleton() {}

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

public class Singleton {
 private Singleton() {}

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

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

public enum Singleton {
 INSTANCE;

 // methods and fields
}

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;
}