जावा में InterruptedException को हैंडल करना

Question

हैंडलिंग के निम्नलिखित तरीकों में क्या अंतर है InterruptedException? यह करने के लिए सबसे अच्छा तरीका क्या है?

try{
 //...
} catch(InterruptedException e) { 
   Thread.currentThread().interrupt(); 
}

या

try{
 //...
} catch(InterruptedException e) {
   throw new RuntimeException(e);
}

संपादित करें: मैं यह भी जानना चाहूंगा कि इन दोनों का उपयोग किन परिदृश्यों में किया गया है।

Comments

javaspecialists.eu/archive/Issue056.html

— starblue

Answer 1

InterruptedException को संभालने के निम्नलिखित तरीकों में क्या अंतर है? यह करने के लिए सबसे अच्छा तरीका क्या है?

आप शायद यह सवाल पूछने आए हैं क्योंकि आपने एक ऐसा तरीका बताया है जो फेंकता है InterruptedException।

सबसे पहले, आपको यह देखना चाहिए throws InterruptedExceptionकि यह क्या है: विधि हस्ताक्षर का एक हिस्सा और जिस पद्धति से आप कॉल कर रहे हैं उसे कॉल करने का एक संभावित परिणाम। तो इस तथ्य को गले लगाकर शुरू करें कि InterruptedExceptionए विधि कॉल का पूरी तरह से वैध परिणाम है।

अब, यदि आप जिस विधि को ऐसे अपवाद कह रहे हैं, वह आपका तरीका क्या है? आप निम्नलिखित के बारे में सोचकर उत्तर का पता लगा सकते हैं:

क्या यह उस विधि के लिए समझ में आता है जिसे आप फेंकने के लिए लागू कर रहे हैं InterruptedException? अलग तरीके से कहें, क्या InterruptedExceptionएक समझदार परिणाम है जब आपके तरीके को बुला रहा है ?

• यदि हाँ , तो आपके विधि हस्ताक्षर throws InterruptedExceptionका हिस्सा होना चाहिए , और आपको अपवाद का प्रचार करने देना चाहिए (अर्थात इसे बिल्कुल न पकड़ें)।

  उदाहरण : आपकी विधि गणना समाप्त करने और परिणाम वापस करने के लिए नेटवर्क से मूल्य का इंतजार करती है। यदि अवरोधक नेटवर्क कॉल फेंकता है तो InterruptedExceptionआपकी विधि सामान्य तरीके से गणना समाप्त नहीं कर सकती है। आप InterruptedExceptionप्रचार करते हैं।

  int computeSum(Server server) throws InterruptedException {
      // Any InterruptedException thrown below is propagated
      int a = server.getValueA();
      int b = server.getValueB();
      return a + b;
  }
  

• यदि नहीं , तो आपको अपना तरीका घोषित नहीं करना throws InterruptedExceptionचाहिए और आपको अपवाद को पकड़ना चाहिए (चाहिए!)। इस स्थिति को ध्यान में रखने के लिए अब दो बातें महत्वपूर्ण हैं:

  1. किसी ने आपके धागे को बाधित किया। शायद कोई व्यक्ति इस अभियान को रद्द करने, कार्यक्रम को शालीनतापूर्वक, या जो भी हो, करने के लिए उत्सुक है। आपको उस व्यक्ति के प्रति विनम्र होना चाहिए और आगे की विधि के बिना अपने तरीके से वापस आना चाहिए।

  2. भले ही आपकी विधि InterruptedExceptionइस तथ्य के मामले में एक समझदार वापसी मूल्य का उत्पादन करने का प्रबंधन कर सकती है कि थ्रेड बाधित हो गया है फिर भी महत्व का हो सकता है। विशेष रूप से, आपकी पद्धति को कॉल करने वाला कोड आपकी पद्धति के निष्पादन के दौरान एक रुकावट है या नहीं, इस बात में दिलचस्पी हो सकती है। इसलिए आपको इस तथ्य को लॉग करना चाहिए कि बाधित ध्वज को स्थापित करने में एक रुकावट आई थी:Thread.currentThread().interrupt()

  उदाहरण : उपयोगकर्ता ने दो मानों का योग छापने को कहा है। मुद्रण " Failed to compute sum" स्वीकार्य है यदि योग की गणना नहीं की जा सकती है (और प्रोग्राम को क्रैश होने के कारण स्टैक ट्रेस के साथ देने से बेहतर है InterruptedException)। दूसरे शब्दों में, इस पद्धति को घोषित करने का कोई मतलब नहीं हैthrows InterruptedException ।

  void printSum(Server server) {
       try {
           int sum = computeSum(server);
           System.out.println("Sum: " + sum);
       } catch (InterruptedException e) {
           Thread.currentThread().interrupt();  // set interrupt flag
           System.out.println("Failed to compute sum");
       }
  }
  

अब तक यह स्पष्ट होना चाहिए कि बस करना throw new RuntimeException(e)एक बुरा विचार है। यह फोन करने वाले के लिए बहुत विनम्र नहीं है। आप एक नए रनटाइम अपवाद का आविष्कार कर सकते हैं लेकिन मूल कारण (कोई व्यक्ति निष्पादन को रोकना चाहता है) खो सकता है।

अन्य उदाहरण:

कार्यान्वित करनाRunnable : जैसा कि आपने खोज लिया होगा, हस्ताक्षर Runnable.runपुन: डूबने की अनुमति नहीं देता है InterruptedExceptions। ठीक है, आपने लागू करने पर हस्ताक्षर किए हैं Runnable, जिसका अर्थ है कि आपने संभव से निपटने के लिए हस्ताक्षर किए हैं InterruptedExceptions। या तो एक अलग इंटरफ़ेस चुनें, जैसे कि Callable, या ऊपर दिए गए दूसरे दृष्टिकोण का पालन करें।

 

कॉल करनाThread.sleep : आप एक फ़ाइल पढ़ने का प्रयास कर रहे हैं और युक्ति कहती है कि आपको बीच में 1 सेकंड के साथ 10 बार कोशिश करनी चाहिए। तुम बुलाओ Thread.sleep(1000)। इसलिए, आपको इससे निपटने की जरूरत है InterruptedException। एक विधि के लिए जैसे कि tryToReadFileयह कहना सही अर्थ है, "अगर मैं बाधित हूं, तो मैं फ़ाइल पढ़ने की कोशिश करने की अपनी कार्रवाई को पूरा नहीं कर सकता" । दूसरे शब्दों में, यह फेंकने की विधि के लिए एकदम सही समझ में आता है InterruptedExceptions।

String tryToReadFile(File f) throws InterruptedException {
    for (int i = 0; i < 10; i++) {
        if (f.exists())
            return readFile(f);
        Thread.sleep(1000);
    }
    return null;
}

---

इस पोस्ट को यहाँ एक लेख के रूप में फिर से लिखा गया है ।

Comments

दूसरी विधि में क्या समस्या है?

— ब्लिट्जक्रेग्ज

लेख कहता है कि आपको interrupt()बाधित स्थिति को संरक्षित करने के लिए कॉल करना चाहिए । ऐसा करने के पीछे क्या कारण है Thread.sleep()?

— oksayt

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

— अमोघ

कॉलिंग मेथड्स जो InterruptedException को फेंकते हैं और कहते हैं कि आप "इंटरप्ट का समर्थन नहीं करते हैं" ऐसा लगता है जैसे मैला प्रोग्रामिंग और एक बग होने की प्रतीक्षा कर रहा है। अलग रखो; यदि आप एक विधि को बुलाते हैं जिसे InterruptedException को फेंकने के लिए घोषित किया जाता है, तो यह एक अप्रत्याशित स्थिति नहीं होनी चाहिए यदि वह विधि वास्तव में ऐसा अपवाद फेंकती है।

— aioobe

@MartiNito, नहीं, Thread.currentThread.interrupt()एक InterruptedExceptionपकड़ने वाले ब्लॉक में कॉल करना केवल रुकावट का झंडा तय करेगा। यह किसी अन्य InterruptedExceptionको बाहरी InterruptedExceptionकैच ब्लॉक में फेंका / पकड़ा नहीं जाएगा ।

— ऐयोबेब

Answer 2

जैसा कि ऐसा होता है कि मैं इस सुबह के बारे में पढ़ रहा था मेरे रास्ते में ब्रायन गोएट्ज द्वारा जावा कंजेरिबिलिटी प्रैक्टिस में काम करने के लिए । मूल रूप से वह कहता है कि आपको तीन चीजों में से एक करना चाहिए

1. प्रोपेगेटInterruptedException - चेक फेंकने के लिए अपनी विधि की घोषणा करें InterruptedExceptionताकि आपके कॉलर को इससे निपटना पड़े।

2. व्यवधान को पुनर्स्थापित करें - कभी-कभी आप फेंक नहीं सकते InterruptedException। इन मामलों में आपको विधि को InterruptedExceptionकॉल करके बाधा स्थिति को पकड़ना चाहिए और पुनर्स्थापित करना चाहिए ताकि कॉल स्टैक को उच्चतर कोड देख सकें कि एक बाधा जारी की गई थी, और जल्दी से विधि से वापस आ गया। नोट: यह केवल तब लागू होता है जब आपके तरीके में "प्रयास" या "सर्वोत्तम प्रयास" शब्दार्थ होता है, अर्थात यदि विधि अपने लक्ष्य को पूरा नहीं करती है तो कुछ भी महत्वपूर्ण नहीं होगा। उदाहरण के लिए, या ऐसी विधि हो सकती है, या , लेकिन नहीं । अधिक जानकारी के लिए यहां देखें ।interrupt()currentThreadlog()sendMetric()boolean tryTransferMoney()void transferMoney()

3. विधि के भीतर रुकावट को अनदेखा करें, लेकिन बाहर निकलने पर स्थिति को पुनर्स्थापित करें - जैसे कि अमरूद के माध्यम से Uninterruptibles। UninterruptiblesJCIP .3 7.1.3 में नॉनकेंसेबल टास्क उदाहरण में बॉयलरप्लेट कोड को संभालें।

Comments

"कभी-कभी आप InterruptedException को नहीं फेंक सकते हैं" - मैं कहूंगा, कभी-कभी यह InterruptedException को प्रचारित करने के लिए विधि के लिए उपयुक्त नहीं है । आपका सूत्रीकरण यह सुझाव देता है कि जब भी आप कर सकते हैं, आपको इंटरप्टेड अपवाद को फिर से उखाड़ फेंकना चाहिए ।

— aioobe

और यदि आपको अध्याय 7 पढ़ने को मिला, तो आप देखेंगे कि इसमें कुछ सूक्ष्मताएँ हैं, जैसे कि सूचीबद्घ 7.7 में, जहाँ एक गैर-उद्देश्यपूर्ण कार्य तुरंत बाधा को बहाल नहीं करता है , लेकिन इसके पूरा होने के बाद ही। इसके अलावा गोएट्ज के पास उस पुस्तक के कई सह-लेखक हैं ...

— फिज़ा

मुझे आपका उत्तर पसंद है क्योंकि यह संक्षिप्त है, हालांकि मेरा मानना ​​है कि इसे दूसरे मामले में अपने कार्य से धीरे और जल्दी लौटने के लिए भी कहना चाहिए। बीच में थ्रेड.सलीप () के साथ एक लंबे (या अनंत) लूप की कल्पना करें। InterruptedException के कैच को Thread.currentThread ()। इंटरप्ट () को कॉल करना चाहिए और लूप से बाहर आना चाहिए ।

— यन वॉन

@YannVo मैंने आपके सुझाव को लागू करने के लिए उत्तर संपादित किया है।

— लीवेंटोव

Answer 3

तुम क्या करने की कोशिश कर रहे हो?

InterruptedExceptionफेंक दिया जाता है जब एक धागा इंतजार कर या सो रहा और एक अन्य धागा बीच में आता है यह उपयोग कर रहा है interruptकक्षा में विधि Thread। इसलिए यदि आप इस अपवाद को पकड़ते हैं, तो इसका मतलब है कि धागा बाधित हो गया है। आमतौर पर Thread.currentThread().interrupt();फिर से कॉल करने का कोई मतलब नहीं है , जब तक आप धागे की "बाधित" स्थिति को कहीं और से जांचना चाहते हैं।

ए फेंकने के आपके अन्य विकल्प के बारे में RuntimeException, यह करना बहुत समझदारी की बात नहीं है (जो इसे पकड़ लेगा? उसे कैसे संभाला जाएगा?) लेकिन अतिरिक्त जानकारी के बिना अधिक बताना मुश्किल है।

Comments

कॉलिंग Thread.currentThread().interrupt()बाधित ध्वज (फिर से) को सेट करता है, जो वास्तव में उपयोगी है यदि हम यह सुनिश्चित करना चाहते हैं कि बाधा को ध्यान दिया जाए और उच्च स्तर पर संसाधित किया जाए।

— Péter Török

@ Péter: मैं केवल इस उल्लेख का उत्तर अपडेट कर रहा था। धन्यवाद।

— ग्रोड्रिग्ज

Answer 4

मेरे लिए इस बारे में महत्वपूर्ण बात यह है: एक InterruptedException कुछ भी गलत नहीं हो रहा है, यह वह धागा है जो आपने इसे करने के लिए कहा था। इसलिए इसे RuntimeException में लिपटे हुए रीथ्रोइंग से शून्य समझ में आता है।

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

इसलिए InterruptedException को प्रचारित करें, या इसे समझदारी से खाएं (ऐसी जगह पर इसका अर्थ है जहां यह पूरा हो जाएगा कि इसका क्या करना था) और इंटरप्ट फ्लैग को रीसेट करें। ध्यान दें कि इंटरप्टेड एक्ससेप्शन फेंके जाने पर इंटरप्ट फ्लैग क्लियर हो जाता है; Jdk लाइब्रेरी डेवलपर्स की धारणा यह है कि अपवाद मात्रा को पकड़ने के लिए इसे पकड़ना, इसलिए डिफ़ॉल्ट रूप से ध्वज को साफ़ किया जाता है।

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

यहाँ एक उत्तर दिया गया है जिसमें मैंने वर्णन किया है कि एक उदाहरण के साथ काम कैसे बाधित होता है । आप उदाहरण कोड में देख सकते हैं जहां यह Runnable की रन विधि में थोड़ी देर के लूप से बाहर निकलने के लिए InterruptedException का उपयोग कर रहा है।

Answer 5

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

जावा ने बेतरतीब ढंग से InterruptedException's को फेंक नहीं दिया, सभी सलाह आपके आवेदन को प्रभावित नहीं करेगी लेकिन मैं ऐसे मामले में चला गया हूं, जहां "निगल" रणनीति के बाद डेवलपर की स्थिति बहुत असुविधाजनक हो गई है। एक टीम ने परीक्षणों का एक बड़ा सेट विकसित किया था और थ्रेड का उपयोग किया था। अब हमने अपने CI सर्वर में परीक्षण चलाना शुरू कर दिया, और कभी-कभी कोड में दोषों के कारण स्थायी प्रतीक्षा में फंस जाते। स्थिति को बदतर बनाने के लिए, जब सीआई की नौकरी को रद्द करने का प्रयास किया गया तो यह कभी बंद नहीं हुआ क्योंकि थ्रेड.इंटरप्ट जो कि परीक्षण को निरस्त करने का इरादा था, नौकरी को निरस्त नहीं करता था। हमें बॉक्स में लॉग इन करना था और मैन्युअल रूप से प्रक्रियाओं को मारना था।

इतनी लंबी कहानी छोटी है, अगर आप बस InterruptedException फेंकते हैं तो आप डिफ़ॉल्ट इरादे से मेल खा रहे हैं कि आपका धागा समाप्त होना चाहिए। यदि आप अपने फेंक सूची में InterruptedException नहीं जोड़ सकते हैं, तो मैं इसे RuntimeException में लपेटूंगा।

एक बहुत ही तर्कसंगत तर्क दिया जाना चाहिए कि InterruptedException स्वयं एक RuntimeException होनी चाहिए, क्योंकि यह एक बेहतर "डिफ़ॉल्ट" हैंडलिंग को प्रोत्साहित करेगी। यह केवल एक RuntimeException नहीं है, क्योंकि डिज़ाइनर एक स्पष्ट नियम से चिपके हुए हैं कि RuntimeException आपके कोड में एक त्रुटि का प्रतिनिधित्व करना चाहिए। चूंकि एक InterruptedException सीधे आपके कोड की किसी त्रुटि से उत्पन्न नहीं होती है, इसलिए यह नहीं है। लेकिन वास्तविकता यह है कि अक्सर एक InterruptedException उत्पन्न होती है क्योंकि आपके कोड में एक त्रुटि है, (यानी अंतहीन लूप, डेड-लॉक), और Interrupt उस त्रुटि से निपटने के लिए कुछ अन्य थ्रेड विधि है।

यदि आप जानते हैं कि तर्कसंगत सफाई की जानी है, तो इसे करें। यदि आप इंटरप्ट के लिए एक गहरा कारण जानते हैं, तो आप अधिक व्यापक हैंडलिंग ले सकते हैं।

इसलिए सारांश में, इस सूची को संभालने के लिए आपके विकल्पों का पालन करना चाहिए:

1. डिफ़ॉल्ट रूप से, थ्रो में जोड़ें।
2. यदि थ्रो में जोड़ने की अनुमति नहीं है, तो RuntimeException (e) को फेंक दें। (कई बुरे विकल्पों में से सर्वश्रेष्ठ विकल्प)
3. केवल जब आप इंटरप्ट का स्पष्ट कारण जानते हैं, तो वांछित रूप से संभाल लें। यदि आपकी हैंडलिंग आपकी विधि के लिए स्थानीय है, तो थ्रेड.ट्रैकट्रेड ()। इंटरप्ट () के लिए एक कॉल द्वारा बाधित रीसेट करें।

Answer 6

मैं सिर्फ एक आखिरी विकल्प जोड़ना चाहता था जो ज्यादातर लोग और लेखों का उल्लेख करते हैं। जैसा कि mR_fr0g ने कहा है, यह महत्वपूर्ण है कि बाधा को सही ढंग से या तो संभाल लिया जाए:

• InterruptException का प्रचार करना

• थ्रेड पर इंटरप्ट अवस्था को पुनर्स्थापित करें

या इसके अतिरिक्त:

• व्यवधान की कस्टम हैंडलिंग

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

मैं इस विषय को समझने की अत्यधिक सलाह देता हूं, लेकिन यह लेख जानकारी का एक अच्छा स्रोत है: http://www.ibm.com/developerworks/java/library/j-jtp05236/

Answer 7

मैं कहूंगा कि कुछ मामलों में कुछ भी नहीं करना ठीक है। संभवत: कुछ ऐसा नहीं है जो आपको डिफ़ॉल्ट रूप से करना चाहिए, लेकिन मामले में होने वाली रुकावट के लिए कोई रास्ता नहीं होना चाहिए, मुझे यकीन नहीं है कि क्या करना है (शायद लॉगिंग त्रुटि, लेकिन यह प्रोग्राम प्रवाह को प्रभावित नहीं करता है)।

एक मामला यह होगा कि आपके पास एक कार्य (अवरुद्ध) कतार है। यदि आपके पास इन कार्यों को संभालने वाला एक डेमॉन थ्रेड है और आप थ्रेड को अपने आप से बाधित नहीं करते हैं (मेरी जानकारी में जेवीएम जेवीएम शटडाउन पर डेमन थ्रेड्स को बाधित नहीं करता है), मुझे ऐसा होने का कोई रास्ता नहीं दिखता है, और इसलिए यह हो सकता है बस नजरअंदाज कर दिया। (मुझे पता है कि डेमन धागे को किसी भी समय jvm द्वारा मारा जा सकता है और इसलिए कुछ मामलों में अनुपयुक्त हैं)।

EDIT: एक और मामला हो सकता है कि प्रखंडों को संरक्षित किया जाए, कम से कम Oracle के ट्यूटोरियल के आधार पर: http://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html

Comments

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

— अजाक्स

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

— ब्रजने बोर्स्र्म

या दूसरे तरीके से डालें: मेरी राय में एक अतिरिक्त त्रुटि लॉग स्टेटमेंट (और उदाहरण के लिए त्रुटि लॉग पर मेल भेजना) होने का जोखिम उठाना बेहतर है, एक आवेदन होने की तुलना में जो 24/7 चलने वाला होना चाहिए, जो एक इंटरप्रेटेसेप्शन के कारण बंद होना चाहिए, जिसके लिए मुझे सामान्य परिस्थितियों में होने का कोई रास्ता नहीं दिख रहा है।

— बोर्ज़ान बोर्स्राम

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

— अजाक्स