मुझे लगता है कि कुछ कार्यों को बहुत लंबा समय लेने के लिए निर्धारित किया गया है और ScheduledThreadPoolExecutor अन्य कार्यों के लिए अतिरिक्त थ्रेड बनाएगा जिन्हें चलाने की आवश्यकता है, जब तक कि अधिकतम संख्या में धागे तक नहीं पहुंच जाते।शेड्यूल्ड थ्रेडपूलएक्सएटर केवल थ्रेड की निश्चित संख्या क्यों स्वीकार करता है?
लेकिन ऐसा लगता है कि मैं केवल पूल के लिए निश्चित संख्या में धागे निर्दिष्ट कर सकता हूं, ऐसा क्यों है?
क्यों, मुझे या तो नहीं पता। लेकिन मैं कल्पना कर सकता हूँ।
कंप्यूटर के संसाधनों की मात्रा सीमित है। सभी संसाधनों को समवर्ती रूप से संभाला नहीं जा सकता है।
यदि एकाधिक प्रक्रियाएं एक साथ फाइल लोड करती हैं, तो उन्हें धीरे-धीरे लोड किया जा रहा है, अगर वे अनुक्रमिक रूप से लोड हो रहे थे (कम से कम हार्डडिस्क पर)।
एक प्रोसेसर के साथ-साथ कई धागे को संभालने के लिए सीमित समर्थन भी है। किसी बिंदु पर ओएस या जेवीएम धागे को स्विच करने में अधिक समय व्यतीत करेंगे, धागे उनके कोड को निष्पादित करने में खर्च करते हैं।
ScheduledThreadPoolExecutor के लिए यह एक अच्छा कारण है जिस तरह से इसे डिजाइन किया जा सकता है। आप कतार पर किसी भी प्रकार की नौकरियां डाल सकते हैं, लेकिन कुशलतापूर्वक चलाने के मुकाबले एक ही समय में कभी भी अधिक नौकरियों को निष्पादित नहीं किया जाता है। बेशक, इसे संतुलित करने के लिए आप पर निर्भर है।
यदि आपके कार्य आईओ बाध्य हैं, तो मैं पूल आकार को छोटा कर दूंगा, और यदि वे सीपीयू बाध्य हैं, तो थोड़ा बड़ा (32 या तो)। आप कई ScheduledThreadPoolExecutor एस भी बना सकते हैं, एक आईओ बाध्य कार्यों के लिए और एक सीपीयू बाध्य कार्यों के लिए।
SchecduledThreadPoolExecutor के बारे में और जानकारी खोते समय मुझे यह link मिला, यह लिंक बताता है कि SchecduledThreadPoolExecutor टाइमर क्लास की कई समस्याओं को हल करता है। और SchecduledThreadPoolExecutor को शुरू करने का कारण टाइमर को प्रतिस्थापित करना था (टाइमर के साथ विभिन्न समस्याओं के कारण)। मुझे लगता है कि SchecduledThreadPoolExecutor को पास किए गए थ्रेड की निश्चित संख्या का कारण इस वर्ग को हल करने वाली समस्याओं में से एक है। यानी
टाइमर क्लास केवल एक थ्रेड शुरू होता है। हालांकि यह प्रति कार्य धागा बनाने से अधिक कुशल है, यह एक इष्टतम समाधान नहीं है। इष्टतम समाधान सभी कार्यों और प्रति कार्य एक थ्रेड के लिए एक थ्रेड के बीच धागे का उपयोग करने के लिए हो सकता है। प्रभाव में, सबसे अच्छा समाधान को थ्रेड के पूल में कार्य करना है। पूल में धागे की संख्या पर निर्माण के दौरान असाइन करने योग्य होनी चाहिए, इस कार्यक्रम को पूल में थ्रेड की इष्टतम संख्या निर्धारित करने की अनुमति दें।
तो मेरी राय में यह है जहां SchecduledThreadPoolExecutor के लिए उपयोग केस आ रहा है। आपके मामले में, आप उन कार्यों के आधार पर इष्टतम मूल्य निर्धारित करने में सक्षम होना चाहिए जिन्हें आप शेड्यूल करने की योजना बनाते हैं और इन कार्यों को पूरा करने में समय लगता है। यदि मेरे पास 4 लंबे समय तक चलने वाले कार्य हैं जो एक ही समय के लिए निर्धारित हैं, तो मैं एक ही समय में अन्य कार्यों को निष्पादित करने के लिए अपने पूल आकार को 4 से अधिक होना पसंद करूंगा। मैं पहले के उत्तरों में बताए गए अनुसार विभिन्न निष्पादक में लंबे समय तक चलने वाले कार्यों को अलग करना पसंद करूंगा।
आशा इस मदद करता है :)
Java Concurrency In Practice के अनुसार असीम धागा निर्माण के निम्नलिखित नुकसान कर रहे हैं:
थ्रेड lifecyle भूमि के ऊपर
धागा निर्माण और टियरडाउन मुक्त नहीं हैं। थ्रेड निर्माण में समय लगता है, और JVM और OS द्वारा कुछ प्रोसेसिंग गतिविधि की आवश्यकता होती है।
संसाधन खपत
सक्रिय धागे प्रणाली संसाधनों का उपभोग, विशेष रूप से स्मृति। जब उपलब्ध प्रोसेसर की तुलना में अधिक चलने योग्य धागे होते हैं, तो थ्रेड निष्क्रिय रहते हैं। कई निष्क्रिय धागे होने से कचरा कलेक्टर पर दबाव डालने, और सीपीयू के लिए प्रतिस्पर्धा करने वाले कई धागे होने से अन्य प्रदर्शन लागत भी लगा सकती है। यदि आपके पास सभी सीपीयू व्यस्त रखने के लिए पर्याप्त धागे हैं, तो अधिक थ्रेड बनाने से मदद नहीं मिलेगी और इससे भी चोट लग सकती है।
स्थिरता
कितने धागे बनाया जा सकता है पर एक सीमा होती है। सीमा प्लेटफ़ॉर्म द्वारा भिन्न होती है और जेवीएम इनवोकेशन पैरामीटर, थ्रेड कन्स्ट्रक्टर में अनुरोधित स्टैक आकार और अंतर्निहित ऑपरेटिंग सिस्टम द्वारा रखे थ्रेड पर सीमा सहित कारकों से प्रभावित होती है। जब आप एचटीआईएस सीमा को दबाते हैं, तो सबसे अधिक संभावना परिणाम आउटऑफमेमरी एरर होता है। ऐसी त्रुटि से पुनर्प्राप्त करने की कोशिश करना बहुत जोखिम भरा है; इस सीमा को मारने से बचने के लिए अपने कार्यक्रम को संरचित करना कहीं अधिक आसान है।
एक निश्चित बिंदु तक, अधिक धागे प्रवाह क्षमता में सुधार कर सकते, लेकिन उस समय अधिक धागे बनाने से सिर्फ आपके आवेदन को धीमा कर देती है, और बनाने एक धागा भी कई बुरी दुर्घटना के लिए अपने पूरे आवेदन पैदा कर सकता है। खतरे से बाहर रहने का तरीका यह है कि आपके आवेदन के कितने धागे पैदा होते हैं, और यह सुनिश्चित करने के लिए कि यह सीमा कब तक पहुंच जाती है, यह संसाधनों से बाहर नहीं निकलता है, यह सुनिश्चित करने के लिए कि आप अपने आवेदन का कितना धागा तैयार करते हैं, इस पर कुछ बाध्य होना है।
असंबद्ध थ्रेड सृजन प्रोटोटाइपिंग और विकास के दौरान ठीक काम करने के लिए प्रतीत होता है, जिसमें समस्या तब होती है जब एप्लिकेशन तैनात किया जाता है और भारी भार के तहत होता है।