🧑🏾 👹 💩 जावा ऑब्जेक्ट का आकार। हम अर्जित ज्ञान का उपयोग करते हैं 🎨 👃 😆

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

निरूपण मॉडल

तो आइए निम्नलिखित कोड देखें:

class Cursor { String icon; Position pos; Cursor(String icon, int x, int y) { this.icon = icon; this.pos = new Position(x, y); } } class Position { int x; int y; Position(int x, int y) { this.x = x; this.y = y; } }

आइए अब निरूपित करें:

 class Cursor2 { String icon; int x; int y; Cursor2(String icon, int x, int y) { this.icon = icon; this.x = x; this.y = y; } }

ऐसा लगता है - रचना और सभी से छुटकारा पा लिया। लेकिन नहीं। वर्ग Cursor2 की एक वस्तु वर्ग Cursor (अनिवार्य रूप से Cursor + स्थिति) की एक वस्तु की तुलना में लगभग 30% कम मेमोरी खाती है। यह अपघटन का स्पष्ट परिणाम नहीं है। लिंक और अतिरिक्त ऑब्जेक्ट के हेडर के कारण। शायद यह महत्वपूर्ण और मजाकिया नहीं लगता है, लेकिन जब तक आपके पास कुछ वस्तुएं हैं, और जब बिल लाखों में जाता है, तो स्थिति नाटकीय रूप से बदल जाती है। यह 100 क्षेत्रों की विशाल कक्षाएं बनाने के लिए एक कॉल नहीं है। किसी भी तरह से नहीं। यह तभी उपयोगी हो सकता है जब आप अपनी रैम की ऊपरी सीमा के करीब आते हैं और आपकी मेमोरी में एक ही प्रकार की कई वस्तुएं होती हैं।

हम अपने लाभ के लिए ऑफसेट का उपयोग करते हैं

मान लें कि हमारे पास 2 कक्षाएं हैं:

 class A { int a; } class B { int a; int b; }

क्लास ए और बी ऑब्जेक्ट्स समान मात्रा में मेमोरी का उपभोग करते हैं। यहां आप एक ही बार में 3 निष्कर्ष निकाल सकते हैं:

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

आदिम और शैल

मैं एक बार फिर दोहराता हूं। लेकिन अगर आपकी कक्षा में क्षेत्र को मूल मानों को सुरक्षित रूप से उपयोग करने के लिए शून्य मानों को स्वीकार नहीं करना चाहिए या नहीं करना चाहिए। क्योंकि बहुत बार कुछ ऐसा होता है:

 class A { @NotNull private Boolean isNew; @NotNull private Integer year; }

याद रखें, औसतन प्राइमेटरी 4 गुना कम मेमोरी लेती है। एक इंटजर फ़ील्ड को एक इंट के साथ बदलने से प्रति ऑब्जेक्ट 16 बाइट्स मेमोरी बच जाएगी। और एक लॉन्ग को 20 बाइट्स से बदलना है। कचरा उठाने वाले पर भार भी कम हो जाता है। सामान्य तौर पर, बहुत सारे फायदे। एकमात्र मूल्य शून्य मानों की कमी है। और फिर, कुछ स्थितियों में, यदि स्मृति वास्तव में आवश्यक है, तो आप कुछ मानों को अशक्त मानों के रूप में उपयोग कर सकते हैं। लेकिन यह अतिरिक्त हो सकता है। आवेदन तर्क को संशोधित करने की लागत।

बूलियन और बूलियन

मैं इन दो प्रकारों में से एकल करना चाहूंगा। बात यह है कि ये जावा में सबसे रहस्यमय प्रकार हैं। चूंकि उनका आकार विनिर्देश द्वारा परिभाषित नहीं है, इसलिए तार्किक प्रकार का आकार पूरी तरह से आपके जेवीएम पर निर्भर करता है। ओरेकल हॉटस्पॉट जेवीएम के रूप में, उन सभी में तार्किक प्रकार के लिए 4 बाइट्स आवंटित किए गए हैं, अर्थात, उदाहरण के लिए। 1 बिट जानकारी के भंडारण के लिए आप बूलियन के मामले में 31 बिट का भुगतान करते हैं। यदि हम बूलियन सरणी के बारे में बात करते हैं, तो अधिकांश कंपाइलर किसी प्रकार का अनुकूलन करते हैं, और इस मामले में, बूलियन प्रति मूल्य बाइट पर कब्जा करेगा (अच्छी तरह से, बिटसेट के बारे में मत भूलना)।
और अंत में - बुलियन प्रकार का उपयोग न करें। मेरे लिए एक ऐसी स्थिति के साथ आना कठिन है जहाँ इसकी वास्तव में आवश्यकता हो सकती है। यह स्मृति के दृष्टिकोण से बहुत सस्ता है और व्यापार तर्क के दृष्टिकोण से आसान है कि एक आदिम का उपयोग करें जो 2 संभावित मान लेगा, और 3 नहीं, जैसा कि बूलियन में है।

सीरियलाइज़ेशन और डिसेरिएलाइज़ेशन

मान लीजिए कि आपके पास क्रमबद्ध एप्लिकेशन मॉडल है और यह डिस्क पर 1 जीबी लेता है। और आपका कार्य इस मॉडल को स्मृति में पुनर्स्थापित करना है - बस इसे डिसेर्बलाइज करें। आपको इस तथ्य के लिए तैयार रहना चाहिए कि मॉडल की संरचना के आधार पर, स्मृति में यह 2GB से 5GB तक होगा। हाँ, हाँ, सभी एक ही हेडर, ऑफ़सेट और लिंक के कारण फिर से। इसलिए, संसाधन फ़ाइलों में बड़ी मात्रा में डेटा रखना कभी-कभी उपयोगी हो सकता है। लेकिन यह, निश्चित रूप से, स्थिति पर बहुत निर्भर है और यह हमेशा बाहर का रास्ता नहीं है, और कभी-कभी यह बस असंभव है।

आदेश मायने रखता है

मान लें कि हमारे पास दो एरेज़ हैं:

 Object[2][1000] Object[1000][2]

यह प्रतीत होता है - कोई अंतर नहीं। लेकिन वास्तव में ऐसा नहीं है ... स्मृति की खपत के दृष्टिकोण से, अंतर बहुत बड़ा है। पहले मामले में, हमारे पास हजारों तत्वों की एक सरणी के लिए 2 संदर्भ हैं। दूसरे मामले में, हमारे पास दो तत्वों के साथ सरणियों के लिए एक हजार संदर्भ हैं! दूसरे मामले में स्मृति के दृष्टिकोण से, खपत की गई मेमोरी की मात्रा 998 अधिक लिंक आकार है। और यह लगभग 7kb है। तो नीले रंग से बाहर आप बहुत सारी याददाश्त खो सकते हैं।

लिंक संपीड़न

स्मृति को कम करने का एक अवसर है जो जावा ऑब्जेक्ट्स में लिंक, हेडिंग और ऑफ़सेट द्वारा उपयोग किया जाता है। बात यह है कि बहुत समय पहले जब 32-बिट आर्किटेक्चर से 64-बिट आर्किटेक्चर, कई प्रशासकों, और सिर्फ डेवलपर्स के लिए पलायन किया गया था, आभासी जावा मशीनों के प्रदर्शन में गिरावट देखी गई थी। इसके अलावा, प्रवासन के दौरान उनके अनुप्रयोगों द्वारा खपत की गई मेमोरी उनके व्यवसाय मॉडल की संरचना के आधार पर 20-50% तक बढ़ जाती है। जो, ज़ाहिर है, लेकिन उन्हें परेशान नहीं कर सकता था। प्रवासन के कारण स्पष्ट हैं - अनुप्रयोग अब 32-बिट आर्किटेक्चर के उपलब्ध पते स्थान में फिट नहीं होंगे। कौन नहीं जानता है - 32-बिट सिस्टम में, एक मेमोरी सेल (1 बाइट) के लिए पॉइंटर का आकार 32 बिट लेता है। इसलिए, 32-बिट पॉइंटर्स का उपयोग करने वाली अधिकतम उपलब्ध मेमोरी 2 ^ 32 = 4294967296 बाइट्स या 4 जीबी है। लेकिन वास्तविक अनुप्रयोगों के लिए, 4 जीबी की मात्रा इस तथ्य के कारण उपलब्ध नहीं है कि पता स्थान का हिस्सा स्थापित परिधीय उपकरणों के लिए उपयोग किया जाता है, उदाहरण के लिए, एक वीडियो कार्ड।
जावा डेवलपर्स एक नुकसान में नहीं थे और लिंक संपीड़न जैसी कोई चीज थी। आमतौर पर जावा में लिंक का आकार देशी सिस्टम की तरह ही होता है। 64-बिट आर्किटेक्चर के लिए यह 64 बिट्स है। इसका मतलब है कि वास्तव में हम 2 ^ 64 ऑब्जेक्ट्स का उल्लेख कर सकते हैं। लेकिन इतनी बड़ी संख्या में संकेत अनावश्यक हैं। इसलिए, वर्चुअल मशीनों के डेवलपर्स ने लिंक के आकार को बचाने का फैसला किया और विकल्प -XX पेश किया: + UseCompressedOops। इस विकल्प ने पॉइंटर के आकार को 64-बिट जेवीएम में घटाकर 32 बिट कर दिया। यह हमें क्या देता है?

सभी ऑब्जेक्ट्स जिनके पास एक लिंक है अब प्रति लिंक 4 बाइट्स कम लेते हैं।
प्रत्येक वस्तु का शीर्षक 4 बाइट्स से घटाया जाता है।
कुछ स्थितियों में, कम संरेखण संभव हैं।
खपत की गई मेमोरी की मात्रा काफी कम हो जाती है।

लेकिन दो छोटे मीनू हैं:

संभव वस्तुओं की संख्या 2 ^ 32 में रहती है। इस आइटम को मुश्किल से माइनस कहा जा सकता है। सहमत, 4 बिलियन ऑब्जेक्ट बहुत, बहुत सारे हैं। और यह भी विचार करते हुए कि किसी वस्तु का न्यूनतम आकार 16 बाइट है ...
अतिरिक्त दिखाई देते हैं। जेवीएम लिंक को देशी और इसके विपरीत में परिवर्तित करने की लागत। यह संदिग्ध है कि ये लागतें कम से कम किसी तरह वास्तव में प्रदर्शन को प्रभावित कर सकती हैं, यह देखते हुए कि ये सचमुच 2 रजिस्टर ऑपरेशन हैं: शिफ्ट और समन। विवरण यहाँ पाया जा सकता है।

मुझे यकीन है कि आप में से कई के पास एक सवाल है, अगर UseCompressedOops विकल्प में बहुत सारे प्लस और लगभग कोई भी मिनीस नहीं है, तो इसे डिफ़ॉल्ट रूप से चालू क्यों नहीं किया जाता है? वास्तव में, JDK 6 अपडेट 23 से शुरू होकर यह डिफ़ॉल्ट रूप से सक्षम है, जैसे JDK 7 में। और यह पहली बार अपडेट 6p में दिखाई दिया।

निष्कर्ष

मुझे आशा है कि मैं आपको समझाने में कामयाब रहा। मुझे वास्तविक परियोजनाओं पर इनमें से कुछ चाल देखने का मौका मिला। और याद रखें, जैसा कि डोनाल्ड नुथ कहते थे, समयपूर्व अनुकूलन सभी बीमारियों की जड़ है।

जावा ऑब्जेक्ट का आकार। हम अर्जित ज्ञान का उपयोग करते हैं