सिंगलटन और स्टैटिक कंस्ट्रक्टर के बारे में

प्रारंभ में, लेखक इस लेख को इस प्रकार से बुलाना चाहता था: "एकल, स्थिर निर्माणकर्ताओं और स्थिर क्षेत्रों के आरम्भकों पर, पहले के फ़्लैटइन ध्वज पर और गतिरोध और स्थैतिक निर्माणकर्ताओं पर इसका प्रभाव। नेट ढाँचा 3.5 में रिलीज़ निर्माण सेवाएँ शुरू करने के दौरान," हालांकि। लेखक के लिए अज्ञात कारण से बहुस्तरीय नाम आधुनिक कंप्यूटर समुदाय में जड़ नहीं लेते थे, उन्होंने (लेखक ने) इस नाम को छोटा करने का फैसला किया, राक्षसी रूप से इसका मूल अर्थ विकृत कर रहे थे।

-------------------------

सिंगलटन पैटर्न के किसी भी कार्यान्वयन में आम तौर पर दो लक्ष्य होते हैं: सबसे पहले, बहु थ्रेडेड .Net दुनिया में एक से अधिक उदाहरणों के निर्माण को रोकने के लिए कार्यान्वयन को सुरक्षित होना चाहिए; और दूसरी बात, यह कार्यान्वयन "आलसी" होना चाहिए, ताकि समय से पहले या उन मामलों में एक (संभावित) महंगी वस्तु न बनाई जाए जहां इसकी आवश्यकता नहीं हो सकती है। लेकिन जब से सिंग्लटन के कार्यान्वयन के बारे में किसी भी लेख को पढ़ने में मल्टीथ्रेडिंग को मुख्य ध्यान दिया जाता है, तो "आलस्य" में अक्सर कोई इच्छा नहीं होती है।



आइए एक स्थिर क्षेत्र आरंभक के आधार पर सिंगलटन (*) पैटर्न के सबसे सरल और सबसे लोकप्रिय कार्यान्वयन में से एक को देखें:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();

// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Singleton()
{}

private Singleton()
{}

public static Singleton Instance { get { return instance; } }
}

* This source code was highlighted with Source Code Highlighter .

इस कार्यान्वयन की थ्रेड सुरक्षा इस तथ्य पर आधारित है कि एक डोमेन में एक स्थिर कंस्ट्रक्टर (या, दूसरे शब्दों में, एक प्रकार का इनिलाइज़र) को एक बार से अधिक नहीं कहा जाता है। और अगर ऐसा है, तो थ्रेड सेफ्टी को और भी सुरक्षित बनाने के लिए डेवलपर को अपने कानों से कोई फील करने की जरूरत नहीं है। अधिकांश डेवलपर्स (और हाल ही में, जब तक खुद को शामिल करते हैं) इस पर शांत हो गए हैं, क्योंकि हमने पहले से ही मुख्य समस्या का फैसला किया है जो किसी भी सिंगलटन के साथ हो सकता है, इसलिए कुछ लोग एक खाली स्थिर कंस्ट्रक्टर की टिप्पणी पर ध्यान देते हैं। और चूंकि यह टिप्पणी बिल्कुल भी समझ में नहीं आती है, एक खाली स्थिर रचनाकार बस वास्तविक अनुप्रयोगों में कई कार्यान्वयन तक नहीं पहुंचता है।

स्टेटिक कंस्ट्रक्टर और फील्ड इनिशियलाइज़र

स्टेटिक कंस्ट्रक्टर एक प्रकार को इनिशियलाइज़ करने के लिए डिज़ाइन की गई चीज़ है, जिसे किसी भी स्टैटिक या नॉन-स्टैटिक मेंबर को एक्सेस करने से पहले और क्लास का इंस्टेंस बनाने से पहले भी कॉल किया जाना चाहिए। हालाँकि, यदि C # में एक क्लास में स्टैटिक कंस्ट्रक्टर की स्पष्ट घोषणा नहीं होती है, तो कंपाइलर इसे FirstFieldInit विशेषता के साथ चिह्नित करता है, जो रनटाइम को बताता है कि टाइप को "रिलैक्स" तरीके से इनिशियलाइज़ किया जा सकता है। हालाँकि, जैसा कि अभ्यास से पता चलता है कि .net फ्रेमवर्क में संस्करण 4 तक, इस व्यवहार को "आस्थगित" नहीं बल्कि कुछ भी कहा जा सकता है।

तो आइए निम्नलिखित कोड देखें:

class Singleton
{
//static Singleton()
//{
// Console.WriteLine(".cctor");
//}

public static string S = Echo( "Field initializer" );

public static string Echo( string s)
{
Console .WriteLine(s);
return s;
}
}

class Program
{

static void Main( string [] args)
{
Console .WriteLine( "Starting Main..." );
if (args.Length == 1)
{
Console .WriteLine(Singleton.S);
}
Console .ReadLine();
}
}

* This source code was highlighted with Source Code Highlighter .

चूंकि इस मामले में सिंग्लटन वर्ग के लिए कोई स्पष्ट स्थिर कंस्ट्रक्टर नहीं है, इसलिए कंपाइलर इस प्रकार के पहलेफिल्डइंट विशेषता को जोड़ता है। विनिर्देशन के अनुसार, इस क्षेत्र में स्थैतिककरण इस क्षेत्र में पहली कॉल से पहले होगा, और यह इस कॉल से बहुत पहले हो सकता है। व्यवहार में, .Net फ्रेमवर्क 3.5 और निम्न का उपयोग करते समय, यह स्टेटिक फ़ील्ड को मुख्य विधि को कॉल करने से पहले इनिशियलाइज़ करने का कारण बनेगा, भले ही स्थिति args हो। लेग्न्थ == 1 विफल हो जाएगा। यह सब इस तथ्य की ओर जाता है कि जब हम उपरोक्त कोड चलाते हैं, तो हमें निम्नलिखित मिलते हैं:

फ़ील्ड इनिशियलाइज़र

मुख्य शुरू ...

जैसा कि आप देख सकते हैं, स्थैतिक क्षेत्र को इनिशियलाइज़ किया जाएगा, हालाँकि एप्लिकेशन में स्वयं टाइप का उपयोग नहीं किया गया है। अभ्यास से पता चलता है कि ज्यादातर मामलों में, एक स्पष्ट निर्माणकर्ता की अनुपस्थिति में, जेआईटी संकलक उस चर को कॉल करने से तुरंत पहले स्टैटिक वैरिएबल्स को कॉल करता है जिसमें यह चर प्रयोग किया जाता है । यदि आप सिंगलटन क्लास के स्टैटिक कंस्ट्रक्टर को असहज करते हैं, तो व्यवहार वही होगा जो अधिकांश डेवलपर्स उम्मीद करते हैं - फील्ड इनिशलाइज़र को नहीं बुलाया जाएगा और जब एप्लिकेशन शुरू होगा, तो स्क्रीन पर केवल एक ही लाइन होगी: " स्टार्टिंग मेन ..." ।

नोट

डेवलपर को स्थिर कंस्ट्रक्टर कहा जाता है, जबकि उसे बांधा नहीं जाना चाहिए और न ही बांधना चाहिए। यदि आप "कानून के पत्र" का पालन करते हैं, तो यह बहुत संभव है कि उपरोक्त उदाहरण में (एक स्पष्ट प्रकार के निर्माता के बिना), सिंगलटन चर । सिंग्लटन क्लास को इंस्टेंट करते समय एस को इनिशियलाइज़ नहीं किया जाएगा और जब एस फील्ड का उपयोग नहीं करने वाले स्टैटिक मेथड को इनवॉइस किया जाएगा, लेकिन एस फील्ड का उपयोग करके स्टैटिक फंक्शन को इनवाइट करते समय इसे इनिशियलाइज़ किया जाएगा। यद्यपि यह ठीक वैसा ही व्यवहार है जो मूल रूप से पहलेफ्लैटइनिट ध्वज की परिभाषा में निर्धारित किया गया था, सी # भाषा विनिर्देश विशेष रूप से बताता है कि कॉल का सही समय कार्यान्वयन द्वारा निर्धारित किया जाता है। इसलिए, उदाहरण के लिए, .Net फ्रेमवर्क 4 के तहत उपरोक्त स्रोत के टुकड़े (एक स्पष्ट स्थिर निर्माता के बिना) को शुरू करते समय, हम अधिक अपेक्षित व्यवहार प्राप्त करेंगे: एस फ़ील्ड को प्रारंभ नहीं किया जाएगा! आप लेख के अंत में दिए गए साइटलिंक में इसके बारे में अधिक पढ़ सकते हैं।

स्थैतिक निर्माता और गतिरोध

चूंकि निर्दिष्ट प्रकार के स्थिर निर्माता को एक से अधिक बार आवेदन डोमेन में नहीं कहा जाना चाहिए, सीएलआर इसे किसी प्रकार के लॉक के अंदर कहता है। फिर, यदि कोई स्टैटिक कंस्ट्रक्टर निष्पादित करने वाला एक थ्रेड पूरा होने के लिए दूसरे थ्रेड का इंतजार करता है, जो बदले में उसी आंतरिक सीएलआर लॉक को पकड़ने की कोशिश करेगा, तो हमें एक क्लासिक गतिरोध प्राप्त होता है।

आदर्श परिस्थितियों में एक समान स्थिति को पुन: पेश करना बहुत आसान है: इसके लिए, एक स्थिर निर्माण में, यह एक नया धागा बनाने के लिए पर्याप्त है और इसके निष्पादन के लिए इंतजार करने की कोशिश करें:

class Program
{
static Program()
{
var thread = new Thread(o => { });
thread.Start();
thread.Join();
}

static void Main()
{
// ,
//
// Program
}
}

* This source code was highlighted with Source Code Highlighter .

इसके अलावा, अगर हम सीएलआई विनिर्देश की ओर मुड़ते हैं, तो यह कहता है कि स्थिर निर्माणकर्ता के अंदर अवरोधक संचालन के लिए एक स्पष्ट या अंतर्निहित कॉल के साथ गतिरोध संभव है। व्यवहार में, इसका मतलब है कि एक स्थिर निर्माणकर्ता के अंदर एक धागे को अवरुद्ध करने का प्रयास, उदाहरण के लिए, कुछ मामलों में एक नाम म्यूटेक्स के उपयोग के कारण गतिरोध हो सकता है।

एक असली आवेदन में बग

यह सभी बकवास, स्थिर निर्माणकर्ताओं में कॉलिंग इनिशियलाइज़र और गतिरोध के समय से जुड़ा हुआ है, उंगली से चूसा और वास्तविक अनुप्रयोगों में संभावना नहीं लग सकता है। सच कहूँ तो, मैं एक सप्ताह पहले एक ही राय का था, इससे पहले कि मैं पूरा दिन एक बहुत अप्रिय बग डिबगिंग में बिताऊं।

तो, यहां एक वास्तविक समस्या के लक्षण हैं जो मैं सामना कर रहा हूं। हमारे पास एक सेवा है जो कंसोल मोड में बहुत बढ़िया काम करती है, और साथ ही साथ एक सेवा के रूप में भी काम करती है यदि आप इसे डीबग में एक साथ रखते हैं। हालांकि, यदि आप इसे रिलीज़ में एकत्र करते हैं, तो यह एक बार शुरू होता है: यह एक बार सफलतापूर्वक शुरू होता है, और दूसरी बार लॉन्च टाइमआउट द्वारा क्रैश हो जाता है (यदि डिफ़ॉल्ट रूप से सेवा 30 सेकंड में शुरू नहीं होती है, तो एससीएम प्रक्रिया को मारता है)।

डिबगिंग के परिणामस्वरूप, निम्नलिखित पाया गया था। (1) हमारे पास निर्माणकर्ता में एक सेवा वर्ग है जिसमें प्रदर्शन काउंटर बनाए गए हैं; (2) सेवा वर्ग एक स्थिर स्थिर निर्माता के बिना एक स्थिर क्षेत्र को आरम्भ करके एक सिंगलटन के रूप में कार्यान्वित किया जाता है, और (3) इस सिंगलटन का उपयोग सीधे कंसोल मोड में सेवा शुरू करने के लिए मुख्य विधि में किया गया था:

//
partial class Service : ServiceBase
{
// "" .
public static readonly Service instance = new Service();
public static Service Instance { get { return instance; } }

public Service()
{
InitializeComponent();

//
var counters = new CounterCreationDataCollection();

if (PerformanceCounterCategory.Exists(category))
PerformanceCounterCategory.Delete(category);

PerformanceCounterCategory.Create(category, description,
PerformanceCounterCategoryType.SingleInstance, counters);
}

//
public void Start()
{}

const string category = "Category" ;
const string description = "Category description" ;
}
// Program
static void Main( string [] args)
{
if (args[0] == "--console" )
Service.Instance.Start();
else
ServiceBase.Run( new Service());

}

* This source code was highlighted with Source Code Highlighter .

चूंकि सर्वर वर्ग में एक स्पष्ट स्टैटिक कंस्ट्रक्टर नहीं होता है और C # कंपाइलर पहले के फ़्लैट को जोड़ता है, मेन क्लास के आने से पहले सर्विस क्लास के कंस्ट्रक्टर को कॉल किया जाता है। उसी समय, एक नामित म्यूटेक्स का उपयोग प्रदर्शन काउंटर की एक श्रेणी बनाने के लिए किया जाता है, जो कुछ शर्तों के तहत आवेदन गतिरोध की ओर जाता है: पहले रन के दौरान, निर्दिष्ट श्रेणी अभी तक सिस्टम में नहीं है, इसलिए एक्ज़िस्ट विधि गलत हो जाती है और क्रिएट सफल हो जाती है; अगले रन के दौरान, एक्सिस्ट विधि सही हो जाती है , डिलीट विधि सफल हो जाती है, लेकिन क्रिएट विधि हमेशा के लिए हैंग हो जाती है। यह स्पष्ट है कि समस्या पाए जाने के बाद, समाधान में ठीक 13 सेकंड लगे: सेवा वर्ग में एक स्थिर निर्माता जोड़ें।

निष्कर्ष

एक वास्तविक एप्लिकेशन में बग के साथ एक उदाहरण बताता है कि C # भाषा के नुकसान और अच्छी तरह से ज्ञात पैटर्न और मुहावरों के उचित उपयोग के बारे में लेख बकवास और सिद्धांतकारों (**) के काल्पनिक नहीं हैं, ऐसे कई लेख वास्तविक दुनिया में भरपाई पर आधारित हैं। आज आप सिंगलटन कार्यान्वयन वक्र के साथ समस्याओं का सामना कर सकते हैं, कल - परिवर्तनशील महत्वपूर्ण प्रकारों के अतुलनीय व्यवहार के साथ, जिस दिन के बाद आप थ्रेड के साथ थ्रेड को हरा देते हैं। सिस्टम को बेमेल करें (***)। ये सभी समस्याएं बहुत वास्तविक हैं और उनकी नींव में रखे गए सिद्धांतों की समझ किसी विशेष बुराई बग की तलाश में एक और दिन बचा सकती है।

संबंधित लिंक

• बार्ट डे स्मेट। स्टेटिक कंस्ट्रक्टर और टाइप इनिशियलाइज़ेशन
• स्थैतिक निर्माण विध्वंसक (कमाल का लेख! अनुशंसा)
• जॉन स्कीट सी # और befrefieldinit
• जॉन स्कीट C # में सिंगलटन पैटर्न को लागू करना
• जॉन स्कीट टाइप करें आरंभीकरण परिवर्तन .Net 4.0

-------------------------

(*) सिंगलटन पैटर्न के दो अन्य बहुत लोकप्रिय कार्यान्वयन हैं: (1) डबल चेक लॉकिंग, और (2) लेज़ी < टी> प्रकार का उपयोग करके, जो .Net फ्रेमवर्क 4 में दिखाई दिया।

(**) मेरे एक सहकर्मी का दृढ़ विश्वास है कि किताबें और लेख पढ़ने का कोई मतलब नहीं है, क्योंकि वे उन लोगों द्वारा लिखे गए हैं जो इस सॉफ़्टवेयर विकास में कुछ भी नहीं समझते हैं। इसलिए, उनका मानना ​​है कि केवल एक "वास्तविक" सिंगलटन कार्यान्वयन है, और यह कि आपको सभी वर्गों के लिए एक खाली फ़ाइनलीज़र जोड़ने की आवश्यकता है, जो कि आईडीसोफ़ेक्टिव इंटरफ़ेस को लागू करता है।

(***) अगर यह दिलचस्प है कि किस तरह की समस्याएं परस्पर सार्थक प्रकारों में घटती हैं, तो पिछला लेख "परस्पर सार्थक प्रकारों के खतरों पर" आपको अच्छी तरह से सूट कर सकता है, लेकिन अगर आप सोच रहे हैं कि थ्रेड को कॉल करने के बारे में इतना बुरा क्या है, तो दो भी हैं नोट: "थ्रेड.बोर्ट कॉलिंग के खतरों पर" , साथ ही क्रिस सेल द्वारा एक दिलचस्प लेख का अनुवाद "रोटर का उपयोग करके लर्निंग थ्रेडबोर्ट एक्सपटेशन " ।