अक्का एंटीपेटर्न: बहुत सारे अभिनेता

एक्का द्वारा हैबे पर कुछ सामग्री हैं। मैंने मैनुएल द्वारा बताए गए कुछ एंटीपैटर्न का अपने ब्लॉग पर अनुवाद करने का फैसला किया। वे वास्तव में उन लोगों के लिए स्पष्ट नहीं हो सकते हैं जिन्होंने पहली बार रूपरेखा का सामना किया था।

यह मेरे साथ हुआ है कि मैंने इसके बारे में अभी तक बहुत बार प्रतिरूप के बारे में नहीं लिखा था। यह अक्सर डेवलपर्स के कोड में पाया जा सकता है जो अभी अभिनेता मॉडल के साथ काम करना शुरू कर रहे हैं।

कई अभिनेताओं को पाने के दो तरीके हैं:

- कई अलग-अलग प्रकार के अभिनेताओं के साथ एक प्रणाली विकसित की है, जिनमें से कई की जरूरत नहीं है
- जब यह आवश्यक और अक्षम न हो, तो रनटाइम में बहुत बड़ी संख्या में अभिनेताओं का निर्माण करना

आइए इन विकल्पों पर विस्तार से देखें।

कई तरह के अभिनेता

सामान्य विचार कुछ इस तरह है: "हमारे पास अभिनेता हैं, इसलिए सब कुछ एक अभिनेता होना चाहिए।"

अभिनेता मॉडल अतुल्यकालिक लेखन को सरल करता है। यह एक अभिनेता के अंदर सिंक्रोनस कोड निष्पादन का भ्रम प्रदान करता है - एक अभिनेता के राज्य के समवर्ती पहुंच के बारे में चिंता करने की कोई आवश्यकता नहीं है, क्योंकि केवल एक अभिनेता अपने राज्य तक पहुंच सकता है, और संदेशों को एक बार में संसाधित किया जाता है, बदले में।

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

मैं अक्सर कोड को बड़ी संख्या में विभिन्न अभिनेताओं के साथ एक-दूसरे के साथ बातचीत करते हुए और कुछ भी नहीं करते हुए देखता हूं, जिससे अतुल्यकालिक या एक साथ निष्पादन में बहुत फायदा होता है। इन परियोजनाओं में, एक ही राज्य को इनमें से प्रत्येक अभिनेता द्वारा संग्रहीत किया जाना चाहिए या प्रत्येक संदेश में उन्हें प्रेषित किया जाना चाहिए।

इस दृष्टिकोण में दो कमियां हैं:

"आपको प्रदर्शन के मामले में कुछ नहीं मिलता है।" इसके विपरीत, संदेशों के निर्माण और उनके संचरण के साथ जुड़ा हुआ ओवरहेड है।
- प्रत्येक प्रकार के अभिनेता और संबंधित संदेशों के साथ, सिस्टम को समझना और बनाए रखना अधिक कठिन हो जाता है।

इसलिए, जब अभिनेता सिस्टम डिजाइन करते हैं, तो आपको यह सोचने की ज़रूरत है कि वास्तव में अतुल्यकालिक क्या होना चाहिए, मूल रूप से यह:

- बाहरी सिस्टम (आपके jvm के बाहर) को कॉल करता है
- अवरुद्ध संचालन के लिए कॉल (पुराने एपीआई, भारी कंप्यूटिंग, ...)

बहुत से अभिनेता रनटाइम में

सामान्य विचार कुछ इस तरह है: "जितने अधिक अभिनेता हमारे पास होंगे, उतनी ही तेजी से सब कुछ हो जाएगा।"

दरअसल, अभिनेता हल्के होते हैं, और आप उनमें से लाखों को एक वर्चुअल मशीन में चला सकते हैं । हाँ आप कर सकते हैं। लेकिन क्या यह जरूरी है?


यदि आप कर सकते हैं, तो इसका मतलब यह नहीं है कि आपको चाहिए

संक्षिप्त उत्तर: हमेशा नहीं - यह इस बात पर निर्भर करता है कि आप अभिनेताओं के साथ क्या करते हैं।

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

हालाँकि, यदि आपके पास कई प्रकार के अभिनेता हैं, जो किसी चीज़ की गणना करने में शामिल हैं - उदाहरण के लिए, XML दस्तावेज़ को पार्स करना - ऐसे लाखों अभिनेताओं को बनाना संदिग्ध है (यह सीधे या राउटर के माध्यम से कोई फर्क नहीं पड़ता)।

प्रोसेसर के निपटान में कोर (हार्डवेयर थ्रेड्स) की एक निश्चित संख्या होती है, और अक्का अभिनेता एक थ्रेड पूल के आधार पर एक्सेकॉन कॉन्टेक्स्ट में संदेशों को संसाधित करते हैं। डिफ़ॉल्ट रूप से, यह कांटा-ज्वाइन-निष्पादक है जो ForkJoinPool के आधार पर जावा 7 में जोड़ा गया है।

लेकिन, इसके तकनीकी लाभ के बावजूद, फोर्कजॉइनपूल कोई जादू नहीं है जो भौतिकी के नियमों को दोहराता है। यदि आपके पास एक मिलियन अभिनेता हैं, जिनमें से प्रत्येक एक XML दस्तावेज़ (पहले से ही मेमोरी में लोड) और 4 हार्डवेयर थ्रेड्स को पार्स करता है, तो सिस्टम बहुत बेहतर काम नहीं करेगा यदि आपके पास केवल 4 अभिनेता थे जो इन XML दस्तावेजों को पार्स करते हैं (जब सजातीय लोड स्थिति)। वास्तव में, आपका सिस्टम 4 अभिनेताओं के साथ बहुत बेहतर काम करेगा क्योंकि योजना और स्मृति प्रबंधन के मामले में केवल न्यूनतम ओवरहेड होगा। वैसे, यदि आपके सिस्टम में केवल कुछ अभिनेता हैं, तो अपने थ्रेड पूल की जांच करें, जो संभवतः उसी अभिनेता के लिए उसी थ्रेड का पुन: उपयोग करने का प्रयास कर रहा है।

सामान्य तौर पर, यदि आप बहुत सारे अभिनेता बनाते हैं, तो सिस्टम तेजी से काम नहीं करेगा।

स्टेटलेस एक्टर्स

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

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

सामान्य तौर पर: यदि आपके पास राज्य नहीं है तो अभिनेताओं का उपयोग न करें - वे इसके लिए अभिप्रेत नहीं हैं।