هل تم جمع القمامة المكدسة في جافا؟

Question

ذاكرة الكومة هي عبارة عن بيانات مجمعة في Java.

هل يتم جمع القمامة المكدسة أيضًا؟

كيف يتم استعادة الذاكرة المكدسة؟

Answer 1

تحتوي الذاكرة الموجودة على المكدس على معلمات أسلوب ومتغيرات محلية (تكون دقيقة: المراجع عن الكائنات والمتغيرات نفسها لأنواع بدائية). سيتم إزالتها تلقائيا إذا تركت الطريقة. إذا كانت المتغيرات هي المراجع (إلى الكائنات) الكائنات نفسها على كومة الكومة ومعالجتها بواسطة جامع القمامة.

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

أ يتم إعطاء إجابة أكثر تفصيلا بواسطة Thomas Pornin, ، انظر إلى ذلك لمزيد من التفاصيل.

Answer 2

المكدس ليس القمامة التي تم جمعها في جافا.

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

مكان واحد حيث يتفاعل مجموعة المكدس والقمامة هو أن المراجع الموجودة على المكدس جذور GC (مما يعني أنهم مراجع الجذر التي يتم تحديدها للوصول إليها).

Answer 3

المدخنة يستطع كن القمامة التي تم جمعها. ومع ذلك، في معظم تطبيقات JVM، يتم التعامل معها كما، حسنا، "كومة"، والتي بحكم تعريف تحول إلى مجموعة القمامة.

ما نسميه المكدس هو تراكم طريقة تنشيط طريقة: لكل طريقة مستدارة، هذا هو الهيكل المفاهيمي الذي يحتوي على وسيطات الأسلوب والمتغيرات المحلية ومؤشر مخفي إلى سياق طريقة الاتصال، وفتحة لحفظ مؤشر التعليمات. سياق التنشيط غير قابل للوصول على هذا النحو من لغة Java نفسها. سياق يصبح عديمة الفائدة عند خروج الطريقة (مع return أو بسبب استثناء ألقيت). يحدث ذلك حتى يتم إجراء طريقة استدعاء الأسلوب B، مضمون أنه عند التحكم في الاستجابة، أصبح السياق الخاص ب B عديمة الفائدة. هذا يعني أن عمر سياق السياق الخاص ب B هو مجال توعية من عمر السياق ل A. لذلك، يمكن تخصيص سياقات التنشيط (للحصول على مؤشر ترابط معين) مع الانضباط LIVO ("الأخير في، أولا خارج"). في كلمات أبسط، كومة: يتم دفع سياق تنشيط جديد أعلى كومة السياقات، والسياق في الأعلى سيكون أول من التخلص منه.

في الممارسة العملية، سياقات التنشيط (تسمى أيضا إطارات المكدس) متسلسلة، في ترتيب مكدس، في منطقة مخصصة. يتم الحصول على تلك المنطقة من نظام التشغيل عند بدء تشغيل الخيط، ويعود نظام التشغيل إلى الوراء عند إنهاء الخيط. يتم تعيين الجزء العلوي من المكدس من قبل مؤشر محدد، وغالبا ما يحتوي في سجل وحدة المعالجة المركزية (هذا يعتمد على ما إذا كان JVM يفسر أو تجميع التعليمات البرمجية). "مؤشر سياق المتصل" هو الظاهري؛ يقع سياق المتصل بالضرورة أدناه فقط في ترتيب المكدس. لا يتدخل GC: يتم إنشاء منطقة المكدس واستصلاحها بشكل متزامن، من نشاط الخيط نفسه. هذا هو أيضا كيف يعمل في العديد من اللغات مثل جيم, ، والتي ليس لديها GC على الإطلاق.

الآن لا يوجد شيء يمنع تنفيذ JVM من القيام بذلك بطريقة أخرى، مثل تخصيص سياقات التنشيط في الكومة ووجودها من قبل GC. لا يتم ذلك عادة في الأجهزة الظاهرية Java منذ تخصيص Stack أسرع. ولكن هناك بعض اللغات الأخرى تحتاج إلى القيام بهذه الأشياء، والأبراد هي تلك التي تلعب استمرار بينما لا يزال يستخدم GC (على سبيل المثال مخطط و call-with-current-continuation وظيفة)، لأن هذه الألعاب كسر قاعدة ليفو وأوضح أعلاه.

Answer 4

يعمل جزء المكدس من الذاكرة تماما مثل "المكدس". أعلم أنه يبدو سيئا، لكن هذا هو بالضبط كيف يعمل. تتم إضافة البيانات إلى الأعلى، على رأس بعضها البعض (pushed onto the stack) ثم تتم إزالتها تلقائيا من الأعلى (popped off the stack) كما يعمل البرنامج الخاص بك. لا يتم جمع القمامة - ولا يحتاج إلى أن يكون ذلك لأن هذه الذاكرة يتم استصلاحها تلقائيا بمجرد برز البيانات عن المكدس. وعندما أقول المستصلحة، لا أقصد أنه يتم تخصيصه - إنه فقط أن الموقع في ذاكرة المكدس حيث سيتم تخزين البيانات التالية، حيث يتم إيقاف تشغيل البيانات.

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

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

Answer 5

إذا قمت بالإشارة إلى الذاكرة المستخدمة في المكدس، فهي ليست مجمعة للقمامة.
يستخدم جهاز Java الظاهري تعليمات بايت كود صريحة لحجز الذاكرة وتحريرها على المكدس، ويتم إنشاء هذه التعليمات بواسطة المترجم وإدارة عمر الأوليات مثل مراجع int وboolean وdouble ومراجع الكائنات الموجودة على المكدس.
كانت هناك خطط لتنفيذ ما يسمى بتحسين الاستدعاء الخلفي، والذي من شأنه إزالة بعض الإدخالات من المكدس بمجرد معرفة أنها لم تعد مستخدمة، لكنني لا أعرف أي jvm يدعم هذا بالفعل.
لذلك لا توجد مجموعة من البيانات المهملة للمكدس نفسه، فقط المترجم هو الذي أنشأ تعليمات الدفع والبوب ​​لإدارة استخدام الذاكرة.

المكدس نفسه جزء من خيط.يتم تخصيص المكدس عند إنشاء كائن مؤشر الترابط وجمع البيانات المهملة بعد إنهاء مؤشر الترابط ولم يعد يتم الرجوع إلى كائن مؤشر الترابط.

Answer 6

يتم تخصيص جميع الكائنات الموجودة في جافا على كومة الكومة. (على الأقل بقدر ما يذهب المواصفات، قد يقوم التنفيذ الفعلي بتخصيصها على المكدس إذا تتصرف بشفافية كما لو كانت على كومة.)

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

هذا لا يهم عادة ما إذا كنت تستخدم نهائيا (أو يفترض Referenceس). في هذه الحالة يجب أن تكون حذرا واستخدام الأقفال / المتقلبة لفرض أ happens-before صلة.

عند توقف الخيوط، عادة ما يتم إلغاء تخصيص المكدس بأكمله.

Answer 7

يتم التعامل مع كل شيء يقع على المكدس كجذور عالمية بجامعة القمامة. لذلك، نعم، يمكنك بالتأكيد أن تقول أن المكدس "جمع القمامة".

Answer 8

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

Answer 9

لا. المكدس ليس القمامة التي تم جمعها في جافا. كل مؤشر ترابط له مكدس خاص به ويحتوي على:

1. طريقة محددة القيم (التي هي قصيرة العمر) و
2. يشير إلى الكائنات، التي تم إنشاؤها على كومة، ويتم إحالةها بواسطة الطريقة

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

وبالتالي، يتم تنظيف البيانات في كومة تلقائيا بمجرد أن يخرج الطريقة / البرنامج من النطاق.