Go में स्टैक या हीप: struct का आवंटन GC को कैसे प्रभावित करता है

परिचय: 'सिर्फ struct' इतना सरल क्यों नहीं है?

क्या आपने कभी Go में प्रोग्राम लिखा है और अपने प्रोग्राम को देखते हुए सोचा है: 'मेरी संरचना (struct) अभी कहाँ रह रही है? तेज़ और आरामदायक स्टैक पर या कचरा संग्रहकर्ता की निगरानी में हीप के विशाल विस्तार में?' यह सवाल न केवल शुरुआती लोगों को परेशान करता है। Stack Overflow पर 'Go में structs का स्टैक बनाम हीप आवंटन, और वे कचरा संग्रह से कैसे संबंधित हैं' विषय ने हज़ारों व्यूज़ प्राप्त किए हैं। और यह कोई संयोग नहीं है।

Go की स्पष्ट सरलता एक शक्तिशाली तंत्र छिपाती है — escape analysis। यह एक कंपाइलर जासूस है जो प्रत्येक ऑब्जेक्ट के भाग्य का फैसला करता है। इसके निर्णय पर आपके एप्लिकेशन का प्रदर्शन और GC (Garbage Collector) पर लोड निर्भर करता है। इस चरण-दर-चरण ट्यूटोरियल में, हम जासूस की टोपी पहनेंगे और समझेंगे:

\n
• एक struct स्टैक पर क्यों रहता है और दूसरा हीप में क्यों?
\n
• पॉइंटर्स और क्लोज़र्स स्टैक की शांति को कैसे तोड़ते हैं।
\n
• यह ज्ञान आपको Go में तेज़ और कुशल कोड लिखने में कैसे मदद करेगा।
\n

स्टैक बनाम हीप: संक्षिप्त जानकारी

कोड में गोता लगाने से पहले, आइए सिद्धांत को ताज़ा करें। चिंता न करें, यह तेज़ और दर्दनाक होगा।

स्टैक (Stack)

\n
• गति: बिजली की तेज़। मेमोरी आवंटन केवल पॉइंटर को नीचे ले जाना है।
\n
• जीवन चक्र: फ़ंक्शन कॉल से सख्ती से बंधा हुआ। जब तक फ़ंक्शन काम करता है, तब तक जीवित रहता है।
\n
• प्रबंधन: स्वचालित। फ़ंक्शन से बाहर निकलने पर 'जल जाता है'।
\n
• आकार: प्रति goroutine छोटा और निश्चित (आमतौर पर 2-4 KB)।
\n

हीप (Heap)

\n
• गति: धीमी। मेमोरी का खाली ब्लॉक खोजने की आवश्यकता होती है।
\n
• जीवन चक्र: जब तक प्रोग्राम से ऑब्जेक्ट पर संदर्भ हैं। यह इसे बनाने वाले फ़ंक्शन से अधिक जीवित रह सकता है।
\n
• प्रबंधन: कचरा संग्रहकर्ता (GC)। यह हीप को स्कैन करता है, 'मृत' ऑब्जेक्ट ढूंढता है और मेमोरी मुक्त करता है। इसकी CPU संसाधनों की कीमत होती है।
\n
• आकार: बड़ा (केवल OS मेमोरी द्वारा सीमित)।
\n

Go का सुनहरा नियम: 'डेटा को जितना हो सके स्टैक पर रखें'। इससे GC पर लोड कम होता है और प्रोग्राम तेज़ होता है।

Escape Analysis: Go का मुख्य जासूस

Go में, आप ऑब्जेक्ट को कहाँ रखना है यह स्पष्ट रूप से बताने के लिए new या malloc नहीं लिखते हैं। कंपाइलर आपके लिए यह निर्णय स्वयं लेता है। इस प्रक्रिया को escape analysis (पलायन विश्लेषण) कहा जाता है।

यह आपके कोड को देखता है और एक प्रश्न पूछता है: 'क्या इस ऑब्जेक्ट का संदर्भ वर्तमान फ़ंक्शन छोड़ सकता है?'।

\n
• यदि नहीं (ऑब्जेक्ट पलायन नहीं करता) → ऑब्जेक्ट स्टैक पर रखा जाता है।
\n
• यदि हाँ (ऑब्जेक्ट पलायन करता है) → ऑब्जेक्ट हीप में रखा जाता है।
\n

आइए इसे क्रिया में देखें।

उदाहरण 1: स्टैक पर सुरक्षित संरचना

package main\n\nimport "fmt"\n\ntype Point struct {\n    X, Y int\n}\n\n// createPoint एक Point बनाता है और इसे मान द्वारा लौटाता है।\nfunc createPoint(x, y int) Point {\n    p := Point{X: x, Y: y}\n    return p // वापसी पर p कॉपी हो जाता है\n}\n\nfunc main() {\n    p1 := createPoint(10, 20)\n    fmt.Println(p1)\n}\n

इस उदाहरण में, p एक स्थानीय चर है। यह createPoint के अंदर बनाया गया है और मान द्वारा लौटाया गया है (कॉपी किया गया है)। struct p स्वयं फ़ंक्शन के बाहर उपयोग नहीं किया जा सकता है (इसकी कॉपी main में उपयोग की जाती है)। Escape analysis इसे देखता है और खुशी-खुशी p को स्टैक पर रखता है। GC आराम करता है।

उदाहरण 2: पॉइंटर के माध्यम से पलायन

अब केवल एक पंक्ति बदलते हैं — पॉइंटर लौटाते हैं।

package main\n\nimport "fmt"\n\ntype Point struct {\n    X, Y int\n}\n\n// createPointer एक Point बनाता है और उस पर पॉइंटर लौटाता है।\nfunc createPointer(x, y int) *Point {\n    p := P