Object resurrection
کچرا جمع کرنے والی آبجیکٹ پر مبنی پروگرامنگ زبانوں میں، آبجیکٹ ریزورکشن اس وقت ہوتا ہے جب آبجیکٹ کی تباہی کے عمل کے دوران کوئی آبجیکٹ دوبارہ زندہ ہو جاتا ہے، حتمی شکل دینے والے کے ضمنی اثر کے طور پر۔ آبجیکٹ کی بحالی متعدد مسائل کا سبب بنتی ہے، خاص طور پر یہ کہ آبجیکٹ کی بحالی کا امکان-چاہے وہ نہ بھی ہو-کچرے کو جمع کرنے کو نمایاں طور پر زیادہ پیچیدہ اور سست بنا دیتا ہے، اور یہ ایک بڑی وجہ ہے کہ حتمی شکل دینے والوں کی حوصلہ شکنی کی جاتی ہے۔ زبانیں مختلف طریقوں سے اشیاء کے جی اٹھنے سے نمٹتی ہیں۔ غیر معمولی حالات میں، آبجیکٹ جی اٹھنے کا استعمال کچھ ڈیزائن کے نمونوں کو نافذ کرنے کے لیے کیا جاتا ہے، خاص طور پر ایک آبجیکٹ پول، جبکہ دیگر حالات میں جی اٹھنا ایک ناپسندیدہ بگ ہے جو حتمی شکل دینے میں غلطی کی وجہ سے ہوتا ہے، اور عام طور پر جی اٹھنے کی حوصلہ شکنی کی جاتی ہے۔ عمل آبجیکٹ کی بحالی مندرجہ ذیل عمل کے ذریعے ہوتی ہے۔ سب سے پہلے، کوئی چیز تب کچرا بن جاتی ہے جب وہ پروگرام سے قابل رسائی نہیں ہوتی، اور اسے جمع کیا جا سکتا ہے (تباہ اور منقطع)۔ پھر، آبجیکٹ کی تباہی کے دوران، اس سے پہلے کہ کچرا جمع کرنے والا آبجیکٹ کو مختص کرے، ایک فائنلائزر طریقہ چلایا جا سکتا ہے، جو بدلے میں اس آبجیکٹ یا کسی اور کچرا آبجیکٹ (فائنلائزر کے ساتھ آبجیکٹ سے قابل رسائی) کو حوالہ بنا کر دوبارہ قابل رسائی بنا سکتا ہے، کیونکہ فائنلائزر میں صوابدیدی کوڈ ہو سکتا ہے۔ اگر ایسا ہوتا ہے تو، حوالہ شدہ آبجیکٹ-جو ضروری نہیں کہ حتمی آبجیکٹ ہو-اب کچرا نہیں ہے، اور اسے الگ نہیں کیا جا سکتا، کیونکہ بصورت دیگر اس کے حوالے لٹکنے والے حوالہ جات بن جائیں گے اور استعمال ہونے پر غلطیوں کا سبب بنیں گے، عام طور پر پروگرام کریش یا غیر متوقع طرز عمل۔ اس کے بجائے، یادداشت کی حفاظت کو برقرار رکھنے کے لیے، شے کو دوبارہ زندہ کیا جاتا ہے یا دوبارہ زندہ کیا جاتا ہے۔ اس کا پتہ لگانے کے لیے، کچرا جمع کرنے والا عام طور پر حتمی شکل دینے والوں کی موجودگی میں دو مراحل میں جمع کرے گا: پہلے کسی بھی کچرے کو حتمی شکل دیں جس میں حتمی شکل دی گئی ہو، اور پھر تمام کچرے (یا حتمی شکل دینے والی اشیاء سے قابل رسائی تمام کچرا) کو دوبارہ چیک کریں، اگر حتمی شکل دینے والوں نے کچھ کچرا دوبارہ جمع کیا ہو۔ یہ اوور ہیڈ میں اضافہ کرتا ہے اور میموری کی بحالی میں تاخیر کرتا ہے۔ دوبارہ زندہ کی گئی اشیاء ایک دوبارہ زندہ کی گئی چیز کے ساتھ دوسری اشیاء کی طرح سلوک کیا جا سکتا ہے، یا اس کا خاص طور پر علاج کیا جا سکتا ہے۔ بہت سی زبانوں میں، خاص طور پر سی #، جاوا، اور ازگر (ازگر 3.4 سے)، اشیاء کو صرف ایک بار حتمی شکل دی جاتی ہے، تاکہ کسی شے کے بار بار دوبارہ زندہ ہونے یا یہاں تک کہ ناقابل تسخیر ہونے کے امکان سے بچا جا سکے۔ سی #میں ڈیفالٹ طور پر حتمی شکل دینے والے اشیاء کو صرف ایک بار حتمی شکل دی جاتی ہے، لیکن اسے حتمی شکل دینے کے لیے دوبارہ رجسٹر کیا جا سکتا ہے۔ دوسرے معاملات میں دوبارہ زندہ کی گئی اشیاء کو غلطیاں سمجھا جاتا ہے، خاص طور پر آبجیکٹیو-سی میں ؛ یا دیگر اشیاء کے ساتھ یکساں سلوک کیا جاتا ہے، خاص طور پر ازگر 3.4 سے پہلے ازگر میں۔ دوبارہ زندہ ہونے والی شے کو بعض اوقات a یا زومبی کہا جاتا ہے، لیکن یہ اصطلاح آبجیکٹ کی تباہی سے متعلق مختلف آبجیکٹ اسٹیٹس کے لیے استعمال ہوتی ہے، جس کا استعمال زبان اور مصنف پر منحصر ہوتا ہے۔ آبجیکٹیو-سی میں "زومبی آبجیکٹ" کا ایک خاص معنی ہوتا ہے، تاہم، جس کی تفصیل ذیل میں دی گئی ہے۔ زومبی آبجیکٹ زومبی کے عمل سے کسی حد تک مشابہت رکھتے ہیں، اس میں کہ وہ اختتامی حالت میں تبدیلی سے گزر چکے ہیں اور ڈی لوکیشن کے قریب ہیں، لیکن تفصیلات نمایاں طور پر مختلف ہیں۔ . NET فریم ورک میں متغیرات، خاص طور پر C #اور VB.NET، "آبجیکٹ ریزورکشن" اس کے بجائے حتمی شکل دینے کے دوران کسی شے کی حالت سے مراد ہے: آبجیکٹ کو دوبارہ زندہ کیا جاتا ہے (ناقابل رسائی ہونے سے)، فائنلائزر چلایا جاتا ہے، اور پھر ناقابل رسائی ہونے پر واپس آ جاتا ہے (اور اب مستقبل میں حتمی شکل دینے کے لیے رجسٹرڈ نہیں ہے)۔ . NET میں، جن اشیاء کو حتمی شکل دینے کی ضرورت ہوتی ہے انہیں آبجیکٹ بہ آبجیکٹ ٹریک نہیں کیا جاتا ہے، بلکہ اسے حتمی شکل دینے والی "قطار" میں محفوظ کیا جاتا ہے، لہذا اس مضمون کے معنی میں دوبارہ زندہ ہونے والی اشیاء کے تصور کے بجائے، کوئی "حتمی شکل دینے کے لیے قطار میں کھڑی" اشیاء کی بات کرتا ہے۔ مزید برآں، اشیاء کو حتمی شکل دینے کے لیے GC.ReRegisterForFinalize کے ذریعے دوبارہ انکیو کیا جا سکتا ہے، اس بات کا خیال رکھتے ہوئے کہ انکیو اشیاء کو ضرب نہ دیں۔ میکانزم دو اہم طریقے ہیں جن سے کوئی شے اپنے آپ کو یا کسی اور شے کو دوبارہ زندہ کر سکتی ہے: کسی ایسی شے میں اپنا حوالہ بنا کر جس تک وہ پہنچ سکے (کچرا قابل رسائی نہیں ہے، لیکن کچرا غیر کچرا اشیاء کا حوالہ دے سکتا ہے)، یا ماحول میں حوالہ بنا کر (عالمی متغیرات، یا کچھ معاملات میں جامد متغیرات یا بندش میں متغیرات)۔ دونوں کی ازگر کی مثالیں پیروی کرتی ہیں، کسی شے کے لیے جو خود کو دوبارہ زندہ کرتی ہے۔ کسی شے کے لیے دوسری اشیاء کو دوبارہ زندہ کرنا بھی ممکن ہے اگر دونوں کو ایک ہی میکانزم کے ذریعے کچرا جمع کرنے کے ایک مخصوص چکر میں جمع کیا جا رہا ہو۔ کسی شے میں حوالہ بنا کر خود کو درست کرتا ہے جس تک وہ پہنچ سکتا ہے: کلاس کلنگی: ڈیف _ _ init _ (سیلف، ریف = کوئی نہیں)-> کوئی نہیں: self.ref = ریف ڈیف _ _ ڈیل _ (سیلف): اگر self.ref: self.ref. ریف = سیلف پرنٹ ("مجھے مت چھوڑیں!") a = Clingy (Clingy ()) #ایک 2-عنصر سے منسلک فہرست بنائیں، #جس کا حوالہ |a۔ a.ref. ریف = a #ایک سائیکل بنائیں a.ref = کوئی نہیں #پہلے نوڈ سے دوسرے نوڈ تک حوالہ صاف کرنے سے دوسرا کچرا a.ref = کوئی نہیں عالمی ماحول میں حوالہ بنا کر خود کو درست کرتا ہے: c = کوئی کلاس امر نہیں: ڈیف _ _ ڈیل _ (سیلف): گلوبل cc = سیلف پرنٹ ("میں ابھی تک مردہ نہیں ہوں")۔ c = امر () c = کوئی نہیں #کلیئرنگ C = کوئی نہیں بناتی ہے۔ مندرجہ بالا مثالوں میں، CPython میں 3.4 سے پہلے، یہ بار بار فائنلائزر چلائیں گے، اور اشیاء کو کچرا جمع نہیں کیا جائے گا، جبکہ CPython 3.4 اور بعد میں، فائنلائزر کو صرف ایک بار بلایا جائے گا، اور دوسری بار جب وہ ناقابل رسائی ہو جائیں گے تو اشیاء کو کچرا جمع کیا جائے گا۔ مسائل آبجیکٹ کی بحالی بڑی تعداد میں مسائل کا سبب بنتی ہے۔ کچرا اکٹھا کرنا پیچیدہ بناتا ہے آبجیکٹ کے دوبارہ جی اٹھنے کے امکان کا مطلب ہے کہ کچرا جمع کرنے والے کو حتمی شکل دینے کے بعد دوبارہ جی اٹھنے والی اشیاء کی جانچ کرنی چاہیے-چاہے وہ حقیقت میں نہ بھی ہو-جو کچرا اکٹھا کرنے کو پیچیدہ اور سست کر دیتا ہے۔ ناقابل تسخیر اشیاء بعض حالات میں کوئی شے ناقابل تسخیر ہو سکتی ہے: اگر کسی شے کو اس کے اپنے فائنلائزر میں دوبارہ زندہ کیا جاتا ہے (یا اشیاء کا ایک گروہ اپنے فائنلائزر کے نتیجے میں ایک دوسرے کو دوبارہ زندہ کرتا ہے)، اور شے کو تباہ کرتے وقت فائنلائزر کو ہمیشہ بلایا جاتا ہے، تو شے کو تباہ نہیں کیا جا سکتا اور اس کی یادداشت کو دوبارہ حاصل نہیں کیا جا سکتا۔ حادثاتی جی اٹھنا اور رساو تیسرا، آبجیکٹ جی اٹھنا غیر ارادی ہو سکتا ہے، اور اس کا نتیجہ بامعنی کچرا ہو سکتا ہے، اس لیے اصل میں کبھی جمع نہیں کیا جاتا، جس کی وجہ سے منطقی میموری رساو ہوتا ہے۔ غیر متزلزل حالت اور دوبارہ شروع کرنا ایک دوبارہ زندہ شدہ شے غیر متزلزل حالت میں ہو سکتی ہے، یا کلاس کے غیر متغیرات کی خلاف ورزی کر سکتی ہے، کیونکہ فائنلائزر کو پھانسی دے دی گئی ہے اور بے قاعدہ حالت کا سبب بنتی ہے۔ اس طرح دوبارہ زندہ کی گئی اشیاء کو عام طور پر دستی طور پر دوبارہ شروع کرنے کی ضرورت ہوتی ہے۔ منفرد حتمی شکل دینا یا دوبارہ حتمی شکل دینا کچھ زبانوں میں (جیسے جاوا اور ازگر 3.4 +) حتمی شکل دینے کی ضمانت ہر شے کے لیے بالکل ایک بار ہوتی ہے، اس لیے دوبارہ زندہ ہونے والی اشیاء کو ان کے حتمی شکل دینے والوں کو نہیں بلایا جائے گا ؛ لہذا، دوبارہ زندہ ہونے والی اشیاء کو حتمی شکل دینے والے سے باہر کسی بھی ضروری صفائی کوڈ کو انجام دینا ہوگا۔ کچھ دوسری زبانوں میں، پروگرامر بار بار حتمی شکل دینے پر مجبور کر سکتا ہے ؛ خاص طور پر، C #میں GC.ReRegisterForFinalize ہے۔ حل زبانوں نے آبجیکٹ کی بحالی سے نمٹنے کے لیے کئی مختلف طریقے اپنائے ہیں، عام طور پر حتمی شکل دینے والوں کی موجودگی میں دو مراحل کا کچرا جمع کرنا، تاکہ حوالہ جات کو لٹکنے سے روکا جا سکے۔ اور صرف ایک بار اشیاء کو حتمی شکل دے کر، خاص طور پر اشیاء کو حتمی شکل دے کر (جھنڈے کے ذریعے)، اس بات کو یقینی بنانے کے لیے کہ اشیاء کو تباہ کیا جا سکتا ہے۔ جاوا اس آبجیکٹ کو اس وقت تک آزاد نہیں کرے گا جب تک کہ یہ ثابت نہ ہو جائے کہ آبجیکٹ ایک بار پھر ناقابل رسائی ہے، لیکن فائنلائزر کو ایک سے زیادہ بار نہیں چلائے گا۔ پائیتھن میں، پائیتھن 3.4 سے پہلے، معیاری سی پائیتھن کا نفاذ دوبارہ زندہ ہونے والی اشیاء کو دوسری اشیاء (جنہیں کبھی حتمی شکل نہیں دی گئی تھی) کے ساتھ یکساں طور پر پیش کرے گا، جس سے ناقابل تسخیر اشیاء ممکن ہو جائیں گی۔ مزید برآں، یہ اشیاء کے جی اٹھنے کے ساتھ ممکنہ مسائل سے بچنے کے لیے ایسی سائیکلوں کو جمع نہیں کرے گا جن میں کسی چیز کو حتمی شکل دی گئی ہو۔ ازگر 3.4 سے شروع کرتے ہوئے، طرز عمل بڑی حد تک جاوا جیسا ہی ہے: اشیاء کو صرف ایک بار حتمی شکل دی جاتی ہے ("پہلے سے حتمی" کے طور پر نشان زد کیا جاتا ہے)، چکروں کا کچرا جمع کرنا دو مراحل میں ہوتا ہے، دوسرے مرحلے میں دوبارہ زندہ ہونے والی اشیاء کی جانچ پڑتال ہوتی ہے۔ مقصد-C 2.0 دوبارہ زندہ ہونے والی اشیاء کو "زومبی" حالت میں رکھے گا، جہاں وہ انہیں بھیجے گئے تمام پیغامات کو لاگ ان کرتے ہیں، لیکن کچھ اور نہیں کرتے۔ خودکار حوالہ شمار: کمزور حوالہ جات کو سنبھالنے کے لیے کمزور حوالہ جات کو صفر کرنا بھی دیکھیں۔ . NET فریم ورک میں، خاص طور پر C #اور VB.NET، آبجیکٹ کو حتمی شکل دینے کا تعین "قطار" کو حتمی شکل دے کر کیا جاتا ہے، جسے آبجیکٹ کی تباہی کے دوران چیک کیا جاتا ہے۔ فائنلائزر والی اشیاء کو تخلیق کے وقت اس قطار میں رکھا جاتا ہے، اور فائنلائزر کو کال کرنے پر ڈیکیو کیا جاتا ہے، لیکن اسے دستی طور پر (حتمی شکل دینے سے پہلے) سپریس فائنالائز کے ساتھ ڈیکیو کیا جا سکتا ہے یا ری ریجسٹر فار فائنالائز کے ساتھ دوبارہ ڈیکیو کیا جا سکتا ہے۔ اس طرح پہلے سے طے شدہ اشیاء کو زیادہ سے زیادہ ایک بار حتمی شکل دی جاتی ہے، لیکن اس حتمی شکل کو دبایا جا سکتا ہے، یا اشیاء کو متعدد بار حتمی شکل دی جا سکتی ہے اگر انہیں دوبارہ زندہ کیا جائے (دوبارہ قابل رسائی بنایا جائے) اور پھر حتمی شکل دینے کے لیے دوبارہ تیار کیا جائے۔ مزید برآں، پہلے سے طے شدہ طور پر کمزور حوالہ جات قیامت کو ٹریک نہیں کرتے، یعنی اگر کسی شے کو دوبارہ زندہ کیا جاتا ہے تو کمزور حوالہ کو اپ ڈیٹ نہیں کیا جاتا ہے۔ انہیں مختصر کمزور حوالہ جات کہا جاتا ہے، اور کمزور حوالہ جات جو قیامت کو ٹریک کرتے ہیں انہیں طویل کمزور حوالہ جات کہا جاتا ہے۔ ایپلی کیشنز آبجیکٹ ریزورکشن عام طور پر استعمال ہونے والی اشیاء کے آبجیکٹ پول کو سنبھالنے کے لیے مفید ہے، لیکن یہ کوڈ کو غیر واضح کرتا ہے اور اسے مزید الجھن میں ڈالتا ہے۔ اسے صرف ان اشیاء کے لیے استعمال کیا جانا چاہیے جو اکثر استعمال کی جا سکتی ہیں اور جہاں اس کی تعمیر/تباہی میں وقت لگتا ہو۔ ایک مثال بے ترتیب نمبروں کی ایک صف ہو سکتی ہے، جہاں ان کی ایک بڑی تعداد مختصر وقت میں بنائی اور تباہ ہو جاتی ہے، لیکن جہاں حقیقت میں ایک ہی وقت میں صرف ایک چھوٹی سی تعداد استعمال میں ہوتی ہے۔ آبجیکٹ ریزورکشن کے ساتھ، پولنگ تکنیک تخلیق اور تباہی کے غیر ضروری اوور ہیڈ کو کم کرے گی۔ یہاں، پول مینیجر اپنے آبجیکٹ اسٹیک کی معلومات کو آبجیکٹ کے حوالے کی شکل میں حاصل کرے گا، اگر اسے فی الحال تباہ کرنا ہے۔ پول مینیجر اس شے کو بعد میں دوبارہ استعمال کے لیے رکھے گا۔ آبجیکٹ لائف ٹائم نوٹس حوالہ جات میموری مینجمنٹ آبجیکٹ (کمپیوٹر سائنس) بھی دیکھیں۔