2012-02-18 18 views
7

जावा में किसी एप्लिकेशन को लागू करने के लिए कई कारणों से कई प्रक्रियाओं में से कौन से कारणों का चयन करेंगे?जावा में धागे पर कई प्रक्रियाओं का चयन कब करें?

मैं एक पुराने जावा एप्लिकेशन को दोबारा कर रहा हूं जो वर्तमान में एक ही बहु-कोर मशीन पर चलने वाले कई छोटे अनुप्रयोगों (प्रक्रियाओं) में विभाजित है, जो एक दूसरे को सॉकेट के माध्यम से संचारित करता है।

मुझे व्यक्तिगत रूप से लगता है कि यह प्रक्रियाओं के बजाय धागे का उपयोग करके किया जाना चाहिए, लेकिन मूल तर्क की रक्षा किस तर्क से होगी?

उत्तर

9

मैं (और अन्य, नीचे विशेषताएं देखें) कारणों की एक जोड़ी के बारे में सोच सकते हैं:

ऐतिहासिक कारणों

  • डिजाइन दिन गए जब केवल हरी धागे उपलब्ध थे और मूल से है लेखक/डिजाइनर ने सोचा कि वे उसके लिए काम नहीं करेंगे।

सशक्तता और दोष सहिष्णुता

  • आप घटकों जो सुरक्षित थ्रेड नहीं कर रहे हैं का उपयोग करें, तो आप कई प्रक्रियाओं का सहारा withough parallelize नहीं कर सकते।

  • कुछ घटक छोटी हैं और आप नहीं चाहते हैं कि वे एक से अधिक प्रक्रियाओं को प्रभावित कर सकें। कहें, अगर किसी घटक में स्मृति या संसाधन रिसाव होता है जो अंततः प्रक्रिया को पुनरारंभ करने के लिए मजबूर कर सकता है, तो केवल घटक का उपयोग करने की प्रक्रिया प्रभावित होती है।

  • सही मल्टीथ्रेडिंग अभी भी करना मुश्किल है। मल्टीप्रोसेसिंग से आपके डिजाइन पर निर्भर करता है। बाद में, हालांकि, तर्कसंगत भी बहुत आसान नहीं है।

  • आपके पास एक मॉडल हो सकता है जहां आपके पास वॉचडॉग प्रक्रिया है जो क्रैश किए गए कार्यकर्ता प्रक्रियाओं को सक्रिय रूप से मॉनिटर (और अंततः पुनरारंभ) कर सकती है। इसमें प्रक्रियाओं को निलंबित/फिर से शुरू करना भी शामिल हो सकता है, जो धागे से सुरक्षित नहीं है (@Jayan को इंगित करने के लिए धन्यवाद)।

ओएस संसाधन सीमाएं & शासन

  • तो प्रक्रिया, किसी एकल थ्रेड का उपयोग कर, पहले से ही उपलब्ध पता स्थान के सभी उपयोग कर रहा है (विंडोज 2GB पर 32 बिट क्षुधा के लिए उदाहरण के लिए), तो आपको प्रक्रियाओं के बीच काम वितरित करने की आवश्यकता हो सकती है।

  • संसाधनों (सीपीयू, मेमोरी, इत्यादि) के उपयोग को सीमित करना आम तौर पर केवल प्रति प्रक्रिया आधार पर संभव है (उदाहरण के लिए विंडोज़ पर आप "नौकरी" ऑब्जेक्ट्स बना सकते हैं, जिसके लिए एक अलग प्रक्रिया की आवश्यकता होती है)।

सुरक्षा संबंधी

  • आप अलग अलग खातों (अर्थात "उन") का उपयोग विभिन्न प्रक्रियाओं को चलाने के इस प्रकार उन दोनों के बीच बेहतर अलगाव प्रदान कर सकते हैं।

संगतता मुद्दे

  • समर्थन एकाधिक/विभिन्न जावा संस्करणों: differnt प्रक्रियाओं का उपयोग करते हुए आप अपने आवेदन भागों के लिए अलग जावा संस्करणों का उपयोग कर सकते हैं (यदि 3 पार्टी पुस्तकालयों के लिए आवश्यक)।

स्थान पारदर्शिता

  • आप (संभावित) अपने आवेदन कई शारीरिक मशीनों से अधिक वितरित कर सकता है, इस प्रकार आगे आवेदन की क्षमता और/या मजबूती बढ़ती (अधिक विवरण के लिए @Qwe's answer देख/मूल विचार)।
+0

उत्कृष्ट सूची या तर्क, धन्यवाद! – wannabeartist

+0

+1 जो कुछ भी मैंने सूचीबद्ध किया है उसे कवर करता है। (मैं संसाधन प्रबंधन और विशेषाधिकार अलगाव वस्तुओं पर जोर देता हूं; वे सामान हैं जो आप अलग प्रक्रियाओं के बिना नहीं कर सकते हैं, हालांकि कभी-कभी इन दिनों आप वीएम को अलग करने के लिए आगे जाते हैं।) –

+0

+1 क्या मजबूती 'गलती सहनशीलता' कुछ प्रक्रियाओं की तरह लॉन्च और अन्य प्रक्रियाओं को देखना (पोस्टग्रेस कुछ ऐसा करता है)। – Jayan

6

यदि आप धागे के साथ जाने का फैसला करते हैं तो आप अपने ऐप को एक मशीन पर चलाने के लिए प्रतिबंधित कर देंगे। यह समाधान स्केल नहीं करता है (या कुछ हद तक स्केल) - हमेशा हार्डवेयर सीमाएं होती हैं।

और सॉकेट के माध्यम से संचार करने वाली विभिन्न प्रक्रियाओं को मशीनों के बीच वितरित किया जा सकता है, ताकि आप लगभग असीमित संख्या या उन्हें जोड़ सकें। यह प्रक्रियाओं के बीच धीमी संचार की लागत पर बेहतर है।

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

+0

बहुत सच है। इस मामले में, एप्लिकेशन हमेशा एक मशीन पर चलने के लिए है, लेकिन आमतौर पर विचार करने के लिए एक बहुत ही वैध बिंदु है। – wannabeartist

संबंधित मुद्दे