جاوا ڪور. انٽرويو سوال، حصو 2

جن ماڻهن جاوا ڪور جو لفظ پهريون ڀيرو ٻڌو، تن لاءِ اهي ٻولي جا بنيادي بنياد آهن. هن علم سان، توهان محفوظ طور تي هڪ انٽرنيشنل شپ / انٽرنيشنل شپ لاء وڃي سگهو ٿا. اهي سوال توهان جي انٽرويو کان اڳ توهان جي ڄاڻ کي تازو ڪرڻ ۾ مدد ڪندي، يا پنهنجي لاء ڪجهه نئين سکندا. عملي صلاحيتن کي حاصل ڪرڻ لاء، JavaRush تي پڙهو . اصل مضمون ٻين حصن جا لنڪ: Java Core. انٽرويو سوال، حصو 1 جاوا ڪور. انٽرويو لاءِ سوال، حصو 3

حتمي () طريقو ڇو پاسو ڪيو وڃي؟

اسان سڀيئي ڄاڻون ٿا ته اهو بيان آهي ته هڪ طريقو finalize()سڏيو ويندو آهي ردي جي ڪليڪٽر طرفان هڪ اعتراض جي قبضي واري ياداشت کي آزاد ڪرڻ کان اڳ. هتي هڪ مثال پروگرام آهي جيڪو ثابت ڪري ٿو ته هڪ طريقو ڪال finalize()ضمانت نه آهي:

public class TryCatchFinallyTest implements Runnable {

	private void testMethod() throws InterruptedException
	{
		try
		{
			System.out.println("In try block");
			throw new NullPointerException();
		}
		catch(NullPointerException npe)
		{
			System.out.println("In catch block");
		}
		finally
		{
			System.out.println("In finally block");
		}
	}

	@Override
	protected void finalize() throws Throwable {
		System.out.println("In finalize block");
		super.finalize();
	}

	@Override
	public void run() {
		try {
			testMethod();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

public class TestMain
{
	@SuppressWarnings("deprecation")
	public static void main(String[] args) {
	for(int i=1;i< =3;i++)
	{
		new Thread(new TryCatchFinallyTest()).start();
	}
	}
}

آئوٽ پُٽ: ٽرائي بلاڪ ۾ ڪيچ بلاڪ ۾ آخرڪار بلاڪ ۾ ڪوشش بلاڪ ۾ ڪيچ بلاڪ ۾ آخرڪار بلاڪ ۾ ڪوشش بلاڪ ۾ ڪيچ بلاڪ ۾ آخر ۾ بلاڪ ۾ ، تعجب جي ڳالهه اها آهي ته طريقي سان finalizeڪنهن به سلسلي لاءِ عمل نه ڪيو ويو. هي منهنجي ڳالهه ثابت ڪري ٿو. منهنجو خيال آهي ته ان جو سبب اهو آهي ته فائنلائزر هڪ الڳ ڪچري جي ڪليڪٽر ٿريڊ طرفان جاري ڪيا ويا آهن. جيڪڏهن جاوا ورچوئل مشين تمام جلدي ختم ٿي وڃي ٿي، ته پوءِ ڪچري جي ڪليڪٽر وٽ ايترو وقت نه هوندو آهي ته هو حتمي ساز ٺاهڻ ۽ ان تي عمل ڪري. هن طريقي کي استعمال نه ڪرڻ جا ٻيا سبب finalize()ٿي سگهن ٿا:

1. اهو طريقو finalize()زنجيرن سان ڪم نٿو ڪري جهڙوڪ تعمير ڪندڙ. هن جو مطلب اهو آهي ته جڏهن توهان هڪ طبقي تعمير ڪندڙ کي سڏيندا آهيو، سپر ڪلاس تعمير ڪندڙ کي غير مشروط طور سڏيو ويندو. پر طريقي جي صورت ۾ finalize()، اهو عمل نه ٿيندو. سپر ڪلاس جو طريقو finalize()واضح طور سڏيو وڃي ٿو.
2. ڪنهن به استثناءَ کي طريقه ڪار ذريعي اڇلايو ويو finalizeآهي، جنهن کي گندي جمع ڪندڙ ٿريڊ طرفان نظر انداز ڪيو ويندو ۽ ان کي وڌيڪ پروپيگنڊا نه ڪيو ويندو، جنهن جو مطلب آهي ته واقعو توهان جي لاگن ۾ رڪارڊ نه ڪيو ويندو. اهو تمام خراب آهي، ڇا اهو ناهي؟

3. توهان پڻ هڪ اهم ڪارڪردگي جي سزا حاصل ڪريو جيڪڏهن طريقو finalize()توهان جي ڪلاس ۾ موجود آهي. مؤثر پروگرامنگ ۾ (2nd ايڊ.)، جوشوا بلوچ چيو:
   "ها، ۽ هڪ ٻي شيء: حتمي ڪارڪردگي استعمال ڪرڻ وقت هڪ وڏو ڪارڪردگي جي سزا آهي. منهنجي مشين تي، سادو شيون ٺاهڻ ۽ تباهه ڪرڻ جو وقت لڳ ڀڳ 5.6 نانو سيڪنڊ آهي.
   فائنلائزر شامل ڪرڻ وقت وڌائي ٿو 2400 نانو سيڪنڊن تائين. ٻين لفظن ۾، اهو لڳ ڀڳ 430 ڀيرا سست هوندو آهي هڪ شئي ٺاهڻ ۽ ختم ڪرڻ لاءِ حتمي ساز سان.

هش ميپ کي گھڻن موضوعن واري ماحول ۾ ڇو نه استعمال ڪيو وڃي؟ ڇا اهو هڪ لامحدود لوپ سبب ٿي سگهي ٿو؟

اسان ڄاڻون ٿا ته HashMapهي هڪ غير هم وقت سازي مجموعو آهي، جنهن جو هم وقت سازي آهي HashTable. تنهن ڪري، جڏهن توهان هڪ مجموعو تائين رسائي ڪري رهيا آهيو ۽ گهڻن موضوعن واري ماحول ۾ جتي سڀني موضوعن کي گڏ ڪرڻ جي هڪ واحد مثال تائين رسائي آهي، پوء اهو HashTableواضح سببن لاء استعمال ڪرڻ لاء محفوظ آهي، جهڙوڪ گندي پڙهڻ کان بچڻ ۽ ڊيٽا جي تسلسل کي يقيني بڻائڻ. بدترين صورت ۾، هي گهڻ موضوع وارو ماحول هڪ لامحدود لوپ جو سبب بڻجندو. ها اهو سچ آهي. HashMap.get()هڪ لامحدود لوپ سبب ٿي سگهي ٿو. اچو ته ڏسون ڪيئن؟ جيڪڏهن توهان طريقي جي ماخذ ڪوڊ تي نظر ڪريو ٿا HashMap.get(Object key)، اهو هن طرح نظر اچي ٿو:

public Object get(Object key) {
    Object k = maskNull(key);
    int hash = hash(k);
    int i = indexFor(hash, table.length);
    Entry e = table[i];
    while (true) {
        if (e == null)
            return e;
        if (e.hash == hash && eq(k, e.key))
            return e.value;
        e = e.next;
    }
}

while(true)ھميشه ھڪ لامحدود لوپ جو شڪار ٿي سگھي ٿو ھڪڙي گھڻن موضوعن واري رن ٽائم ماحول ۾ جيڪڏھن ڪنھن سبب جي ڪري e.nextاھو پاڻ ڏانھن اشارو ڪري سگھي ٿو. اهو هڪ لامحدود لوپ جو سبب بڻجندو، پر e.nextاهو ڪيئن پاڻ ڏانهن اشارو ڪندو (يعني، ڏانهن e)؟ اهو ٿي سگهي ٿو هڪ طريقي سان void transfer(Entry[] newTable)جنهن کي سڏيو ويندو آهي جڏهن ان کي HashMapتبديل ڪيو پيو وڃي.

do {
    Entry next = e.next;
    int i = indexFor(e.hash, newCapacity);
    e.next = newTable[i];
    newTable[i] = e;
    e = next;
} while (e != null);

ڪوڊ جو هي ٽڪرو هڪ لامحدود لوپ ٺاهڻ جو امڪان آهي جيڪڏهن ٻيهر سائيز ساڳئي وقت ٿئي ٿي ته ٻيو ٿريڊ نقشي جي مثال کي تبديل ڪرڻ جي ڪوشش ڪري رهيو آهي ( HashMap). هن منظرنامي کان بچڻ جو واحد طريقو اهو آهي ته توهان جي ڪوڊ ۾ هم وقت سازي کي استعمال ڪيو وڃي، يا اڃا بهتر، هڪ هم وقت ساز ٿيل مجموعو استعمال ڪريو.

وضاحت ڪريو تجريد ۽ انڪپسوليشن. اهي ڪيئن ڳنڍيل آهن؟

سادي لفظن ۾ ، " Abstraction ڪنهن شئي جي صرف انهن خاصيتن کي ڏيکاري ٿو جيڪي موجوده ڏسڻ لاء اهم آهن . " اعتراض تي مبني پروگرامنگ جي نظريي ۾، تجريد ۾ شيون بيان ڪرڻ جي صلاحيت شامل آهي جيڪي خلاصا "اداڪار" جي نمائندگي ڪن ٿا جيڪي ڪم ڪري سگهن ٿا، تبديل ڪري سگهن ٿا ۽ انهن جي حالت ۾ تبديلين جي رپورٽ ڪن ٿا، ۽ سسٽم ۾ ٻين شين سان "تعلق" سان. ڪنهن به پروگرامنگ ٻولي ۾ Abstraction ڪيترن ئي طريقن سان ڪم ڪري ٿو. اهو ڏسي سگهجي ٿو روٽين جي تخليق کان وٺي گهٽ سطح جي ٻولي حڪمن لاءِ انٽرفيس کي بيان ڪرڻ لاءِ. ڪجهه تجريد پروگرامر جي ضرورتن جي مجموعي نمائندگي جي حد تائين محدود ڪرڻ جي ڪوشش ڪندا آهن مڪمل طور تي انهن خلاصن کي لڪائڻ جي ذريعي جن تي اهي ٺهيل آهن، جهڙوڪ ڊزائن جا نمونا. عام طور تي، تجريد کي ٻن طريقن سان ڏسي سگھجي ٿو: ڊيٽا خلاصو پيچيده ڊيٽا جي قسمن کي ٺاهڻ جو هڪ طريقو آهي ۽ ڊيٽا ماڊل سان لهه وچڙ ڪرڻ لاء صرف بامعني عملن کي ظاهر ڪرڻ، جڏهن ته ساڳئي وقت ٻاهرئين دنيا کان سڀني عملن جي تفصيل کي لڪايو. Execution abstraction سڀني اهم بيانن کي سڃاڻڻ ۽ انهن کي ڪم يونٽ جي طور تي ظاهر ڪرڻ جو عمل آهي. اسان عام طور تي هي خصوصيت استعمال ڪندا آهيون جڏهن اسان ڪجهه ڪم ڪرڻ جو طريقو ٺاهيندا آهيون. ڪلاسن اندر ڊيٽا ۽ طريقن کي محدود ڪرڻ سان گڏ پرفارمنگ لڪائڻ (پهچ ڪنٽرول استعمال ڪندي) اڪثر ڪري encapsulation سڏيو ويندو آهي. نتيجو هڪ ڊيٽا جو قسم آهي خاصيتن ۽ رويي سان. Encapsulation لازمي طور تي ڊيٽا کي لڪائڻ ۽ عمل درآمد کي لڪائڻ ۾ شامل آهي. "هر شي کي شامل ڪريو جيڪو تبديل ڪري سگهي ٿو" . هي اقتباس هڪ مشهور ٺهيل اصول آهي. انهي معاملي لاء، ڪنهن به طبقي ۾، ڊيٽا تبديلين کي رن ٽائم تي ٿي سگهي ٿو ۽ مستقبل جي نسخن ۾ عملدرآمد تبديليون ٿي سگهن ٿيون. اهڙيء طرح، encapsulation ٻنهي ڊيٽا ۽ عمل درآمد تي لاڳو ٿئي ٿو. تنهن ڪري اهي هن طرح ڳنڍيل ٿي سگهن ٿا:

• خلاصو گهڻو ڪري اهو آهي ته هڪ طبقو ڇا ڪري سگهي ٿو [Idea]
• Encapsulation وڌيڪ آهي هن ڪارڪردگي کي ڪيئن حاصل ڪجي [عمل درآمد]

انٽرفيس ۽ تجريدي طبقي جي وچ ۾ فرق؟

مکيه اختلاف هيٺ ڏنل فهرست ڪري سگهجي ٿو:

• هڪ انٽرفيس ڪنهن به طريقن کي لاڳو نٿو ڪري سگهي، پر هڪ خلاصو طبقو ڪري سگهي ٿو.
• هڪ طبقو ڪيترن ئي انٽرفيس کي لاڳو ڪري سگهي ٿو، پر صرف هڪ سپر ڪلاس رکي سگهي ٿو (خلاصو يا غير خلاصو)
• هڪ انٽرفيس هڪ طبقي جي درجه بندي جو حصو نه آهي. غير لاڳاپيل طبقن ساڳئي انٽرفيس کي لاڳو ڪري سگھن ٿا.

جيڪو توهان کي ياد رکڻو آهي اهو آهي: "جڏهن توهان مڪمل طور تي وضاحت ڪري سگهو ٿا "اهو ڇا ڪري ٿو" جي اصطلاحن ۾ تصور کي بيان ڪرڻ جي بغير "اهو ڪيئن ڪري ٿو"، پوء توهان کي هڪ انٽرفيس استعمال ڪرڻ گهرجي. جيڪڏهن توهان کي ڪجهه عمل درآمد جي تفصيل شامل ڪرڻ جي ضرورت آهي، ته پوء توهان کي پنهنجي تصور کي هڪ تجريدي طبقي ۾ نمائندگي ڪرڻ جي ضرورت آهي. انهي سان گڏ، ان کي ٻئي طريقي سان رکڻ لاء: ڇا اهڙا ڪيترائي طبقا آهن جيڪي "گڏجي گڏ" ٿي سگهن ٿا ۽ هڪ واحد اسم طرفان بيان ڪيل آهن؟ جيڪڏهن ائين آهي ته، هن اسم جي نالي سان هڪ خلاصو طبقو ٺاهيو، ۽ ان مان ورثي وارا طبقا. مثال طور، Cat۽ Dogخلاصي طبقي مان ورثي ۾ ملي سگهي ٿو Animal، ۽ هي خلاصو بنيادي طبقو طريقو لاڳو ڪندو void Breathe()- سانس، جنهن کي سڀئي جانور اهڙيء طرح انجام ڏيندا. ڪھڙا فعل منھنجي طبقي تي لاڳو ٿي سگھن ٿا ۽ ٻين تي لاڳو ڪري سگھجن ٿا؟ انهن فعلن مان هر هڪ لاءِ انٽرفيس ٺاهيو. مثال طور، سڀ جانور کائي سگهن ٿا، تنهنڪري مان هڪ انٽرفيس ٺاهيندس IFeedable۽ ان کي Animalان انٽرفيس تي عمل ڪرڻ ڏيندس. صرف هڪ انٽرفيس کي لاڳو ڪرڻ لاء ڪافي سٺو Dog( مون کي پسند ڪرڻ جي قابل)، پر سڀ نه. ڪنهن چيو: بنيادي فرق اهو آهي جتي توهان چاهيو ٿا توهان جي عمل درآمد. جڏهن توهان هڪ انٽرفيس ٺاهي سگهو ٿا، توهان عمل درآمد کي ڪنهن به طبقي ڏانهن منتقل ڪري سگهو ٿا جيڪو توهان جي انٽرفيس کي لاڳو ڪري ٿو. خلاصو ڪلاس ٺاهڻ سان، توهان سڀني نڪتل طبقن جي نفاذ کي هڪ جاءِ تي شيئر ڪري سگهو ٿا ۽ ڪيترن ئي خراب شين کان پاسو ڪري سگهو ٿا جهڙوڪ نقل ڪرڻ واري ڪوڊ. HorseILikeable

StringBuffer ميموري کي ڪيئن بچائيندو؟

ڪلاس کي Stringهڪ ناقابل بدلي شئي جي طور تي لاڳو ڪيو ويو آهي، مطلب ته جڏهن توهان شروعاتي طور تي ڪنهن شيءِ کي اعتراض ۾ وجهڻ جو فيصلو ڪيو ٿا String، ورچوئل مشين هڪ مقرر ڊگھائي صف کي مختص ڪري ٿي بلڪل توهان جي اصل قدر جي سائيز. اهو پوءِ ورچوئل مشين جي اندر هڪ مستقل طور سمجهيو ويندو، جيڪو هڪ اهم ڪارڪردگي بهتري فراهم ڪري ٿو جيڪڏهن اسٽرنگ جي قيمت تبديل نه ٿئي. بهرحال، جيڪڏهن توهان ڪنهن به طريقي سان اسٽرنگ جي مواد کي تبديل ڪرڻ جو فيصلو ڪيو ٿا، مجازي مشين اصل ۾ اصل اسٽرنگ جي مواد کي عارضي اسپيس ۾ نقل ڪري ٿي، پنهنجون تبديليون ڪريو، پوء انهن تبديلين کي نئين ميموري صف ۾ محفوظ ڪريو. اهڙيءَ طرح، شروعات کان پوءِ اسٽرنگ جي قيمت ۾ تبديلي ڪرڻ هڪ قيمتي آپريشن آهي. StringBufferٻئي طرف، مجازي مشين جي اندر متحرڪ طور تي وڌائڻ واري صف جي طور تي لاڳو ڪيو ويو آهي، جنهن جو مطلب آهي ته ڪنهن به ترميمي آپريشن موجوده ميموري سيل تي ٿي سگهي ٿي ۽ نئين ياداشت کي گهربل طور تي مختص ڪيو ويندو. بهرحال، ورچوئل مشين لاءِ اصلاح ڪرڻ جو ڪو طريقو ناهي StringBufferڇو ته ان جو مواد هر مثال ۾ متضاد سمجهيو ويندو آهي.

ٿريڊ جي بدران Object ڪلاس ۾ انتظار ۽ اطلاع جا طريقا ڇو بيان ڪيا ويا آهن؟

wait, notify, طريقن کي notifyAllصرف ان صورت ۾ گهربل آهي جڏهن توهان چاهيو ٿا ته توهان جي موضوعن کي حصيداري وسيلن تائين رسائي حاصل ڪئي وڃي ۽ حصيداري وسيلن جي هيپ ۾ ڪنهن به جاوا اعتراض ٿي سگهي ٿو. اهڙيء طرح، اهي طريقا بيس ڪلاس تي بيان ڪيا ويا آهن Objectته جيئن هر شئي تي هڪ ڪنٽرول هجي جيڪا موضوعن کي انهن جي مانيٽر تي انتظار ڪرڻ جي اجازت ڏئي ٿي. جاوا وٽ ڪا خاص شئي ناهي جيڪا گڏيل وسيلن کي شيئر ڪرڻ لاءِ استعمال ٿئي. اهڙي ڊيٽا جي جوڙجڪ جي وضاحت نه ڪئي وئي آهي. تنهن ڪري، اها طبقي جي ذميواري آهي Objectته هو هڪ گڏيل وسيلو بڻجڻ جي قابل ٿي، ۽ مددگار طريقا مهيا ڪن جهڙوڪ wait(), notify(), notifyAll(). جاوا مانيٽر جي چارلس هوئر جي خيال تي ٻڌل آهي. جاوا ۾، سڀني شين کي هڪ مانيٽر آهي. سلسلا مانيٽر تي انتظار ڪن ٿا، تنهنڪري انتظار ڪرڻ لاء اسان کي ٻن پيٽرولن جي ضرورت آهي:

• هڪ ڌاڳو
• مانيٽر (ڪنهن به اعتراض).

جاوا ڊيزائن ۾، هڪ سلسلي کي واضح طور تي بيان نه ٿو ڪري سگهجي؛ اهو هميشه موجوده ٿريڊ آهي جيڪو ڪوڊ تي عمل ڪري رهيو آهي. بهرحال، اسان هڪ مانيٽر جي وضاحت ڪري سگهون ٿا (جيڪو هڪ اعتراض آهي جنهن تي اسان هڪ طريقو سڏي سگهون ٿا wait). هي هڪ سٺي ڊيزائن آهي ڇاڪاڻ ته جيڪڏهن اسان ڪنهن ٻئي ٿريڊ کي مجبور ڪري سگهون ٿا ته هڪ مخصوص مانيٽر تي انتظار ڪرڻ لاءِ، ان جي نتيجي ۾ "انفريشن" ٿيندو، متوازي پروگرامن جي ڊيزائننگ/پروگرامنگ کي ڏکيو بنائڻ. ياد رهي ته جاوا ۾، سڀئي عمل جيڪي مداخلت ڪن ٿا ٻين موضوعن سان ختم ٿيل آهن (مثال طور، stop()).

جاوا ۾ بند لاڪ ٺاهڻ لاءِ پروگرام لکو ۽ ان کي درست ڪريو

جاوا ۾ deadlock، اها هڪ صورتحال آهي جتي گهٽ ۾ گهٽ ٻه موضوع مختلف وسيلن تي هڪ بلاڪ رکون ٿا، ۽ ٻئي پنهنجي ڪم کي مڪمل ڪرڻ لاء ٻئي وسيلن جي دستياب ٿيڻ جي انتظار ۾ آهن. ۽ انهن مان ڪو به ان قابل ناهي ته هو رکيل وسيلن تي تالا ڇڏي وڃي. مثال پروگرام:

package thread;

public class ResolveDeadLockTest {

	public static void main(String[] args) {
		ResolveDeadLockTest test = new ResolveDeadLockTest();

		final A a = test.new A();
		final B b = test.new B();

		// Thread-1
		Runnable block1 = new Runnable() {
			public void run() {
				synchronized (a) {
					try {
					// Добавляем задержку, чтобы обе нити могли начать попытки
					// блокирования ресурсов
						Thread.sleep(100);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
					// Thread-1 заняла A но также нуждается в B
					synchronized (b) {
						System.out.println("In block 1");
					}
				}
			}
		};

		// Thread-2
		Runnable block2 = new Runnable() {
			public void run() {
				synchronized (b) {
					// Thread-2 заняла B но также нуждается в A
					synchronized (a) {
						System.out.println("In block 2");
					}
				}
			}
		};

		new Thread(block1).start();
		new Thread(block2).start();
	}

	// Resource A
	private class A {
		private int i = 10;

		public int getI() {
			return i;
		}

		public void setI(int i) {
			this.i = i;
		}
	}

	// Resource B
	private class B {
		private int i = 20;

		public int getI() {
			return i;
		}

		public void setI(int i) {
			this.i = i;
		}
	}
}

مٿي ڏنل ڪوڊ کي هلائڻ جي نتيجي ۾ تمام واضع سببن لاءِ بند لاڪ ٿيندو (مٿي بيان ڪيو ويو). هاڻي اسان کي هن مسئلي کي حل ڪرڻ جي ضرورت آهي. مان سمجهان ٿو ته ڪنهن به مسئلي جو حل ان مسئلي جي پاڙ ۾ ئي هوندو آهي. اسان جي صورت ۾، A ۽ B تائين رسائي ماڊل بنيادي مسئلو آهي. تنهن ڪري، ان کي حل ڪرڻ لاء، اسان صرف ترتيب ڏيڻ جي رسائي آپريٽرز کي حصيداري وسيلن ڏانهن تبديل ڪريون ٿا. تبديلي کان پوء ان کي هن طرح نظر ايندي:

// Thread-1
Runnable block1 = new Runnable() {
	public void run() {
		synchronized (b) {
			try {
				// Добавляем задержку, чтобы обе нити могли начать попытки
				// блокирования ресурсов
				Thread.sleep(100);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			// Thread-1 заняла B но также нуждается в А
			synchronized (a) {
				System.out.println("In block 1");
			}
		}
	}
};

// Thread-2
Runnable block2 = new Runnable() {
	public void run() {
		synchronized (b) {
			// Thread-2 заняла B но также нуждается в А
			synchronized (a) {
				System.out.println("In block 2");
			}
		}
	}
};

هن ڪلاس کي ٻيهر هلايو ۽ هاڻي توهان کي تعطل نظر نه ايندو. مون کي اميد آهي ته هي توهان جي مدد ڪري ٿي ڊيڊ لاڪ کان بچڻ ۽ انهن مان نجات حاصل ڪريو جيڪڏهن توهان انهن سان منهن ڪيو.

ڇا ٿيندو جيڪڏهن توهان جو ڪلاس جيڪو سيريلائيبل انٽرفيس کي لاڳو ڪري ٿو ان ۾ غير سيريلائيبل جزو شامل آهي؟ هن کي ڪيئن ٺيڪ ڪرڻ لاء؟

NotSerializableExceptionهن معاملي ۾، ان کي عملدرآمد دوران اڇلايو ويندو . هن مسئلي کي حل ڪرڻ لاء، اتي هڪ تمام سادو حل آهي - چيڪ ڪريو اهي باڪس transient. هن جو مطلب آهي ته چيڪ ٿيل فيلڊ سيريل نه ڪيا ويندا. جيڪڏهن توهان انهن شعبن جي حالت کي پڻ ذخيرو ڪرڻ چاهيو ٿا، ته پوء توهان کي ريفرنس متغير تي غور ڪرڻو پوندو، جيڪي اڳ ۾ ئي Serializable. توھان کي شايد استعمال ڪرڻ جي ضرورت پوندي readResolve()۽ طريقا writeResolve(). اچو ته اختصار ڪريون:

• پهرين، پنهنجي فيلڊ کي غير سيريلائيبل ٺاهيو transient.
• سڀ کان پهريان writeObject، defaultWriteObjectسڀني نان فيلڊز کي محفوظ ڪرڻ لاءِ ٿريڊ تي ڪال ڪريو transient، پوءِ باقي طريقن کي ڪال ڪريو پنھنجي غير سيريلائيبل شئي جي انفرادي ملڪيتن کي سيريل ڪرڻ لاءِ.
• ان ۾ readObject، سڀ کان پهرين ڪال ڪريو defaultReadObjectاسٽريم تي سڀني غير transientشعبن کي پڙهڻ لاءِ، پوءِ ڪال ڪريو ٻين طريقن سان (جيڪي توهان شامل ڪيا آهن انهن سان لاڳاپيل writeObject) توهان جي غير اعتراض کي ختم ڪرڻ لاءِ transient.

وضاحت ڪريو Transient and volatile keywords in Java

"اهڙا لفظ transientاستعمال ڪيا ويندا آهن انهن شعبن کي ظاهر ڪرڻ لاءِ جيڪي سيريل نه ڪيا ويندا." جاوا ٻوليءَ جي وضاحت جي مطابق: متغيرن کي عارضي اشاري سان نشان لڳايو وڃي ٿو ته جيئن ظاهر ٿئي ته اهي اعتراض جي مستقل حالت جو حصو نه آهن. مثال طور، توھان ٻين شعبن مان نڪتل شعبن تي مشتمل ٿي سگھو ٿا، ۽ اھو ترجيح آھي انھن کي حاصل ڪرڻ بجاءِ پروگرام جي لحاظ کان پنھنجي حالت کي سيريلائيزيشن ذريعي بحال ڪرڻ جي. مثال طور، هڪ طبقي ۾، BankPayment.javaشعبن جهڙوڪ principal(ڊائريڪٽر) ۽ rate(شرح) کي سيريلائيز ڪري سگهجي ٿو، ۽ interest(جمع ڪيل دلچسپي) ڪنهن به وقت حساب ڪري سگهجي ٿو، جيتوڻيڪ ڊيسيريلائيزيشن کان پوءِ. جيڪڏهن اسان کي ياد آهي ته، جاوا ۾ هر سلسلي جي پنهنجي مقامي ياداشت آهي ۽ هن مقامي ياداشت تي پڙهڻ/لکڻ جا عمل انجام ڏئي ٿي. جڏهن سڀئي عمل ڪيا ويندا آهن، اهو لکندو آهي تبديل ٿيل حالت متغير جي گڏيل ميموري ۾، جتان سڀئي موضوعن تائين رسائي ڪن ٿا. عام طور تي، هي هڪ ورچوئل مشين اندر هڪ عام موضوع آهي. پر volatile modifier ورچوئل مشين کي ٻڌائي ٿو ته ھڪڙي ٿريڊ جي پھچ ان متغير تائين ھميشه ان متغير جي پنھنجي ڪاپي کي ميموري ۾ موجود متغير جي ماسٽر ڪاپي سان ملائڻ گھرجي. هن جو مطلب آهي ته هر دفعي هڪ ٿريڊ هڪ متغير جي حالت پڙهڻ چاهي ٿي، ان کي اندروني ميموري اسٽيٽ کي صاف ڪرڻ گهرجي ۽ متغير کي مين ميموري مان اپڊيٽ ڪرڻ گهرجي. Volatileلاڪ فري الگورتھم ۾ سڀ کان وڌيڪ مفيد. توھان ھڪڙي متغير کي نشان لڳايو، حصيداري ڪيل ڊيٽا کي غير مستحڪم طور تي محفوظ ڪري، پوء توھان ان متغير تائين رسائي حاصل ڪرڻ لاء لاڪ استعمال نه ڪندا، ۽ ھڪڙي سلسلي ۾ ڪيل سڀ تبديليون ٻين کي نظر اينديون. يا جيڪڏھن توھان چاھيو ٿا "ٿيڻ کان پوءِ" تعلق پيدا ڪرڻ لاءِ پڪ ڪرڻ لاءِ ته حسابن کي بار بار نه ڪيو وڃي، ٻيهر يقيني بڻائڻ لاءِ تبديليون اصل وقت ۾ نظر اچن ٿيون. Volatile استعمال ڪيو وڃي محفوظ طور تي غير متحرڪ شيون شايع ڪرڻ لاءِ گھڻن موضوعن واري ماحول ۾. فيلڊ جي اعلان کي public volatile ImmutableObjectيقيني بڻائي ٿو ته سڀئي موضوع هميشه مثال جي موجوده حوالي سان ڏسندا آهن.

Iterator ۽ ListIterator جي وچ ۾ فرق؟

اسان استعمال ڪري سگھون ٿا ، يا Iteratorعناصرن کي ٻيهر ڏيڻ لاء . پر اهو صرف استعمال ڪري سگهجي ٿو عناصر مٿان ٻيهر ڪرڻ لاءِ . ٻيا اختلاف هيٺ بيان ڪيا ويا آهن. توهان ڪري سگهو ٿا: SetListMapListIteratorList

1. ريورس ترتيب ۾ ورجائي.
2. ڪٿي به انڊيڪس حاصل ڪريو.
3. ڪٿي به قيمت شامل ڪريو.
4. موجوده پوزيشن تي ڪا به قيمت مقرر ڪريو.

توهان جي پڙهائي سان سٺي قسمت !! مضمون جو ليکڪ لوڪيش گپتا اصل مضمون جاوا ڪور. انٽرويو سوال، حصو 1 جاوا ڪور. انٽرويو لاءِ سوال، حصو 3