फोर्क / जॉइन करने या आपको याद रखने के लिए एक जावा एप्लिकेशन को माइग्रेट करना

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

यहाँ, मैं इस बात पर विचार करना चाहूँगा कि फोर्क / जॉइन करते समय आपको क्या ध्यान देना चाहिए।

थ्रेडलोक चर

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

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

इसलिए, स्थानीय प्रवाह चर का उपयोग करने के दृष्टिकोण की समीक्षा की जानी चाहिए।
थ्रेडलॉक का उपयोग कई मामलों में किया जा सकता है:

1. किसी भी गैर-थ्रेड-सुरक्षित उपयोगिता वर्ग के भंडारण के लिए। उदाहरण के लिए, SimpleDateFormat । जिसका निर्माण बहुत महंगा है, और कई थ्रेड का उपयोग गलत संचालन और अपवादों से भरा हुआ है।
2. किसी थ्रेड निष्पादन संदर्भ को संग्रहीत करने के लिए। उदाहरण के लिए, वर्तमान लेन-देन, डेटाबेस से एक कनेक्शन, आदि या डेटा जो केवल विधि हस्ताक्षर या सेटर के माध्यम से स्थानांतरित करने का निर्णय लेते हैं, लेकिन संदर्भ के माध्यम से धारा के लिए। उदाहरण के लिए, Struts2 में ActionContext ।

यदि पहले मामले में फोर्क / जॉइन करते समय कुछ भी भयानक नहीं होता है, तो दूसरे में, एक कार्य के स्थानीय चर दूसरे के लिए उपलब्ध हो जाएंगे।

Moral : इस मामले में थ्रेडलोक वैरिएबल का उपयोग न करें, या ForKJoinTask का समर्थन करने वाले अपने थ्रेडलोक एनालॉग को लागू करें।

अवरुद्ध

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

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

समस्या का हिस्सा इस तथ्य से हल किया जाता है कि सम्मिलित () अनिवार्य रूप से थ्रेड को पूल में लौटाता है।

समसामयिकता के आवश्यक स्तर को सुनिश्चित करने के लिए, ForJJoinPool एक नियंत्रित लॉकिंग तंत्र प्रदान करता है। ForkJoinPool.ManagedBlocker वर्ग का उपयोग करते हुए, हम ForkJoinPool 'y को बता सकते हैं कि थ्रेड लॉक के इंतजार में ब्लॉक हो सकता है और ForkJoinPool निर्दिष्ट स्तर के समानता प्रदान करने के लिए एक अतिरिक्त थ्रेड बनाएगा।

मान लीजिए कि हम अपने कोड में ReentrantLock का उपयोग करना चाहते हैं। हमें ForkJoinPool.anagedBlocker इंटरफ़ेस को निम्नानुसार लागू करना होगा (javadocs से लिया गया):

class ManagedLocker implements ManagedBlocker { final ReentrantLock lock; boolean hasLock = false; ManagedLocker(ReentrantLock lock) { this.lock = lock; } public boolean block() { if (!hasLock) lock.lock(); return true; } public boolean isReleasable() { return hasLock || (hasLock = lock.tryLock()); } } 

और कोड में निम्नानुसार लॉक का उपयोग करें:

 ReentrantLock lock = new ReentrantLock(); //Somewhere in thread try{ ForkJoinPool.managedBlock(new ManagedLocker(lock)); //Guarded code goes here }finally{ lock.unlock(); } 

वह सब है।

और बल आपके साथ आ सकता है!