जावा हीप आकार को झुकाव, जावा के बीच स्थानीय अंतर और जावा वेब के बीच बड़ा अंतर

Question

मेरे पास पिछले सप्ताह के अंत में एक ग्राहक का फोन था, जिसमें मुझे बताया गया था कि डेटा का आयात करते समय उनका जावा प्रोग्राम प्रतिसाद नहीं दे रहा था। डेटा 4 वर्कशीट्स के साथ एक साधारण एक्सेल वर्कबुक है। सभी डेटा कॉलम से पढ़ा जा रहा है और डेटाबेस में जोड़ा गया है।

तो मैंने जांच शुरू कर दी और कुछ अजीब परिणाम हुए।

1. नेटबीन्स में रन का उपयोग करके आयात का परीक्षण करना।

फर्स्ट रन

दूसरा रन

1. : यह जावा 64-बिट उदाहरण का उपयोग करता है परीक्षण जावा वेब शुरू करने का उपयोग करके आयात। यह एक JNLP फ़ाइल खोलने द्वारा शुरू की जा रही है और एक जावा 32-बिट उदाहरण का उपयोग करता है: इस मामले में

फर्स्ट रन

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

दूसरा रन

तो मैं प्रारंभिक ढेर आकार और अधिकतम ढेर आकार मेरी JNLP फ़ाइल में निम्न जोड़कर बढ़ाने के लिए तय कर लिया है: initial-heap-size="512m" max-heap-size="1024m"। जब मैं आयात का पुन: परीक्षण किया है, यह काम करने के लिए लग रहा था, लेकिन मैं नोटिस भी बहुत कुछ इस्तेमाल किया स्मृति पहले 2 मामलों की तुलना में है:

• क्यों मामले के बीच स्मृति के उपयोग में एक 300MB का अंतर है मामले 4 की तुलना में 1 और 2?
• क्या यह उच्च स्मृति उपयोग खराब प्रोग्रामिंग या स्मृति रिसाव का परिणाम है? या क्या ऐसे उच्च मूल्य होने के लिए सामान्य है?
• initial-heap-size="512m" max-heap-size="1024m" इस मुद्दे के लिए एक वैध समाधान जोड़ रहा है?

Answer 1

ठीक है, स्पष्ट अंतर है कि आपका पहला रन एक 64-bit server VM के साथ किया जाता है और बाद वाले एक 32-bit client VM के साथ किया जाता है।

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

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