آبجیکٹ لائف سائیکل

ہیلو! میرے خیال میں آپ کو زیادہ حیرت نہیں ہوگی اگر ہم آپ کو بتائیں کہ آپ کے کمپیوٹر پر میموری کا سائز محدود ہے :) یہاں تک کہ ایک ہارڈ ڈرائیو، جو کہ ریم سے کئی گنا بڑی ہے، آپ کے پسندیدہ گیمز، ٹی وی سیریز، اور اسی طرح. ایسا ہونے سے روکنے کے لیے، آپ کو میموری کی موجودہ حالت پر نظر رکھنے اور اپنے کمپیوٹر سے غیر ضروری فائلوں کو حذف کرنے کی ضرورت ہے۔ جاوا پروگرامنگ کا اس سب سے کیا تعلق ہے؟ براہ راست! سب کے بعد، جب جاوا مشین کے ذریعہ کوئی بھی چیز بنائی جاتی ہے، تو اس کے لیے میموری مختص کی جاتی ہے۔ ایک حقیقی بڑے پروگرام میں، دسیوں اور سیکڑوں ہزاروں آبجیکٹ بنائے جاتے ہیں، جن میں سے ہر ایک کی اپنی میموری کا اپنا حصہ مختص ہوتا ہے۔ لیکن آپ کے خیال میں یہ تمام اشیاء کب تک موجود ہیں؟ کیا وہ ہمارے پروگرام کے چلنے کے پورے وقت میں "رہتے" ہیں؟ یقیناً نہیں۔ جاوا آبجیکٹ کے تمام فوائد کے ساتھ، وہ لافانی نہیں ہیں :) آبجیکٹ کا اپنا لائف سائیکل ہے۔ آج ہم کوڈ لکھنے سے تھوڑا وقفہ لیں گے اور اس عمل کو دیکھیں گے :) مزید یہ کہ پروگرام کے آپریشن کو سمجھنے اور وسائل کے انتظام کے لیے یہ بہت ضروری ہے۔ تو، کسی چیز کی زندگی کہاں سے شروع ہوتی ہے؟ ایک شخص کی طرح - اس کی پیدائش سے، یعنی تخلیق۔

Cat cat = new Cat();//вот сейчас и начался vital цикл нашего an object Cat!

سب سے پہلے، جاوا ورچوئل مشین آبجیکٹ بنانے کے لیے میموری کی ضروری مقدار مختص کرتی ہے۔ پھر وہ اس کا ایک لنک بناتی ہے، ہمارے معاملے میں - catاسے ٹریک کرنے کے قابل ہونے کے لیے۔ اس کے بعد، تمام متغیرات کو شروع کیا جاتا ہے، کنسٹرکٹر کو کہا جاتا ہے، اور دیکھو، ہماری تازہ آبجیکٹ پہلے سے ہی اپنی زندگی گزار رہی ہے :) اشیاء کی عمر مختلف ہے، یہاں کوئی صحیح اعداد نہیں ہیں۔ کسی بھی صورت میں، یہ کچھ وقت کے لیے پروگرام کے اندر رہتا ہے اور اپنے افعال انجام دیتا ہے۔ درست ہونے کے لیے، کوئی شے "زندہ" ہے جب تک کہ اس کے حوالے موجود ہوں۔ جیسے ہی کوئی لنک باقی نہیں رہتا، آبجیکٹ "مر جاتا ہے"۔ مثال کے طور پر:

public class Car {

   String model;

   public Car(String model) {
       this.model = model;
   }

   public static void main(String[] args) {
       Car lamborghini  = new Car("Lamborghini Diablo");
       lamborghini = null;

   }

}

طریقہ کار میں، main()Lamborghini Diablo کار آبجیکٹ دوسری لائن پر پہلے سے ہی زندہ رہنا چھوڑ دیتا ہے۔ اس کا صرف ایک لنک تھا، اور اب اس لنک کو تفویض کر دیا گیا ہے null۔ چونکہ لیمبوروگھینی ڈیابلو کا کوئی حوالہ باقی نہیں ہے، اس لیے یہ "فضول" بن جاتا ہے۔ لنک کو دوبارہ ترتیب دینا ضروری نہیں ہے:

public class Car {

   String model;

   public Car(String model) {
       this.model = model;
   }

   public static void main(String[] args) {
       Car lamborghini  = new Car("Lamborghini Diablo");

       Car lamborghiniGallardo = new Car("Lamborghini Gallardo");
       lamborghini = lamborghiniGallardo;
   }

}

یہاں ہم نے دوسرا آبجیکٹ بنایا، جس کے بعد ہم نے حوالہ لیا lamborghiniاور اسے اس نئے آبجیکٹ کو تفویض کیا۔ اب Lamborghini Gallardoاعتراض کی طرف اشارہ کرنے والے دو حوالہ جات ہیں، لیکن Lamborghini Diabloاعتراض کی طرف کوئی نہیں۔ اس لیے چیز Diabloکوڑا کرکٹ بن جاتی ہے۔ اور اس وقت، بلٹ ان جاوا میکانزم جسے کچرا جمع کرنے والا کہا جاتا ہے، یا دوسرے لفظوں میں - گاربیج کلیکٹر، جی سی، کام میں آتا ہے۔ کوڑا اٹھانے والا ایک اندرونی جاوا میکانزم ہے جو میموری کو آزاد کرنے کا ذمہ دار ہے، یعنی اس سے غیر ضروری اشیاء کو ہٹانا۔ یہ بے کار نہیں تھا کہ ہم نے روبوٹ ویکیوم کلینر کے ساتھ تصویر کا انتخاب کیا تاکہ اسے دکھایا جائے۔ سب کے بعد، ردی کی ٹوکری جمع کرنے والا بہت زیادہ اسی طرح کام کرتا ہے: پس منظر میں، یہ آپ کے پروگرام کے ذریعے "سفر" کرتا ہے، کوڑا کرکٹ جمع کرتا ہے، اور اسی وقت آپ عملی طور پر اس کے ساتھ بات چیت نہیں کرتے ہیں۔ اس کا کام ان اشیاء کو ہٹانا ہے جو اب پروگرام میں استعمال نہیں ہوتی ہیں۔ اس طرح، یہ کمپیوٹر میں دیگر اشیاء کے لیے میموری کو آزاد کر دیتا ہے۔ کیا آپ کو یاد ہے کہ لیکچر کے آغاز میں ہم نے کہا تھا کہ عام زندگی میں آپ کو اپنے کمپیوٹر کی حالت مانیٹر کرنی ہوتی ہے اور پرانی فائلوں کو ڈیلیٹ کرنا پڑتا ہے؟ لہذا، جاوا اشیاء کے معاملے میں، کوڑا اٹھانے والا آپ کے لیے یہ کرتا ہے۔ آپ کے پروگرام کے آپریشن کے دوران گاربیج کلیکٹر کو کئی بار لانچ کیا جاتا ہے: اسے خاص طور پر بلانے اور کمانڈ دینے کی ضرورت نہیں ہے، حالانکہ یہ تکنیکی طور پر ممکن ہے۔ بعد میں ہم اس کے بارے میں مزید بات کریں گے اور اس کے کام کے عمل کا مزید تفصیل سے تجزیہ کریں گے۔ اس وقت جب کوڑا اٹھانے والا شے تک پہنچتا ہے، اس کی تباہی سے پہلے، اس چیز پر ایک خاص طریقہ کہا جاتا ہے finalize()۔ اس کا استعمال کچھ اضافی وسائل کو خالی کرنے کے لیے کیا جا سکتا ہے جو آبجیکٹ استعمال کر رہا تھا۔ طریقہ finalize()کلاس سے تعلق رکھتا ہے Object۔ یعنی، کے ساتھ equals()، hashCode()اور toString()، جس سے آپ پہلے ہی مل چکے ہیں، کسی بھی چیز کے پاس ہے۔ دوسرے طریقوں سے اس کا فرق یہ ہے کہ یہ ہے... اسے کیسے ڈالا جائے... بہت موجی۔ یعنی کسی چیز کو تباہ کرنے سے پہلے اسے ہمیشہ نہیں کہا جاتا ہے۔ پروگرامنگ ایک درست چیز ہے۔ پروگرامر کمپیوٹر کو کچھ کرنے کو کہتا ہے، اور کمپیوٹر کرتا ہے۔ آپ شاید پہلے سے ہی اس رویے کے عادی ہیں، اور آپ کے لیے پہلے اس خیال کو قبول کرنا مشکل ہو سکتا ہے: "اشیاء کو تباہ کرنے سے پہلے، کلاس کا finalize()طریقہ کہا جاتا ہے Object۔ یا اسے نہیں کہا جاتا۔ اگر ہم خوش قسمت ہیں!" تاہم، یہ سچ ہے. جاوا مشین خود طے کرتی ہے کہ آیا finalize()ہر مخصوص معاملے میں طریقہ کو کال کرنا ہے یا نہیں۔ مثال کے طور پر، تجربہ کی خاطر درج ذیل کوڈ کو چلانے کی کوشش کریں:

public class Cat {

   private String name;

   public Cat(String name) {
       this.name = name;
   }

   public Cat() {
   }

   public static void main(String[] args) throws Throwable {

       for (int i = 0 ; i < 1000000; i++) {

           Cat cat = new Cat();
           cat = null;//вот здесь первый an object становится доступен сборщику мусора
       }
   }

   @Override
   protected void finalize() throws Throwable {
       System.out.println("Объект Cat уничтожен!");
   }
}

ہم ایک آبجیکٹ بناتے ہیں Catاور کوڈ کی اگلی لائن میں ہم اس کا واحد حوالہ دوبارہ ترتیب دیتے ہیں۔ اور اس طرح - ایک ملین بار. ہم نے واضح طور پر طریقہ کو اوور رائیڈ کر دیا ہے finalize()، اور اسے ہر بار آبجیکٹ کو تباہ کرنے سے پہلے کنسول پر سٹرنگ کو ایک ملین بار پرنٹ کرنا چاہیے Cat۔ لیکن نہیں! عین مطابق ہونے کے لیے، یہ میرے کمپیوٹر پر صرف 37,346 بار چلا! یعنی، 27 میں سے صرف 1 کیس میں جاوا مشین جس کو میں نے انسٹال کیا تھا ایک طریقہ کو کال کرنے کا فیصلہ کیا finalize()- دوسرے معاملات میں، کوڑا اٹھانا اس کے بغیر آگے بڑھا۔ اس کوڈ کو خود چلانے کی کوشش کریں: غالب امکان ہے کہ نتیجہ مختلف ہوگا۔ جیسا کہ آپ دیکھ سکتے ہیں، finalize()اسے ایک قابل اعتماد پارٹنر کہنا مشکل ہے :) لہذا، مستقبل کے لیے ایک چھوٹی سی نصیحت: آپ کو finalize()کچھ اہم وسائل کو آزاد کرنے کے معاملے میں طریقہ پر بھروسہ نہیں کرنا چاہیے۔ ہوسکتا ہے کہ جے وی ایم اسے کال کرے ، شاید نہیں۔ کسے پتا؟ اگر اپنی زندگی کے دوران آپ کے آبجیکٹ نے کچھ ایسے وسائل پر قبضہ کر لیا جو کارکردگی کے لیے انتہائی اہم تھے، مثال کے طور پر، اس نے ڈیٹا بیس سے کھلا کنکشن رکھا ہے، تو بہتر ہے کہ آپ اپنی کلاس میں ایک خاص طریقہ بنائیں تاکہ انہیں آزاد کیا جا سکے اور جب اعتراض ہو تو اسے واضح طور پر کال کریں۔ اب ضرورت نہیں ہے. اس طرح آپ یقینی طور پر جان لیں گے کہ آپ کے پروگرام کی کارکردگی متاثر نہیں ہوگی۔ بالکل شروع میں ہم نے کہا کہ میموری کا انتظام اور کوڑا کرکٹ کو ہٹانا بہت ضروری ہے، اور یہ سچ ہے۔ وسائل کا نامناسب ہینڈلنگ اور غیر ضروری اشیاء کو جمع کرنے کے عمل کو نہ سمجھنا میموری لیک ہونے کا باعث بن سکتا ہے۔ یہ پروگرامنگ کی سب سے مشہور غلطیوں میں سے ایک ہے۔ پروگرامر کی طرف سے غلط لکھے گئے کوڈ کے نتیجے میں ہر بار نئی تخلیق شدہ اشیاء کے لیے نئی میموری مختص کی جا سکتی ہے، جبکہ پرانی، غیر ضروری اشیاء کو کوڑا اٹھانے والے کے ذریعے ہٹانے کے لیے دستیاب نہیں ہیں۔ چونکہ ہم نے روبوٹ ویکیوم کلینر سے مشابہت پیدا کی ہے، اس لیے تصور کریں کہ کیا ہوگا اگر، روبوٹ کو شروع کرنے سے پہلے، آپ نے گھر کے چاروں طرف جرابیں بکھیر دیں، شیشے کا گلدان توڑ دیا اور فرش پر الگ الگ لیگو سیٹ چھوڑ دیا۔ روبوٹ یقیناً کچھ کرنے کی کوشش کرے گا، لیکن ایک موقع پر وہ پھنس جائے گا۔ اس کے صحیح طریقے سے کام کرنے کے لیے، آپ کو فرش کو اچھی حالت میں رکھنے اور وہاں سے ہر وہ چیز ہٹانے کی ضرورت ہے جسے ویکیوم کلینر سنبھال نہیں سکتا۔ کچرا اٹھانے والا بھی اسی اصول پر کام کرتا ہے۔ اگر پروگرام میں بہت سی ایسی چیزیں رہ جاتی ہیں جنہیں وہ جمع نہیں کر سکتا (جیسے روبوٹ ویکیوم کلینر کے لیے جراب یا لیگو)، تو ایک موقع پر میموری ختم ہو جائے گی۔ اور نہ صرف آپ کا لکھا ہوا پروگرام منجمد ہو جائے گا بلکہ اس وقت کمپیوٹر پر چلنے والے دیگر تمام پروگرامز بھی منجمد ہو جائیں گے۔ ان کے لیے کافی میموری بھی نہیں ہوگی۔ جاوا میں آبجیکٹ لائف سائیکل اور کوڑا اٹھانے والا ایسا ہی نظر آتا ہے۔ اسے یاد کرنے کی ضرورت نہیں ہے: صرف آپریشن کے اصول کو سمجھیں۔ اگلے لیکچر میں ہم ان پراسیسز کے بارے میں مزید تفصیل سے بات کریں گے، لیکن ابھی آپ جاوا رش کے مسائل کو حل کرنے کے لیے واپس آ سکتے ہیں :) گڈ لک!