هذا البرنامج التعليمي هو فهم مجموعة القمامة الأساسية Java وكيفية عملها. هذا هو الجزء الثاني من سلسلة Tutorial Collection Garbage. آمل أن تكون قد قرأت الجزء الأول: " مقدمة موجزة لآلية جمع القمامة Java ".
مجموعة Java Garbage هي عملية تلقائية تستخدم لإدارة ذاكرة وقت التشغيل المستخدمة من قبل البرامج. من خلال عملية الأتمتة هذه ، يزيل JVM النفقات العامة للمبرمجين لتخصيص موارد الذاكرة المجانية في البرنامج.
ابدأ مجموعة القمامة Java
كعملية تلقائية ، لا يحتاج المبرمجون إلى بدء عملية جمع القمامة المعروضة في الكود. يتم استخدام System.gc () و Runtime.gc () لطلب JVM لبدء مجموعة القمامة.
على الرغم من أن آلية الطلب هذه توفر للمبرمجين فرصة لبدء عملية GC ، فإن بدء التشغيل هو مسؤولية JVM. يمكن لـ JVM رفض هذا الطلب ، لذلك لا يوجد ضمان بأن كل هذه المكالمات ستقوم بجمع القمامة. يتم تحديد اختيار توقيت بدء التشغيل بواسطة JVM ويعتمد على ما إذا كانت منطقة عدن متاحة في ذاكرة الكومة. يترك JVM هذا الاختيار لتنفيذ مواصفات Java ، والخوارزميات المحددة المستخدمة من قبل التطبيقات المختلفة مختلفة.
وغني عن القول ، نحن نعلم أنه لا يمكن تطبيق عملية جمع القمامة. لقد وجدت للتو مشهدًا حيث يكون الاتصال system.gc () منطقيًا. من خلال هذه المقالة ، دعنا نتعرف على المواقف المتطرفة المناسبة للاتصال system.gc () .
عملية جمع القمامة جافا
مجموعة Garbage هي عملية استعادة مساحة ذاكرة عديمة الفائدة وجعلها متاحة للمثيلات المستقبلية.
منطقة عدن: عند إنشاء مثيل ، سيتم تخزينه أولاً في منطقة عدن من الجيل الشاب من ذاكرة الكومة.
ملاحظة: إذا لم تتمكن من فهم هذه الكلمات ، أقترح عليك قراءة هذه المقدمة في مجموعة Garbage ، والتي توفر مقدمة مفصلة لنماذج الذاكرة ، بنيات JVM ، وهذه المصطلحات.
مناطق الناجين (S0 و S1): كجزء من دورة GC (MinorGC) ، كجزء من GC (MinorGC) ، يتم نقل الكائن الباقي (الذي لا يزال يتم الإشارة إليه) من منطقة عدن إلى S0 من منطقة الناجين. وبالمثل ، يقوم جامع القمامة بمسح S0 وينقل الحالة الباقية إلى S1.
(ملاحظة المترجم: ألا ينتقل الأشخاص الباقون على قيد الحياة في عدن و S0 إلى S1؟ لماذا ينتقلون إلى S0 أولاً ثم من S0 إلى S1؟)
يتم وضع علامة على مثيل الوفاة (لم يعد يشار إليه) على أنه جمع القمامة. اعتمادًا على جامع القمامة (هناك أربعة جامعي للقمامة شائعة الاستخدام ، والتي سيتم وصفها في البرنامج التعليمي التالي) ، إما أن يتم إزالة الحالات الموسومة باستمرار من الذاكرة ، أو يتم الانتهاء من عملية إعادة التدوير في عملية منفصلة.
الجيل الأقدم: الجيل الأكبر هو المنطقة المنطقية الثانية في ذاكرة الكومة. عندما يقوم جامع القمامة بإجراء دورة MinorGC ، سيتم الترويج للمثال الباقي في منطقة S1Survivor إلى الشيخوخة ، بينما يتم إعادة تدوير الأشياء غير المرجعية على أنها معاد تدويرها.
Old GC (MajorGC): مقارنة بعملية جمع القمامة Java ، فإن GC Old هي المرحلة الأخيرة من دورة حياة المثيل. Majorgc يقوم بمسح عملية إعادة تدوير القمامة للمسنين. إذا لم تعد الحالات مُشير إليها ، فسيتم تمييزها على أنها معاد تدويرها ، وإلا فإنها ستستمر في البقاء في الشيخوخة.
Shard Memory Shard: بمجرد حذف المثيل من ذاكرة الكومة ، يصبح موقعه فارغًا ويمكن استخدامه لتخصيص مثيلات مستقبلية. هذه المساحات الحرة ستقوم بتجميع منطقة الذاكرة بأكملها. للتخصيص السريع للحالات ، يلزم إزالة التجزئة. استنادًا إلى الخيارات المختلفة لمجمع القمامة ، يتم فرز منطقة الذاكرة المعاد تدويرها أو إكمالها باستمرار في عملية GC منفصلة.
نهاية الحالات في مجموعة القمامة
قبل تحرير مثيل واستعادة مساحة الذاكرة ، يدعو جامع Java Garbage Collector طريقة وضع اللمسات الأخيرة على الحالة () ، بحيث تتاح للمثال الفرصة لتحرير الموارد التي يحتفظ بها. على الرغم من أنه من الضمان أن يتم استدعاء اللمسات الأخيرة () قبل استعادة مساحة الذاكرة ، لا يوجد أي ترتيب ووقت محددين. لا يمكن التنبؤ بالترتيب بين حالات متعددة وقد يحدث بالتوازي. لا ينبغي للبرامج تعديل الترتيب بين الحالات وموارد إعادة التدوير باستخدام طريقة اللمسات الأخيرة ().
سيتم تجاهل أي استثناءات لم يتم اكتشافها في عملية اللمسات الأخيرة تلقائيًا ، ويتم إلغاء عملية الانتهاء من المثيل.
لا تناقش مواصفات JVM آلية جمع القمامة للمراجع الضعيفة ، كما أنها لا تحتوي على متطلبات واضحة. يتم تحديد التنفيذ المحدد من قبل الطرف التنفيذي.
يتم جمع القمامة بواسطة خيط الخفي.
متى سيفي الكائن بظروف جمع القمامة؟
جميع الحالات ليس لها وصول نشط للموضوع.
مثيل مرجعي دائري لا يمكن الوصول إليه من قبل أي مثيل آخر.
هناك أنواع مرجعية مختلفة في جافا. تحديد ما إذا كان مثيل يفي بظروف جمع القمامة ، كلها تعتمد على نوع المرجع.
| النوع المرجعي | مجموعة القمامة |
|---|---|
| إشارة قوية | لا يتوافق مع جمع القمامة |
| مرجع ناعم | قد يتم تنفيذ مجموعة القمامة ، ولكن سيكون الملاذ الأخير |
| مرجع ضعيف | الامتثال لجمع القمامة |
| مرجع الوهمية | الامتثال لجمع القمامة |
كأسلوب تحسين أثناء عملية التجميع ، يمكن لمرجم Java اختيار تعيين قيم خالية إلى مثيلات ، وبالتالي وضع مثيل على أنه قابل لإعادة التدوير.
Class Animal {public static void main (string [] args) {Animal Lion = new Animal () ؛ System.out.println ("تم الانتهاء من Main.") ؛ } void المحمية اللمسات الأخيرة () {system.out.println ("REST in Peace!") ؛ }}في الفئة أعلاه ، لم يتم استخدام كائن الأسد بعد إنشاء الخط. لذلك ، كمقياس للتحسين ، يمكن لمجمول Java تعيين Lion = NULL مباشرة بعد إنشاء الصف. لذلك ، يمكن أن تطبع وظيفة اللمسات الأخيرة على "RestInpeace!" حتى قبل إخراج SOP. لا يمكننا إثبات أن هذا سيحدث لأنه يعتمد على كيفية تنفيذ JVM والذاكرة المستخدمة في وقت التشغيل. ومع ذلك ، يمكننا أن نتعلم واحدة أخرى: إذا رأى المترجم أن المثيل لن يتم الرجوع إليه أبدًا في المستقبل ، فيمكنه تحديد مساحة مثيل وتطبيقها في وقت مبكر.
هناك مثال أفضل على متى تتوافق الكائنات لجمع القمامة. يمكن تخزين جميع سمات المثيل في السجلات ، والتي سيتم الوصول إليها وقراءتها. بدون استثناء ، سيتم كتابة هذه القيم مرة أخرى إلى المثيل. على الرغم من أنه يمكن استخدام هذه القيم في المستقبل ، إلا أنه لا يزال من الممكن تمييز هذه الحالة على أنها متوافقة مع جمع القمامة. هذا مثال كلاسيكي للغاية ، أليس كذلك؟
هذا مثال بسيط للغاية يتوافق مع جمع القمامة عند تعيينه إلى NULL. بالطبع ، يمكن أن تكون المواقف المعقدة مثل النقاط المذكورة أعلاه. هذا هو الخيار الذي قام به تطبيق JVM. والغرض من ذلك هو ترك أصغر بصمة الذاكرة قدر الإمكان ، وتسريع سرعة الاستجابة ، وتحسين الإنتاجية. لتحقيق ذلك ، يمكن لمنفذي JVM اختيار حل أفضل أو خوارزمية لاستعادة مساحة الذاكرة أثناء عملية جمع القمامة.
عندما يتم استدعاء طريقة اللمسات الأخيرة () ، تقوم JVM بإطلاق جميع أقفال التزامن على الخيط.
برنامج عينة GCSCOPE
class gcscope {gcscope t ؛ static int i = 1 ؛ public static void main (string args []) {gcscope t1 = new gcscope () ؛ gcscope t2 = new gcscope () ؛ gcscope t3 = new gcscope () ؛ مؤهل للحصول على gct3.t = t1 ؛ // لا يوجد كائن مؤهل للحصول على gct1 = null ؛ // لا يوجد كائن مؤهل لـ GC (T30 لا يزال لديه مرجع إلى t1) t2 = null ؛ أخرى بطريقة مدورة من A // تشكل جزيرة الكائنات دون أي مرجع خارجي //)} الفراغ المحمي المحمي () {system.out.println ("تم جمع القمامة من كائن"+i) ؛ i ++ ؛} class gcscope {gcscope t ؛ static int i = 1 ؛ T2 = جديد gcscope () ؛ gcscope t3 = جديد gcscope () ؛ // لا يوجد كائن يتوافق مع gct1.t = t2 ؛ // لا يوجد كائن يتوافق مع gct2.t = t3 ؛ // لا يوجد كائن يتوافق مع gct3 يتوافق مع GC (T3.TT لا يزال لديه إشارة إلى T2) t3 = null ؛ // جميع الكائنات الثلاثة يتوافق مع GC (لا يوجد أي منها لديه مرجع.برنامج عينة GC OutOfMemoryError
لا يضمن GC أمان مشاكل الفائض في الذاكرة ، وسيؤدي الكود المهمل المكتوب إلى التسبب في OutOfMemoryError.
استيراد java.util.linkedList ؛ استيراد java.util.list ؛ الفئة العامة gc {public static void main (string [] main) {list l = new linkedlist () ؛الإخراج:
استثناء في الموضوع "Main" java.lang.outofmemoryerror: Java Heap Space في java.util.linkedlist.linklast (linkedlist.java:142) على java.util.linkedlist.add (linkedList.java:338) at com.java.java
لخص
ما سبق هو المحتوى الكامل لهذه المقالة حول مناقشة عملية تنفيذ مجموعة القمامة Java لفترة وجيزة. آمل أن يكون ذلك مفيدًا للجميع. يمكن للأصدقاء المهتمين الاستمرار في الرجوع إلى الموضوعات الأخرى ذات الصلة على هذا الموقع. إذا كانت هناك أي أوجه قصور ، فيرجى ترك رسالة لإشارةها. شكرا لك يا أصدقائك لدعمكم لهذا الموقع!