निष्पादक सेवा इंटरफ़ेस ऑटोक्लोसेबल को लागू क्यों नहीं करता है?

Question

थ्रेड एक्जिक्यूटर पर shutdown() पर कॉल करने में विफल होने के परिणामस्वरूप कभी भी समाप्त नहीं होगा।

ExecutorService service = null; 
try { 
    service = Executors.newSingleThreadExecutor(); 
    // Add tasks to thread executor 
    … 
} finally { 
    if(service != null) service.shutdown(); 
} 

के बाद से जावा कोशिश के साथ-संसाधनों अवधारणा जानता है, यह अच्छा नहीं होगा अगर हम ऐसा कर सकता है: ExecutorService बंद करने के लिए सबसे अच्छा अभ्यास है?

try (service = Executors.newSingleThreadExecutor()) 
{ 
    // Add tasks to thread executor 
    … 
} 

Answer 1

ExecutorService वास्तव में दो बंद से संबंधित तरीकों है कि; सरल तथ्य के आधार पर कि दोनों सेवा बंद करने के तरीके समझ में आते हैं।

इस प्रकार: आप फिर सेवा को स्वतः बंद कैसे करेंगे? एक निरंतर तरीके से जो हर किसी के लिए काम करता है ?!

तो, मेरी आंखों में उचित स्पष्टीकरण: आप निष्पादक सेवा को ऑटोक्लोसेबल नहीं बना सकते क्योंकि उस सेवा में ऑपरेशन की तरह एक "करीबी" नहीं है; लेकिन दो!

और यदि आपको लगता है कि आप ऐसी ऑटो-क्लोजिंग सेवा का अच्छा उपयोग कर सकते हैं, तो "प्रतिनिधिमंडल" का उपयोग करके अपना स्वयं का कार्यान्वयन लिखना 5 मिनट की बात होगी! या शायद 10 मिनट, क्योंकि आप shutdown() को बंद ऑपरेशन के रूप में कॉल करने वाला एक संस्करण बनायेंगे; और एक जो shutdownNow() इसके बजाए करता है।

Answer 2

रीयल-टू-रिसोर्स रीडर/स्ट्रीम के ऑटो-क्लोजिंग के बारे में है, जहां एक्जिक्यूटर्स सेवा थ्रेड के पूल का उपयोग करके कार्यों को निष्पादित करने के बारे में है।

इसलिए मुझे सच में यकीन नहीं है कि दोनों के बीच समानांतर है कि हम निष्पादक सेवा के साथ-साथ संसाधनों को लागू करने के बारे में सोच सकते हैं।

UPDATED
का हवाला देते हुए जावा भाषा विशिष्टता:

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

स्पेक "संसाधन" के रूप में चर को कॉल करता है। तो मुझे यकीन है कि अगर ExecutorService एक संसाधन के रूप कहा जा सकता है और इतने ExecutorService को पाठकों/स्ट्रीम/स्टेटमेंट/ResultSet/कनेक्शन आदि

Answer 3

एक समानांतर रूप में नहीं लगता कि यह एक औसत दर्जे का वैकल्पिक हल

ExecutorService service = Executors.newSingleThreadExecutor(); 
try (Closeable close = service::shutdown) { 

} 

है नहीं कर रहा हूँ

बेशक, आपको कभी भी असाइनमेंट और try कथन के बीच कुछ भी नहीं रखना चाहिए, न ही try कथन के बाद service स्थानीय चर का उपयोग करना चाहिए।

चेतावनियों को देखते हुए, बस इसके बजाय finally का उपयोग करें।

Answer 4

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

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