सीमित क्षमता BlockingQueue भी सहायक है यदि आप किसी प्रकार के अनुरोध को थ्रॉटल करना चाहते हैं। एक असंबद्ध कतार के साथ, एक निर्माता उपभोक्ताओं से बहुत आगे हो सकता है। कार्यों को अंततः निष्पादित किया जाएगा (जब तक कि इतने सारे लोग नहीं हैं कि वे OutOfMemoryError) का कारण बनते हैं, लेकिन निर्माता लंबे समय से छोड़ चुके हैं, इसलिए प्रयास बर्बाद हो गया है।
इन तरह की स्थितियों में, यह एक निर्माता बनने के लिए बेहतर हो सकता है कि कतार पूर्ण है, और विफलता के साथ जल्दी छोड़ने के लिए। उदाहरण के लिए, निर्माता एक वेब अनुरोध हो सकता है, ऐसे उपयोगकर्ता के साथ जो बहुत लंबा इंतजार नहीं करना चाहता, और भले ही यह प्रतीक्षा करते समय कई CPU चक्रों का उपभोग नहीं करेगा, यह सॉकेट और कुछ मेमोरी जैसे सीमित संसाधनों का उपयोग कर रहा है । देने से उन कार्यों को दिया जाएगा जो समय-समय पर समाप्त होने के लिए पहले से ही एक बेहतर मौका है।
संशोधन सवाल है, जो मैं के रूप में व्याख्या कर रहा हूँ, के बारे में
"क्या एक पूल में वस्तुओं के आयोजन के लिए एक अच्छा संग्रह है?"
एक unbounded LinkedBlockingQueue कई पूल के लिए एक अच्छा विकल्प है। हालांकि, आपके पूल प्रबंधन रणनीति के आधार पर, ConcurrentLinkedQueue भी काम कर सकता है।
पूलिंग एप्लिकेशन में, अवरुद्ध "डाल" उचित नहीं है। कतार के अधिकतम आकार को नियंत्रित करना पूल प्रबंधक — का काम है यह पूल के संसाधनों को बनाने या नष्ट करने का निर्णय लेता है। पूल के ग्राहक उधार लेते हैं और पूल से संसाधन वापस करते हैं। एक नई वस्तु जोड़ना, या पूल में पहले उधारित वस्तु को वापस करना तेजी से, गैर-अवरुद्ध संचालन होना चाहिए। तो, एक बाध्य क्षमता कतार पूल के लिए एक अच्छा विकल्प नहीं है।
दूसरी ओर, पूल से ऑब्जेक्ट पुनर्प्राप्त करते समय, अधिकांश एप्लिकेशन संसाधन तक उपलब्ध होने तक प्रतीक्षा करना चाहते हैं। एक "टेक" ऑपरेशन जो कम से कम अस्थायी रूप से ब्लॉक करता है, संसाधनों के उपलब्ध होने तक "व्यस्त प्रतीक्षा" — बार-बार मतदान करने से अधिक कुशल होता है। इस मामले में LinkedBlockingQueue एक अच्छा विकल्प है। एक उधारकर्ता take के साथ अनिश्चित काल तक अवरुद्ध कर सकता है, या poll के साथ ब्लॉक करने के इच्छुक समय को सीमित कर सकता है।
जब कोई ग्राहक ब्लॉक करने के लिए तैयार नहीं होता है तो कम आम मामला है, लेकिन पूल खाली होने पर स्वयं के लिए संसाधन बनाने की क्षमता है। उस स्थिति में, ConcurrentLinkedQueue एक अच्छा विकल्प है। यह एक ग्रे क्षेत्र का प्रकार है जहां संसाधन जितना संभव हो सके संसाधन (उदा।, स्मृति) साझा करना अच्छा होगा, लेकिन गति और भी महत्वपूर्ण है। बदतर मामले में, यह हर धागे को संसाधन का अपना उदाहरण रखने के लिए अपमानित करता है; तो धागे के बीच साझा करने की कोशिश करने से परेशान न होने के कारण यह अधिक कुशल होता।
इनमें से दोनों संग्रह एक समवर्ती आवेदन में अच्छा प्रदर्शन और उपयोग में आसानी देते हैं। गैर-समवर्ती अनुप्रयोगों के लिए, ArrayList को हरा करना मुश्किल है। यहां तक कि गतिशील रूप से बढ़ने वाले संग्रहों के लिए, LinkedList के प्रति-तत्व ओवरहेड ArrayList को कुछ खाली स्लॉट के साथ प्रतिस्पर्धी स्मृति-वार रहने के लिए अनुमति देता है।
धन्यवाद एरिक्सन का उपयोग अपने
Queueकार्यान्वयन के बाद किया जाएगा। इसने मेरी समस्या हल कर दी है। –