اعتراض جي زندگي

سلام مان سمجهان ٿو ته توهان کي تمام گهڻو تعجب نه ٿيندو جيڪڏهن مون توهان کي ٻڌايو ته توهان جي ڪمپيوٽر ۾ ميموري جي محدود مقدار آهي :) ايستائين جو توهان جي هارڊ ڊرائيو (جيڪا گهڻي آهي، ڪيترائي ڀيرا ريم جي سائيز) توهان جي پسنديده رانديون، ٽي وي شوز، ۽ ٻين شين مان مڪمل چيڪ حاصل ڪري سگهو ٿا. ائين ٿيڻ کان روڪڻ لاءِ، توهان کي پنهنجي ڪمپيوٽر جي ميموري جي موجوده حالت کي مانيٽر ڪرڻ ۽ غير ضروري فائلن کي حذف ڪرڻ جي ضرورت آهي. اهو سڀ ڪجهه جاوا پروگرامنگ سان ڪيئن جڙيل آهي؟ بلڪل سڌو! آخرڪار، ڪنهن به شئي کي ٺاهڻ جاوا مشين کي ان لاءِ ميموري مختص ڪرڻ جو سبب بڻائيندو آهي . حقيقي دنيا جو هڪ وڏو پروگرام ڏهه يا سوين هزارين شيون ٺاهي ٿو، ۽ انهن مان هر هڪ لاءِ ياداشت جو هڪ حصو مختص ڪيو ويو آهي. پر توهان ڇا ٿا سوچيو، انهن مان ڪيتريون شيون موجود آهن؟ ڇا اهي ”زنده“ آهن جڏهن اسان جو پروگرام هلي رهيو آهي؟ بلڪل نه. جيتوڻيڪ انهن جي سڀني فائدن سان، جاوا شيون امر نه آهن :) شيون پنهنجون زندگيون آهن. اڄ اسان ڪوڊ لکڻ کان ٿورو وقفو وٺنداسين ۽ هن عمل کي ڳولينداسين :) اهو پڻ تمام ضروري آهي انهي کي سمجهڻ لاءِ ته هڪ پروگرام ڪيئن ڪم ڪري ٿو ۽ وسيلن جي انتظام لاءِ. تنهن ڪري، هڪ اعتراض جي زندگي ڪٿي شروع ٿئي ٿي؟ انسان وانگر، پيدائش کان، يعني جڏهن اهو پيدا ٿيو آهي.

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" ڪار اعتراض ٻئي لڪير تي جيئرو ٿيڻ بند آهي. ان لاءِ صرف هڪ حوالو هو، ۽ حوالو 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 Gallardoاعتراض ڏانهن اشارو ڪن ٿا، پر Lamborghini Diabloاعتراض ڪو به نه آهي. ان جو مطلب اهو آهي ته Diabloاعتراض گندو ٿي ويندو آهي. اهو تڏهن ٿيندو آهي جڏهن جاوا جي ٺاهيل گاربيج ڪليڪٽر (GC) اندر داخل ٿيندي آهي. گاربيج ڪليڪٽر هڪ اندروني جاوا ميکانيزم آهي جيڪو ميموري کي آزاد ڪرڻ جو ذميوار آهي، يعني ياداشت مان غير ضروري شيون هٽائڻ. اتي ھڪڙو سبب آھي ڇو ته اسان ان کي روبوٽ ويڪيوم ڪلينر سان نمائندگي ڪرڻ جو انتخاب ڪيو آھي. گاربيج ڪليڪٽر اٽڪل ساڳئي طريقي سان ڪم ڪري ٿو: اهو توهان جي پروگرام کي پس منظر ۾ "هلائي ٿو"، ڪچرو گڏ ڪرڻ. توهان کي عملي طور تي ان سان رابطو ڪرڻ جي ضرورت ناهي. ان جو ڪم انهن شين کي ختم ڪرڻ آهي جيڪي هاڻي پروگرام ۾ استعمال نه ڪيا ويا آهن. اهڙيء طرح، اهو ٻين شين لاء ياداشت کي آزاد ڪري ٿو. ڇا توهان کي ياد آهي ته سبق جي شروعات ۾ اسان چيو هو ته حقيقي زندگي ۾ توهان کي پنهنجي ڪمپيوٽر جي حالت مانيٽر ڪرڻو پوندو ۽ پراڻي فائلن کي حذف ڪرڻو پوندو؟ جيڪڏهن اسان جاوا شين جي باري ۾ ڳالهائي رهيا آهيون، گندي جمع ڪندڙ اهو توهان لاء ڪندو آهي . ڪچرو جمع ڪندڙ ڪيترائي ڀيرا شروع ڪيو ويو آهي جيئن توهان جو پروگرام هلندو آهي: توهان کي واضح طور تي ان کي ڪال ڪرڻ ۽ ان کي حڪم ڏيڻ جي ضرورت ناهي (جيتوڻيڪ اهو ٽيڪنالاجي طور ممڪن آهي). اسان بعد ۾ گندي ڪليڪٽر بابت وڌيڪ ڳالهائينداسين ۽ تجزيو ڪنداسين ته اهو ڪيئن ڪم ڪري ٿو وڌيڪ تفصيل سان. جڏهن ڪچرو گڏ ڪندڙ ڪنهن شئي تائين پهچي ٿو- ان جي تباهه ٿيڻ کان اڳ- ان شئي کي خاص finalize()طريقو چئبو آهي. اهو طريقو استعمال ڪري سگهجي ٿو اعتراض طرفان استعمال ڪيل ڪجهه اضافي وسيلن کي ڇڏڻ لاءِ. طريقو finalize()Object class سان تعلق رکي ٿو. ٻين لفظن ۾، اهو ساڳيو آهي 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 جا ٽڪرا ڇڏي ڏيو. قدرتي طور، روبوٽ ڪجهه ڪرڻ جي ڪوشش ڪندو، پر هڪ ڏينهن اهو پڪڙيندو. ويڪيوم ڪلينر کي صحيح طريقي سان هلائڻ لاءِ، توهان کي فرش کي مهذب شڪل ۾ رکڻو پوندو ۽ هر شي کي کڻڻو پوندو جيڪو اهو سنڀالي نٿو سگهي. ڪچرو گڏ ڪرڻ وارو ساڳيو اصول تي عمل ڪري ٿو. جيڪڏهن هڪ پروگرام ۾ تمام گهڻيون شيون آهن ته اهو صاف نٿو ڪري سگهي (جهڙوڪ اسان جي روبوٽڪ ويڪيوم ڪلينر لاءِ جراب يا ليگو)، هڪ ڏينهن اسان جي يادگيري ختم ٿي ويندي. نه رڳو توھان جو پروگرام ھنگ ٿيندو، پر ٻيا سڀ پروگرام جيڪي ڪمپيوٽر تي ھلڻ لڳندا آھن سي به ھلندا. آخرڪار، انهن وٽ ڪافي ياداشت نه هوندي (اسان جي قياس ڏانهن واپسي، فرش تي ڀريل گلاس نه رڳو ويڪيوم ڪلينر کي روڪي ٿو، پر گهر ۾ رهندڙ ماڻهن کي پڻ). مختصر ۾، هي اهو آهي جيڪو آبجیکٹ لائف سائيڪل ۽ گندگي گڏ ڪرڻ جاوا ۾ نظر اچن ٿا. توهان کي هن کي ياد ڪرڻ جي ضرورت ناهي: اهو صرف سمجهڻ لاء ڪافي آهي ته اهو ڪيئن ڪم ڪري ٿو. ايندڙ سبق ۾، اسان وڌيڪ تفصيل سان انهن عملن ڏانهن موٽنداسين. پر ھاڻي، توھان واپس ڪري سگھوٿا CodeGym ڪمن کي حل ڪرڻ لاءِ :) سٺي قسمت!