عند تطوير التطبيقات باستخدام Golang، فإن إحدى التحديات الشائعة التي تواجهها هي إدارة الذاكرة. يستخدم Golang موقعين أساسيين لتخزين الذاكرة: المكدس والكومة. يعد فهم متى يتم تخصيص متغير للكومة مقابل المكدس أمرًا بالغ الأهمية لتحسين أداء التطبيقات التي نبنيها. في هذه المقالة، سوف نستكشف الشروط الأساسية التي تتسبب في تخصيص متغير إلى الكومة ونقدم مفهوم تحليل الهروب، الذي يستخدمه مترجم Go لتحديد تخصيص الذاكرة.

ليرة تركية؛ د

في Golang، يمكن تخصيص المتغيرات على الكومة أو المكدس. يحدث تخصيص الكومة عندما يحتاج المتغير إلى تجاوز نطاق الوظيفة أو كائن أكبر. يستخدم Go تحليل الهروب لتحديد ما إذا كان يجب تخصيص متغير في الكومة.

يحدث تخصيص الكومة في السيناريوهات التالية:

1. المتغيرات "تهرب" من الوظيفة أو النطاق.
2. يتم تخزين المتغيرات في مواقع ذات دورات حياة أطول، مثل المتغيرات العالمية.
3. يتم وضع المتغيرات في بنيات مستخدمة خارج الوظيفة.
4. يتم تخصيص كائنات كبيرة في الكومة لتجنب استخدام مكدس كبير.
5. عمليات الإغلاق التي تخزن المراجع للمتغيرات المحلية تؤدي إلى تخصيص الكومة.
6. عندما يتم تحويل المتغيرات إلى واجهة، يحدث تخصيص الكومة غالبًا.

تخصيص الكومة أبطأ لأن الذاكرة تتم إدارتها بواسطة أداة تجميع البيانات المهملة (GC)، لذلك من الضروري تقليل استخدامها.

ما هي المكدس والكومة؟

قبل الغوص في الموضوع الرئيسي، دعونا أولاً نفهم الاختلافات بين المكدس والكومة.

• المكدس: يتم استخدام ذاكرة المكدس لتخزين المتغيرات المحلية من وظيفة أو goroutine. تعمل المكدس بطريقة الوارد أخيرًا يخرج أولاً (LIFO)، حيث تكون البيانات الأحدث هي أول البيانات التي تتم إزالتها. المتغيرات المخصصة على المكدس تبقى حية فقط طالما أن الوظيفة قيد التنفيذ ويتم إزالتها تلقائيًا عندما تخرج الوظيفة من نطاقها. التخصيص وإلغاء التخصيص على المكدس سريعان جدًا، لكن حجم المكدس محدود.
• الكومة: يتم استخدام ذاكرة الكومة لتخزين الكائنات أو المتغيرات التي يجب أن تستمر بعد دورة حياة الوظيفة. على عكس المكدس، لا تتبع الكومة نمط LIFO وتتم إدارتها بواسطة أداة تجميع البيانات المهملة (GC)، التي تقوم بشكل دوري بتنظيف الذاكرة غير المستخدمة. في حين أن الكومة أكثر مرونة للتخزين على المدى الطويل، فإن الوصول إلى ذاكرة الكومة يكون أبطأ ويتطلب إدارة إضافية بواسطة GC.

ما هو تحليل الهروب؟

تحليل الهروب هو عملية يتم إجراؤها بواسطة برنامج التحويل البرمجي Go لتحديد ما إذا كان يمكن تخصيص متغير على المكدس أو يجب نقله إلى الكومة. إذا "هرب" متغير من الوظيفة أو النطاق، فسيتم تخصيصه في الكومة. على العكس من ذلك، إذا ظل المتغير ضمن نطاق الوظيفة، فيمكن تخزينه على المكدس.

متى يتم تخصيص المتغير إلى الكومة؟

تتسبب عدة شروط في تخصيص المتغيرات على الكومة. دعونا نناقش كل موقف.

1. عندما "يهرب" المتغير من وظيفة أو نطاق

يحدث تخصيص الكومة عندما يتم الإعلان عن متغير داخل دالة، ولكن مرجعه يفلت من الدالة. على سبيل المثال، عندما نعيد مؤشرًا إلى متغير محلي من دالة، فسيتم تخصيص هذا المتغير في الكومة.

على سبيل المثال:

func newInt() *int {
    x := 42
    return &x // "x" is allocated on the heap because a pointer is returned
}

في هذا المثال، يجب أن يظل المتغير x حيًا بعد انتهاء الدالة newInt()، لذا يخصص Go x على الكومة.

2. عندما يتم تخزين المتغير في مكان أطول عمرًا

إذا تم تخزين متغير في موقع بدورة حياة أطول من النطاق الذي تم الإعلان عن المتغير فيه، فسيتم تخصيصه في الكومة. المثال الكلاسيكي هو عندما يتم تخزين إشارة إلى متغير محلي في متغير عام أو بنية تعيش لفترة أطول. على سبيل المثال:

var global *int

func setGlobal() {
    x := 100
    global = &x // "x" is allocated on the heap because it's stored in a global variable
}

هنا، يحتاج المتغير x إلى البقاء خارج وظيفة setGlobal()، لذلك يجب تخصيصه في الكومة. وبالمثل، عندما يتم وضع متغير محلي في بنية مستخدمة خارج الوظيفة التي تم إنشاؤها فيها، سيتم تخصيص هذا المتغير في الكومة. على سبيل المثال:

type Node struct {
    value *int
}

func createNode() *Node {
    x := 50
    return &Node{value: &x} // "x" must be on the heap because it's stored in Node
}

في هذا المثال، بما أن x مخزنة في العقدة ويتم إرجاعها من الوظيفة، فيجب أن تظل x أطول من عمر الوظيفة، وبالتالي يتم تخصيصها في الكومة.

3. للأشياء الكبيرة

في بعض الأحيان، يكون تخصيص الكومة ضروريًا للكائنات الكبيرة، مثل المصفوفات أو الشرائح الكبيرة، حتى لو لم "تفلت" الكائنات. يتم ذلك لتجنب استخدام مساحة كبيرة جدًا. على سبيل المثال:

func largeSlice() []int {
    return make([]int, 1000000) // Heap allocation due to large size
}

سوف يستخدم Golang الكومة لتخزين هذه الشريحة الكبيرة لأن حجمها كبير جدًا بالنسبة للمكدس.

4. عمليات الإغلاق التي تخزن المراجع للمتغيرات المحلية

غالبًا ما تؤدي عمليات الإغلاق في Golang إلى تخصيص الكومة إذا كان الإغلاق يحتوي على إشارة إلى متغير محلي في الوظيفة حيث تم تعريف الإغلاق. على سبيل المثال:

func createClosure() func() int {
    x := 10
    return func() int { return x } // "x" must be on the heap because it's used by the closure
}

بما أن وظيفة الإغلاق func() int تحتوي على إشارة إلى x، فيجب تخصيص x على الكومة لضمان بقائها على قيد الحياة بعد انتهاء وظيفة createClosure().

5. الواجهات والإرسال الديناميكي

عند إرسال المتغيرات إلى واجهة ما، قد يحتاج Go إلى تخزين النوع الديناميكي للمتغير في الكومة. يحدث هذا لأنه يجب تخزين المعلومات المتعلقة بنوع المتغير بجانب قيمته. على سبيل المثال:

func asInterface() interface{} {
    x := 42
    return x // Heap allocation because the variable is cast to interface{}
}

في هذه الحالة، سيقوم Go بتخصيص x على الكومة لضمان توفر معلومات النوع الديناميكي.

العوامل الأخرى التي تسبب تخصيص الكومة

بالإضافة إلى الشروط المذكورة أعلاه، هناك العديد من العوامل الأخرى التي قد تتسبب في تخصيص المتغيرات على الكومة:

1. الجوروتين

غالبًا ما يتم تخصيص المتغيرات المستخدمة داخل goroutines على الكومة لأن دورة حياة goroutine يمكن أن تمتد إلى ما هو أبعد من الوظيفة التي تم إنشاؤها فيها.

2. المتغيرات التي يديرها جامع البيانات المهملة (GC)

إذا اكتشف Go أن هناك متغيرًا يحتاج إلى إدارته بواسطة Garbage Collector (GC) (على سبيل المثال، لأنه يستخدم عبر goroutines أو يحتوي على مراجع معقدة)، فقد يتم تخصيص هذا المتغير في الكومة.

خاتمة

يعد فهم متى ولماذا يتم تخصيص متغير على الكومة أمر بالغ الأهمية لتحسين أداء تطبيقات Go. يلعب تحليل الهروب دورًا رئيسيًا في تحديد ما إذا كان يمكن تخصيص متغير على المكدس أو يجب تخصيصه على الكومة. بينما توفر الكومة مرونة لتخزين الكائنات التي تحتاج إلى عمر أطول، فإن الاستخدام المفرط للكومة يمكن أن يزيد من عبء العمل على Garbage Collector ويبطئ أداء التطبيق. باتباع هذه الإرشادات، يمكنك إدارة الذاكرة بشكل أكثر كفاءة والتأكد من تشغيل التطبيق الخاص بك بأداء مثالي.

إذا كان هناك أي شيء تعتقد أنني فاتني أو إذا كان لديك خبرة إضافية ونصائح تتعلق بإدارة الذاكرة في Go، فلا تتردد في مشاركتها في التعليقات أدناه. يمكن أن تساعدنا المزيد من المناقشة جميعًا على فهم هذا الموضوع بشكل أفضل ومواصلة تطوير ممارسات ترميز أكثر كفاءة.