2009-02-16 9 views
9

Java memory model यह स्पष्ट करता है कि थ्रेड कैसे स्मृति के माध्यम से बातचीत करते हैं, इस बारे में क्या माना जा सकता है और नहीं माना जा सकता है। उदाहरण के लिए, यदि एक थ्रेड उचित सिंक्रनाइज़ेशन के बिना किसी फ़ील्ड में एक नया मान लिखता है तो नए मान को अन्य धागे द्वारा देखने योग्य होने की गारंटी नहीं है। अभ्यास में, हालांकि, अन्य धागे किसी भी तरह से अपर्याप्त सिंक्रनाइज़ेशन के बावजूद नए मूल्य को पढ़ सकते हैं, लिखने और पढ़ने, हार्डवेयर आर्किटेक्चर आदि के बीच के समय के आधार परक्या JVM का सबसे खराब केस कार्यान्वयन है?

इससे ऐसी बग हो सकती हैं जो खोजना मुश्किल हो और पुन: पेश करना मुश्किल हो । इसलिए यह एक सबसे खराब मामले JVM पर जावा एप्लिकेशन चलाने के लिए उपयोगी हो सकता है जिसने Java memory model में गारंटी से परे धागे के बीच बिल्कुल कोई स्मृति सिंक्रनाइज़ेशन नहीं किया। क्या ऐसा सबसे खराब मामला JVM कार्यान्वयन मौजूद है?

+0

मैंने सोचा कि सूर्य ने इसे लिखा है। – GEOCHET

+0

मैंने सोचा कि माइक्रोसॉफ्ट जे ++ यह था। –

+3

आप दोनों सोचते हैं कि आप मजाकिया हैं, लेकिन दोनों नकारात्मक और नकारात्मक के बजाय माइक्रोसॉफ्ट के बारे में सकारात्मक बातें कह रहे हैं। यह सबसे अच्छा होगा यदि JVM हमेशा स्मृति मॉडल से सबसे खराब केस परिणाम दिखाता है क्योंकि इससे सबसे अधिक बग प्रकट होंगे, लेकिन यह अभी मामला नहीं है, जहां इनमें से अधिकतर बग छिपाए गए हैं – Pyrolistical

उत्तर

2

आप अपने प्रोग्राम को क्लस्टर करने के लिए Terracotta का उपयोग करने का प्रयास कर सकते हैं। यह गलत सिंक्रनाइज़ेशन के आसपास अविश्वसनीय रूप से क्षमा नहीं कर रहा है (जो क्लस्टर में केवल एक नोड के साथ भी स्पष्ट हो जाएगा)। वहाँ मानक JRE -XXJMMExtreme

टेराकोटा में एक स्विच है नहीं है खुला स्रोत और बुनियादी उत्पाद के लिए मुफ्त मैं हैरान हूँ - मैं अक्सर वास्तव में इस क्षमता चाहता था: यह एक महान सवाल है।

0

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

0

ऐसे कई तरीके हैं जो संगामिति बग को चालू कर सकते हैं। की तुलना में आप सामान्य रूप से उम्मीद होती है

  • कई और अधिक धागे के लिए आपके आवेदन लोड करें। सुनिश्चित करें कि 99% + सीपीयू प्राप्त करने के लिए यह पर्याप्त है।
  • अपने प्रोग्राम को एक प्रोफाइलर सक्षम या जेआईटी अक्षम के साथ चलाएं। यह आपके आवेदन के समय व्यवहार को बदलता है।
  • जावा 5 और जावा 6 दोनों का परीक्षण करें (यह अक्सर सबसे आसान और कुछ बग खोजने का सबसे अच्छा तरीका है) मुझे जावा 7 का उपयोग करके एक बग नहीं मिली है जो 5/6 में दिखाई नहीं दे रहा था।

सबसे खराब मामले के लिए JVM, मोबाइल फोन आज़माएं। (आपका आवेदन शायद बिल्कुल काम नहीं करेगा);

0

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

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

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