🏤 🅰️ 🤽🏾 C # ऑब्जेक्ट पूल कार्यान्वयन 🐎 💭 🎳

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

परिचय

ऑब्जेक्ट पूल एक जेनेरिक डिज़ाइन पैटर्न है, जो इनिशियलाइज़ और रेडी-टू-यूज़ ऑब्जेक्ट्स का एक सेट है।
इसकी आवश्यकता क्यों है? संक्षेप में, किसी नई वस्तु को शुरू करते समय प्रदर्शन में सुधार करना एक बड़ा खर्च है। लेकिन यह समझना महत्वपूर्ण है कि .NET में निर्मित कचरा कलेक्टर प्रकाश अल्पकालिक वस्तुओं के विनाश का सामना करता है, इसलिए पूल की प्रयोज्यता निम्न मानदंडों द्वारा सीमित है:

ऐसी वस्तुएँ जो बनाने और / या नष्ट करने के लिए महंगी हैं (उदाहरण: सॉकेट, प्रवाह, अप्रबंधित संसाधन);
पुन: उपयोग के लिए वस्तुओं को साफ करना एक नया निर्माण करने की तुलना में सस्ता है (या इसकी लागत कुछ भी नहीं है);
बहुत बड़ी वस्तुओं।

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

var obj = pool.Take(); //    .        obj.DoSomething(); pool.Release(obj); //  ("")   ,

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

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

इन समस्याओं को ध्यान में रखते हुए, एक नए वर्ग की आवश्यकताओं को संकलित किया गया:

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

उपयोग के मुद्दों को हल करना

कुछ कार्यान्वयन में, ऑब्जेक्ट पूल का समर्थन करने के लिए, ऑब्जेक्ट को IPoolable इंटरफ़ेस या समान लागू करना चाहिए, लेकिन मेरा कार्य यह सुनिश्चित करना था कि पूल किसी भी वर्ग के साथ काम करता है, भले ही वे विरासत के लिए बंद हों। ऐसा करने के लिए, PoolSlot जेनेरिक शेल बनाया गया था, जिसके अंदर ऑब्जेक्ट स्वयं और पूल के लिए एक लिंक होता है। पूल ही इन स्लॉट्स को संचय करने के लिए एक सारगर्भित सामान्य वर्ग है, जिसमें एक नई वस्तु बनाने और पुराने को साफ करने के दो असत्य तरीके हैं।

 public abstract class Pool<T> { public PoolSlot<T> TakeSlot() {...} //  "  " public void Release(PoolSlot<T> slot) {...} //  "  " /* ... */ //   : protected abstract T ObjectConstructor(); //   ,    protected virtual void CleanUp(T item) {} //   ,   }

सॉकेटसेंसेटइवेंटआर्ग्स क्लास उदाहरण का उपयोग करना

पूल परिभाषा

 public class SocketClientPool : Pool<SocketAsyncEventArgs> { private readonly int _bufferSize; public SocketClientPool(int bufferSize, int initialCount, int maxCapacity) : base(maxCapacity) { if (initialCount > maxCapacity) throw new IndexOutOfRangeException(); _bufferSize = bufferSize; TryAllocatePush(initialCount); //      protected-;           } protected override SocketAsyncEventArgs ObjectConstructor() { var args = new SocketAsyncEventArgs(); args.SetBuffer(new byte[_bufferSize], 0, _bufferSize); return args; } protected override void CleanUp(SocketAsyncEventArgs @object) { Array.Clear(@object.Buffer, 0, _bufferSize); } }

कोड में उपयोग करें:

 var pool = new SocketClientPool(1024, 5, 10); //   ,  /* ...-  ... */ var slot = pool.TakeSlot(); //     var args = slot.Object; //    -  pool.Release(slot); //

या इस तरह भी:

 using(var slot = pool.TakeSlot()) //  PoolSlot  IDisposable { var args = slot.Object; }

जो लोग एसिंक्रोनस .NET मॉडल और / या एक ही सॉकेट क्लास के एसिंक्रोनस तरीकों से परिचित हैं, वे जानते हैं कि इस तरह के कार्यान्वयन का उपयोग करना मुश्किल है, क्योंकि सॉकेट.एक्सएक्सएएनएक्सएक्स विधियां बिल्कुल सॉकेटसेक्स्टइन्वायरवेंट्स स्वीकार करती हैं, न कि कुछ पूलसाल्ट <सॉकेटएस्क्यूइवेंटएवार्ग्स> । एक विधि को कॉल करने के लिए यह कोई फर्क नहीं पड़ता, लेकिन हम अंत हैंडलर में स्लॉट कहां प्राप्त कर सकते हैं?
ऑब्जेक्ट बनाते समय SocketAsyncEventArgs.UserToken प्रॉपर्टी में स्लॉट को सेव करना एक विकल्प है, इसके लिए होल्डस्लॉटइनऑब्जेक्ट को ओवरराइड करने के लिए पूल में एक विधि है।

हमारे उदाहरण के लिए ओवरराइड करें

 protected override void HoldSlotInObject(SocketAsyncEventArgs @object, PoolSlot<SocketAsyncEventArgs> slot) { @object.UserToken = slot; } /* ...-  ... */ pool.Release(args.UserToken as PoolSlot<SocketAsyncEventArgs>);

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

बेहतर पूल के सरलीकृत कार्यान्वयन (IPoolSlotHolder को लागू करने वाली वस्तुओं के लिए)

 public abstract class PoolEx<T> : Pool<T> where T : IPoolSlotHolder { public T TakeObject() { ... } public void Release(T @object) { ... } protected sealed void HoldSlotInObject(T @object, PoolSlot<T> slot) { ... } //      }

अगला, मैं आंतरिक "रसोई" के विकास से परिचित होने का प्रस्ताव करता हूं।

कोष

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

बहु सूत्रण

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

सरल संचालन का कार्यान्वयन

 private void Push(PoolSlot<T> item) { _registry[token.Id] = true; // :  " " _storage.Push(item); //     Interlocked.Increment(ref _currentCount); } private bool TryPop(out PoolSlot<T> item) { if (_storage.TryPop(out item)) //      { Interlocked.Decrement(ref _currentCount); _registry[token.Id] = false; // :  "  " return true; } item = default(PoolSlot<T>); return false; }

मौजूदा वस्तुओं के इनपुट-आउटपुट के अलावा, निर्दिष्ट ऊपरी सीमा तक नए लोगों को सिंक्रनाइज़ और आवंटित करना आवश्यक है।
यहां हम पूल (ऊपरी सीमा) में तत्वों की अधिकतम संख्या के साथ प्रारंभिक रूप से एक सेमीफोर लागू करते हैं और हर बार एक नई वस्तु के निर्माण से घटाते हैं, लेकिन समस्या यह है कि जब यह शून्य तक पहुंचता है तो यह प्रवाह को अवरुद्ध करता है। इस स्थिति से बाहर निकलने के लिए सेमाफोरस्लीम.विट (0) विधि को कॉल किया जा सकता है, जो कि सेमीफोर के मौजूदा मूल्य "0" के साथ, बिना किसी देरी के झूठे तरीके से लौटता है, लेकिन इस कार्यक्षमता का एक हल्का एनालॉग लिखने का फैसला किया गया था। यह है कि LockFreeSemaphore वर्ग दिखाई दिया, जो, जब यह बिना देरी के शून्य तक पहुंचता है, तो झूठे वापस आ जाता है। आंतरिक सिंक्रोनाइज़ेशन के लिए, यह तेज CAS संचालन Interlocked.CompareExchange का उपयोग करता है।

एक सेमाफोर में कैस ऑपरेशन का उपयोग करने का एक उदाहरण

 public bool TryTake() //  true,     ,  false (   ) { int oldValue, newValue; do { oldValue = _currentCount; //    newValue = oldValue - 1; //    if (newValue < 0) return false; //     0 -  false   } while (Interlocked.CompareExchange(ref _currentCount, newValue, oldValue) != oldValue); //        ,         return true; }

इस प्रकार, पूल ऑपरेशन "एक वस्तु ले" निम्नलिखित एल्गोरिदम के अनुसार काम करता है:

हम स्टोरेज से ऑब्जेक्ट लेने की कोशिश कर रहे हैं, अगर वहाँ नहीं है - बिंदु 2।
हम एक नई वस्तु बनाने की कोशिश कर रहे हैं यदि अर्ध-शून्य (ऊपरी सीमा तक पहुंच गया है) - बिंदु 3।
सबसे खराब स्थिति यह है कि हम उम्मीद करते हैं कि वस्तु विजयी अंत तक लौट आएगी।

पहले परिणाम, अनुकूलन और रीफैक्टरिंग

क्या आपको वास्तव में ऑब्जेक्ट पूल की आवश्यकता है? यह स्थिति पर निर्भर करता है। यहां एक "विशिष्ट सर्वर ऑब्जेक्ट" का उपयोग करके थोड़े परीक्षण के परिणाम हैं, 1024 बाइट्स के बफ़र के साथ सॉकेट्ससंक्यूइनएवेंटएगर (सेकंड में समय, पूलिंग सक्षम):

एक नई संपत्ति के लिए अनुरोध	एकल धागा, कोई पूल नहीं	एकल धागा, पूल के साथ	25 कार्य *, बिना पूल के	एक पूल के साथ 25 कार्य *
1000	0.002	0.003	0.027	0.009
10000	0.010	0.001	0.272	0.039
25000	0.030	0.003	0.609	0.189
50000	0.048	0.006	1.285	0.287
1000000	0.959	0.125	27,965	8345

* कार्य - class System.Threading.Tasks.Task TPL लाइब्रेरी से, .NET 4.0 से शुरू
पूल के साथ बहु-थ्रेडेड परीक्षण पर प्रोफाइलर VS2012 के पारित होने के परिणाम:

जैसा कि आप देख सकते हैं, सब कुछ ConcurrentStack.TryPop पद्धति पर निर्भर करता है, जो (हम मानते हैं) में तेजी नहीं है। दूसरे स्थान पर "रजिस्ट्री" के लिए अपील है, जो दोनों कार्यों में लगभग 14% का चयन करती है।
सिद्धांत रूप में, पूल के अंदर दूसरे संग्रह का समर्थन वैसे भी एक बैसाखी लगता था, इसलिए "पूल में / पूल में नहीं" पर हस्ताक्षर को स्लॉट में स्थानांतरित कर दिया गया था, और रजिस्ट्री को सुरक्षित रूप से हटा दिया गया था। परीक्षण के परिणाम के बाद परिणाम (विकास, उम्मीद के मुताबिक, 30-40%):

एक नई संपत्ति के लिए अनुरोध	एक पूल के साथ 25 कार्य
25000	0.098
1000000	5.751

मुझे लगता है कि आप यहां रुक सकते हैं।

निष्कर्ष

संक्षेप में याद रखें कि कार्य कैसे हल किए गए थे:

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

यूनिट टेस्ट और टेस्ट एप्लिकेशन के साथ सोर्स कोड: जीथब
यदि दिलचस्पी है, तो मैं अतुल्यकालिक टीसीपी और यूडीपी सॉकेट सर्वर को लागू करके लेख जारी रख सकता हूं, जिसके लिए यह पूल बस लिखा गया था।

C # ऑब्जेक्ट पूल कार्यान्वयन