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

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

Cat cat = new Cat();// Our Cat object's lifecycle begins now!

سب سے پہلے، جاوا ورچوئل مشین آبجیکٹ بنانے کے لیے ضروری میموری مختص کرتی ہے۔ پھر یہ اس کا ایک حوالہ بناتا ہے (ہمارے معاملے میں، 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" کار آبجیکٹ دوسری لائن پر زندہ رہنا چھوڑ دیتا ہے۔ اس کا صرف ایک حوالہ تھا، اور حوالہ کالعدم کر دیا گیا تھا۔ چونکہ ڈیابلو کا کوئی حوالہ باقی نہیں ہے، اس لیے یہ "کچرا" بن جاتا ہے۔ ایسا کرنے کے لیے کسی حوالہ کو صفر پر سیٹ کرنے کی ضرورت نہیں ہے:

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 Gallardoاعتراض کی طرف اشارہ کرتے ہیں، لیکن Lamborghini Diabloاعتراض کے پاس کوئی نہیں ہے۔ اس کا مطلب ہے کہ Diabloچیز کوڑا کرکٹ بن جاتی ہے۔ یہ تب ہوتا ہے جب جاوا کا بلٹ ان گاربیج کلیکٹر (GC) شروع ہوتا ہے۔ کوڑا جمع کرنے والا ایک اندرونی جاوا میکانزم ہے جو میموری کو آزاد کرنے کے لیے ذمہ دار ہے، یعنی میموری سے غیر ضروری اشیاء کو ہٹانا۔ ایک وجہ ہے کہ ہم نے روبوٹ ویکیوم کلینر کے ساتھ اس کی نمائندگی کرنے کا انتخاب کیا۔ کوڑا اٹھانے والا تقریباً اسی طرح کام کرتا ہے: یہ آپ کے پروگرام کو پس منظر میں "چلتا ہے"، کچرا جمع کرتا ہے۔ آپ کو عملی طور پر اس کے ساتھ بات چیت کرنے کی ضرورت نہیں ہے۔ اس کا کام ان اشیاء کو حذف کرنا ہے جو اب پروگرام میں استعمال نہیں ہوتے ہیں۔ اس طرح، یہ دیگر اشیاء کے لیے میموری کو آزاد کرتا ہے۔ کیا آپ کو یاد ہے کہ سبق کے آغاز میں ہم نے کہا تھا کہ حقیقی زندگی میں آپ کو اپنے کمپیوٹر کی حالت مانیٹر کرنی ہوگی اور پرانی فائلوں کو ڈیلیٹ کرنا ہوگا؟ اگر ہم جاوا آبجیکٹ کے بارے میں بات کر رہے ہیں، تو کچرا جمع کرنے والا آپ کے لیے ایسا کرتا ہے ۔ جب آپ کا پروگرام چلتا ہے تو کوڑا اٹھانے والا کئی بار شروع ہوتا ہے: آپ کو اسے واضح طور پر کال کرنے اور اسے کمانڈ دینے کی ضرورت نہیں ہے (حالانکہ یہ تکنیکی طور پر ممکن ہے)۔ ہم بعد میں کوڑا اٹھانے والے کے بارے میں مزید بات کریں گے اور مزید تفصیل سے تجزیہ کریں گے کہ یہ کیسے کام کرتا ہے۔ جب کوڑا اٹھانے والا کسی چیز تک پہنچ جاتا ہے — اس کے تباہ ہونے سے ٹھیک پہلے — اس چیز کا خاص finalize()طریقہ کہا جاتا ہے۔ آبجیکٹ کے ذریعہ استعمال ہونے والے کچھ اضافی وسائل کو جاری کرنے کے لئے یہ طریقہ استعمال کیا جاسکتا ہے۔ طریقہ finalize()آبجیکٹ کلاس سے تعلق رکھتا ہے۔ دوسرے الفاظ میں، یہ equals(), hashCode()اور toString()(جس سے آپ پہلے مل چکے ہیں) سے ملتا جلتا ہے۔ ہر شے کے پاس ہوتا ہے ۔ یہ اس میں دوسرے طریقوں سے مختلف ہے... ہمیں یہ کیسے کہنا چاہیے... یہ بہت جان بوجھ کر ہے۔ اس سے ہمارا مطلب ہے کہ کسی چیز کے تباہ ہونے سے پہلے اسے ہمیشہ نہیں کہا جاتا ہے ۔ پروگرامنگ ایک بہت ہی درست سرگرمی ہے۔ پروگرامر کمپیوٹر کو کچھ کرنے کو کہتا ہے، اور کمپیوٹر کرتا ہے۔ میں فرض کرتا ہوں کہ آپ اس طرز عمل کے عادی ہو چکے ہیں، اس لیے پہلے تو آپ کے لیے درج ذیل خیال کو قبول کرنا مشکل ہو سکتا ہے: "کسی چیز کو تباہ کرنے سے پہلے، آبجیکٹ کلاس کا طریقہ کہا جاتا ہے۔ یا نہیں، اگر ہم خوش قسمت ہو جائیں finalize()! " پھر بھی، یہ حقیقت ہے۔ جاوا مشین خود اس بات کا تعین کرتی ہے کہ آیا کسی کیس پر کیس کی بنیاد پر 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;// The first object becomes available for garbage collection here
       }
   }

   @Override
   protected void finalize() throws Throwable {
       System.out.println("The Cat is destroyed!");
   }
}

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