Kotlin में मेमोरी प्रबंधन: गार्बेज कलेक्टर कैसे काम करता है

Kotlin में मेमोरी और गार्बेज कलेक्टर: RAM कैसे न गंवाएं और प्रदर्शन कैसे न खोएं

क्या आपने कभी सोचा है कि आपके Kotlin एप्लिकेशन की रैम कहाँ गायब हो जाती है? कोड तो बिल्कुल सही लिखा है, कोरूटीन उड़ रहे हैं, लेकिन एक घंटे के काम के बाद प्रोग्राम 'लैग' करने लगता है या OutOfMemoryError के साथ क्रैश हो जाता है। परिचित दर्द? उन लोगों के क्लब में आपका स्वागत है जो यह समझना चाहते हैं कि Kotlin मेमोरी का प्रबंधन कैसे करता है और गार्बेज कलेक्टर बुराई नहीं, बल्कि आपका सबसे अच्छा दोस्त क्यों है (अगर आप जानते हैं कि उससे दोस्ती कैसे करनी है)।

इस लेख में हम Kotlin में मेमोरी प्रबंधन के विषय में गहराई से उतरेंगे और जानेंगे कि विभिन्न प्लेटफॉर्म पर Kotlin में गार्बेज कलेक्टर कैसे काम करता है। आप जानेंगे कि स्टैक और हीप क्या हैं, मेमोरी लीक से कैसे बचें, और क्यों WeakReference आपके प्रोजेक्ट को बचा सकता है। चलिए शुरू करते हैं!

Kotlin में मेमोरी क्या है? स्टैक, हीप और उनके दोस्त

Kotlin एक मल्टी-प्लेटफ़ॉर्म भाषा है। यह JVM बाइटकोड, नेटिव कोड (Kotlin/Native के माध्यम से) या JavaScript (Kotlin/JS) में कंपाइल होती है। और प्रत्येक प्लेटफ़ॉर्म पर मेमोरी थोड़ी अलग तरह से व्यवस्थित होती है, लेकिन आधार हर जगह समान है।

आइए मूल बातें याद करें। जब आपका प्रोग्राम चलता है, तो ऑपरेटिंग सिस्टम उसे मेमोरी का एक क्षेत्र आवंटित करता है। इस क्षेत्र के अंदर दो मुख्य 'क्षेत्र' होते हैं:

\n
• स्टैक (Stack) — यहाँ स्थानीय चर, प्रिमिटिव और ऑब्जेक्ट्स के संदर्भ संग्रहीत होते हैं। यह प्लेटों के ढेर की तरह काम करता है: तेज़, पूर्वानुमानित, लेकिन सीमित आकार के साथ। स्टैक की सीमा से बाहर जाने पर StackOverflowError आता है।
\n
• हीप (Heap) — उन सभी ऑब्जेक्ट्स के लिए डंपिंग ग्राउंड जिन्हें आप new या कंस्ट्रक्टर (val list = mutableListOf()) के माध्यम से बनाते हैं। हीप बड़ा होता है, लेकिन धीमा होता है, और यहीं पर Kotlin गार्बेज कलेक्टर 'रहता' है।
\n

JVM पर स्टैक और हीप क्लासिक रूप से काम करते हैं। Kotlin/Native में स्टैक थ्रेड का नेटिव स्टैक है, और हीप अपने स्वयं के गार्बेज कलेक्टर द्वारा प्रबंधित किया जाता है। Kotlin/JS में — सब कुछ JavaScript-इंजन (V8, SpiderMonkey) के कंधों पर आ जाता है।

मुख्य बिंदु: ऑब्जेक्ट्स के संदर्भ स्टैक में संग्रहीत होते हैं, जबकि ऑब्जेक्ट्स स्वयं हीप में होते हैं। जब तक किसी ऑब्जेक्ट पर कम से कम एक 'जीवित' संदर्भ (स्टैक या किसी अन्य ऑब्जेक्ट से) है, तब तक गार्बेज कलेक्टर उसे नहीं छुएगा।

Kotlin में गार्बेज कलेक्टर: यह JVM पर कैसे काम करता है

जब आप JVM (Android, सर्वर) के तहत Kotlin में लिखते हैं, तो आपको Java Virtual Machine Garbage Collector (GC) की शक्ति मिलती है। यह Kotlin के लिए कुछ विशिष्ट नहीं है, लेकिन इसकी यांत्रिकी को समझना आवश्यक है।

आधुनिक JVM G1GC (Garbage First) या ZGC (नए संस्करणों में) का उपयोग करता है। यह सरलीकृत रूप से कैसे काम करता है:

\n
1. Mark (मार्किंग) — GC रूट पॉइंट्स (स्टैक, स्टैटिक फील्ड) से शुरू करके सभी जीवित ऑब्जेक्ट्स पर 'चलता' है। जहाँ तक वह पहुँचता है, वह जीवित है।
\n
2. Sweep (सफाई) — जो कुछ भी चिह्नित नहीं किया गया है, उसे कचरा माना जाता है और हटा दिया जाता है।
\n
3. Compact (कॉम्पैक्टीकरण) — जीवित ऑब्जेक्ट्स को स्थानांतरित किया जाता है ताकि विखंडन न हो।
\n

G1GC में हीप को क्षेत्रों में विभाजित किया गया है। GC उन क्षेत्रों को इकट्ठा करता है जहाँ सबसे अधिक कचरा है (इसलिए नाम)। यह ठहराव को कम करता है, लेकिन उन्हें पूरी तरह से समाप्त नहीं करता है।

Kotlin में आप JVM फ़्लैग्स (सर्वर के लिए) या GarbageCollectorMXBean (निगरानी के लिए) के माध्यम से गार्बेज कलेक्टर को प्रभावित कर सकते हैं। लेकिन अक्सर, आपको बस ऐसा कोड लिखने की आवश्यकता होती है जो GC के काम में बाधा न डाले।

उदाहरण: GC आपके कोड को कैसे देखता है

fun processData() {\n    val list = mutableListOf<String>()\n    for (i in 1..100_000) {\n        list.add("Element $i")\n    }\n    // यहाँ list जीवित है, जब तक मेथड समाप्त नहीं हो जाती\n    println(list.size)\n    // मेथड से बाहर निकलने के बाद list कचरा बन जाता है\n}\n

processData() के पूरा होने के बाद, list का संदर्भ स्टैक से गायब हो जाता है, और ऑब्जेक्ट संग्रह के लिए उम्मीदवार बन जाता है। सरल है, है ना?

Kotlin/Native की विशेषताएं: बिना JVM के गार्बेज कलेक्टर

Ko