मैं जावा (और जेबॉस प्लेटफ़ॉर्म पर) में आउट ऑफ़ मेमोरी त्रुटि स्थितियों को संभालने पर article पढ़ रहा था और मैंने थ्रेडस्टैक के आकार को कम करने के लिए यह सुझाव देखा।जावा जेवीएम थ्रेड स्टैक के आकार को कम क्यों करें?
थ्रेडस्टैक के आकार को अधिकतम मेमोरी त्रुटि स्थिति के साथ कैसे कम करेगा?
जब जावा एक नया धागा बनाता है, तो यह उस धागे के ढेर के लिए स्मृति के एक निश्चित आकार ब्लॉक को पूर्व-आवंटित करता है। उस मेमोरी ब्लॉक के आकार को कम करके, आप स्मृति से बाहर निकलने से बच सकते हैं, खासकर यदि आपके पास बहुत सारे धागे हैं - स्मृति की बचत स्टैक आकार में थ्रेड की संख्या में कमी है।
ऐसा करने का नकारात्मक पक्ष यह है कि आप एक स्टैक ओवरफ़्लो त्रुटि का मौका बढ़ाते हैं।
ध्यान दें कि धागे के ढेर जेवीएम ढेर के बाहर बनाए जाते हैं, भले ही ढेर में बहुत सारी मेमोरी उपलब्ध हो, फिर भी आप स्मृति से बाहर निकलने के कारण थ्रेड स्टैक बनाने में विफल हो सकते हैं (या पते से बाहर निकलने के कारण अंतरिक्ष, टॉम Hawtin सही ढंग से बताता है)।
ठीक है, मैं वर्चुअल वीएम के साथ पता लगाऊंगा और पता लगाने की कोशिश करूँगा कि स्टैक स्पेस को बदलने की जरूरत है या नहीं। मेरा अनुमान है कि यह नहीं होगा। – djangofan
एक प्रक्रिया में एन धागे हैं, और प्रत्येक थ्रेड स्टैक के लिए स्मृति के एम बाइट आवंटित किए जाते हैं। स्टैक उपयोग के लिए आवंटित कुल मेमोरी एन एक्स एम
आप थ्रेड (एन) की संख्या को कम करके या प्रत्येक थ्रेड (एम) के लिए आवंटित स्मृति को कम करके स्टैक द्वारा खपत कुल स्मृति को कम कर सकते हैं।
अक्सर एक धागा सभी ढेर का उपयोग नहीं करेगा। यह पूर्व-आवंटित "मामले में" की आवश्यकता होगी, लेकिन यदि थ्रेड गहरे कॉल पथ का उपयोग नहीं करता है, या रिकर्सन का उपयोग नहीं करता है, तो उसे इसकी ओर से आवंटित सभी स्टैक स्पेस की आवश्यकता नहीं हो सकती है।
इष्टतम स्टैक आकार ढूंढना एक कला हो सकता है।
32-बिट JVMs पर समस्या मौजूद है पता स्थान समाप्त हो सकता है। अधिकतम स्टैक आकार को कम करने से आम तौर पर आवंटित स्मृति की मात्रा कम नहीं होगी। 2k के 1k के ढेर के लिए आरक्षित 256 केबी के साथ 8k धागे पर विचार करें, यह वहां 31 स्थान की पता स्थान (2 जीबी) है।
समस्या सभी 64-बिट जेवीएम के साथ गायब हो जाती है (हालांकि स्मृति की वास्तविक मात्रा थोड़ी बढ़ जाएगी क्योंकि संदर्भ दो गुना बड़ा है)। वैकल्पिक रूप से, गैर-अवरुद्ध एपीआई का उपयोग काफी सारे धागे की आवश्यकता को हटा सकता है।
हॉटस्पॉट 6u14 में पेश किए गए संपीड़ित ऑब्जेक्ट पॉइंटर्स इसे कम करने में मदद करते हैं। http: //wikis.sun।com/प्रदर्शन/HotSpotInternals/CompressedOops –
थ्रेड स्टैक आकार को बदलने की कोशिश करने से पहले मैं अन्य चीजों (जैसे उत्तरजीवी अनुपात या कक्षा परिभाषाओं के लिए आवंटित स्थान के आकार को बदलने) की कोशिश करता हूं। यह यह सही है, इस प्रकार बहुत ही आसान एक ढेर अतिप्रवाह त्रुटि प्राप्त करने के लिए प्राप्त करने के लिए कठिन है (जो स्मृति त्रुटि के बाहर एक के रूप में समान रूप से घातक है।)
मैं सावधान परीक्षा के बाद भी यह अधिकार मिल गया कभी नहीं किया है। लेकिन फिर, मुझे कभी भी एक वेब एप्लिकेशन/कंटेनर संयोजन का सामना नहीं करना पड़ेगा जिसे इसके थ्रेड स्टैक आकार को बदलकर जुर्माना लगाया जा सकता है। मेरे पास उत्तरजीवी अनुपात को संशोधित करने के लिए बहुत बेहतर (और गैर-घातक) परिणाम हैं। लेकिन यह मेरा कार्य अनुभव रहा है। विभिन्न कार्यस्थलों और अनुप्रयोगों में, वाईएमएमवी।
क्योंकि स्टैक पर कम डेटा होगा? – Tedil