جاوا کور۔ انٹرویو کے سوالات، حصہ 2

جو لوگ جاوا کور کا لفظ پہلی بار سنتے ہیں ان کے لیے یہ زبان کی بنیادی بنیادیں ہیں۔ اس علم کے ساتھ، آپ محفوظ طریقے سے انٹرن شپ/انٹرن شپ کے لیے جا سکتے ہیں۔ یہ سوالات آپ کو انٹرویو سے پہلے اپنے علم کو تازہ کرنے یا اپنے لیے کچھ نیا سیکھنے میں مدد کریں گے۔ عملی مہارت حاصل کرنے کے لیے، JavaRush میں مطالعہ کریں ۔ اصل مضمون دوسرے حصوں کے لنکس: جاوا کور۔ انٹرویو کے سوالات، حصہ 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()اگر یہ طریقہ آپ کی کلاس میں موجود ہے تو آپ کو ایک اہم کارکردگی کا نشانہ بھی ملتا ہے ۔ Effective Programming (2nd ed.) میں، Joshua Bloch نے کہا:
   "ہاں، اور ایک چیز: فائنلائزرز کا استعمال کرتے وقت کارکردگی کا ایک بڑا جرمانہ ہے۔ میری مشین پر، سادہ اشیاء کو بنانے اور تباہ کرنے کا وقت تقریباً 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) کو تبدیل کرنے کی کوشش کر رہا ہے۔ اس منظر نامے سے بچنے کا واحد طریقہ یہ ہے کہ اپنے کوڈ میں ہم وقت سازی کا استعمال کریں، یا اس سے بھی بہتر، مطابقت پذیر مجموعہ استعمال کریں۔

تجرید اور انکیپسولیشن کی وضاحت کریں۔ وہ کیسے جڑے ہوئے ہیں؟

سادہ الفاظ میں ، '' تجرید کسی چیز کی صرف وہی خصوصیات دکھاتا ہے جو موجودہ منظر کے لیے اہم ہیں ۔ '' آبجیکٹ اورینٹڈ پروگرامنگ تھیوری میں، تجرید میں ایسی اشیاء کی وضاحت کرنے کی صلاحیت شامل ہوتی ہے جو تجریدی "اداکاروں" کی نمائندگی کرتے ہیں جو کام انجام دے سکتے ہیں، اپنی حالت میں تبدیلی اور رپورٹ کرسکتے ہیں، اور نظام میں موجود دیگر اشیاء کے ساتھ "تعلق" کرسکتے ہیں۔ کسی بھی پروگرامنگ زبان میں تجرید کئی طریقوں سے کام کرتا ہے۔ یہ کم سطحی زبان کے حکموں کے لیے انٹرفیس کی وضاحت کے لیے معمولات کی تخلیق سے دیکھا جا سکتا ہے۔ کچھ تجریدات ان تجریدوں کو مکمل طور پر چھپا کر پروگرامر کی ضروریات کی مجموعی نمائندگی کی وسعت کو محدود کرنے کی کوشش کرتے ہیں جن پر وہ بنائے گئے ہیں، جیسے کہ ڈیزائن کے نمونے۔ عام طور پر، تجرید کو دو طریقوں سے دیکھا جا سکتا ہے: ڈیٹا خلاصہ پیچیدہ ڈیٹا کی قسمیں بنانے اور ڈیٹا ماڈل کے ساتھ تعامل کرنے کے لیے صرف بامعنی کارروائیوں کو ظاہر کرنے کا ایک طریقہ ہے، جبکہ ایک ہی وقت میں تمام نفاذ کی تفصیلات کو بیرونی دنیا سے چھپاتا ہے۔ ایگزیکیوشن خلاصہ تمام اہم بیانات کی نشاندہی کرنے اور انہیں کام کی اکائی کے طور پر ظاہر کرنے کا عمل ہے۔ ہم عام طور پر اس خصوصیت کو استعمال کرتے ہیں جب ہم کچھ کام کرنے کا طریقہ بناتے ہیں۔ کلاسوں کے اندر ڈیٹا اور طریقوں کو چھپانے (ایکسیس کنٹرول کا استعمال کرتے ہوئے) کے ساتھ مل کر محدود کرنا اکثر انکیپسولیشن کہلاتا ہے۔ نتیجہ خصوصیات اور رویے کے ساتھ ڈیٹا کی قسم ہے۔ Encapsulation میں بنیادی طور پر ڈیٹا کو چھپانا اور نفاذ کو چھپانا بھی شامل ہے۔ "ہر چیز کو سمیٹ لیں جو بدل سکتا ہے" ۔ یہ اقتباس ایک معروف ڈیزائن اصول ہے۔ اس معاملے کے لیے، کسی بھی کلاس میں، ڈیٹا کی تبدیلیاں رن ٹائم کے وقت ہو سکتی ہیں اور نفاذ میں تبدیلیاں مستقبل کے ورژن میں ہو سکتی ہیں۔ اس طرح، encapsulation کا اطلاق ڈیٹا اور نفاذ دونوں پر ہوتا ہے۔ لہذا وہ اس طرح منسلک ہوسکتے ہیں:

• خلاصہ زیادہ تر وہ ہے جو ایک کلاس کر سکتا ہے [آئیڈیا]
• Encapsulation زیادہ ہے اس فعالیت کو کیسے حاصل کیا جائے [عمل درآمد]

انٹرفیس اور خلاصہ کلاس کے درمیان فرق؟

اہم اختلافات کو مندرجہ ذیل کے طور پر درج کیا جا سکتا ہے:

• ایک انٹرفیس کسی بھی طریقے کو نافذ نہیں کر سکتا، لیکن ایک خلاصہ کلاس کر سکتا ہے۔
• ایک کلاس بہت سے انٹرفیس کو نافذ کر سکتی ہے، لیکن اس میں صرف ایک سپر کلاس ہو سکتا ہے (خلاصہ یا غیر خلاصہ)
• انٹرفیس کلاس کے درجہ بندی کا حصہ نہیں ہے۔ غیر متعلقہ کلاسیں ایک ہی انٹرفیس کو نافذ کرسکتی ہیں۔

آپ کو جو یاد رکھنا ہے وہ یہ ہے: "جب آپ کسی تصور کو "یہ کیا کرتا ہے" کے لحاظ سے مکمل طور پر بیان کر سکتے ہیں "یہ کیسے کرتا ہے" کی وضاحت کیے بغیر، تو آپ کو ایک انٹرفیس استعمال کرنا چاہیے۔ اگر آپ کو عمل درآمد کی کچھ تفصیلات شامل کرنے کی ضرورت ہے، تو آپ کو ایک تجریدی کلاس میں اپنے تصور کی نمائندگی کرنے کی ضرورت ہے۔" اس کے علاوہ، اسے دوسرے طریقے سے ڈالیں: کیا بہت ساری کلاسیں ہیں جن کو "ایک ساتھ گروپ" کیا جاسکتا ہے اور ایک اسم کے ذریعہ بیان کیا جاسکتا ہے؟ اگر ایسا ہے تو، اس اسم کے نام کے ساتھ ایک تجریدی کلاس بنائیں، اور اس سے کلاسیں حاصل کریں۔ مثال کے طور پر، Catاور Dogabstract class سے وراثت میں مل سکتا ہے Animal، اور یہ خلاصہ بیس کلاس طریقہ void Breathe()- سانس لینے پر عمل درآمد کرے گا، جسے تمام جانور اسی طرح انجام دیں گے۔ کون سے فعل میری کلاس پر لاگو ہوسکتے ہیں اور دوسروں پر لاگو ہوسکتے ہیں؟ ان میں سے ہر ایک فعل کے لیے ایک انٹرفیس بنائیں۔ مثال کے طور پر، تمام جانور کھا سکتے ہیں، اس لیے میں ایک انٹرفیس بناؤں گا IFeedableاور اسے Animalاس انٹرفیس کو نافذ کروں گا۔ صرف ایک انٹرفیس کو لاگو کرنے کے لئے کافی اچھا ہے Dog( مجھے پسند کرنے کے قابل)، لیکن سب نہیں. کسی نے کہا: بنیادی فرق یہ ہے کہ آپ اپنا نفاذ کہاں چاہتے ہیں۔ جب آپ ایک انٹرفیس بناتے ہیں، تو آپ نفاذ کو کسی بھی کلاس میں منتقل کر سکتے ہیں جو آپ کے انٹرفیس کو نافذ کرتا ہے۔ ایک خلاصہ کلاس بنا کر، آپ تمام اخذ کردہ کلاسوں کے نفاذ کو ایک جگہ پر شیئر کر سکتے ہیں اور کوڈ کو ڈپلیکیٹ کرنے جیسی بہت سی بری چیزوں سے بچ سکتے ہیں۔ HorseILikeable

StringBuffer میموری کو کیسے بچاتا ہے؟

کلاس کو Stringایک ناقابل تغیر آبجیکٹ کے طور پر لاگو کیا جاتا ہے، اس کا مطلب ہے کہ جب آپ ابتدائی طور پر کسی چیز کو آبجیکٹ میں ڈالنے کا فیصلہ کرتے ہیں String، تو ورچوئل مشین آپ کی اصل قدر کے سائز کے عین مطابق ایک مقررہ لمبائی والی صف مختص کرتی ہے۔ اس کے بعد اسے ورچوئل مشین کے اندر ایک مستقل سمجھا جائے گا، جو سٹرنگ کی قدر تبدیل نہ ہونے کی صورت میں کارکردگی میں نمایاں بہتری فراہم کرتا ہے۔ تاہم، اگر آپ کسی بھی طرح سے کسی سٹرنگ کے مواد کو تبدیل کرنے کا فیصلہ کرتے ہیں، تو ورچوئل مشین اصل میں اصل سٹرنگ کے مواد کو عارضی جگہ میں کاپی کرتی ہے، اپنی تبدیلیاں کرتی ہے، پھر ان تبدیلیوں کو ایک نئی میموری سرنی میں محفوظ کرتی ہے۔ اس طرح، ابتدا کے بعد سٹرنگ کی قدر میں تبدیلی کرنا ایک مہنگا آپریشن ہے۔ StringBufferدوسری طرف، ورچوئل مشین کے اندر متحرک طور پر پھیلتی ہوئی صف کے طور پر لاگو کیا جاتا ہے، جس کا مطلب یہ ہے کہ کسی بھی ترمیمی عمل موجودہ میموری سیل پر ہو سکتا ہے اور ضرورت کے مطابق نئی میموری مختص کی جائے گی۔ تاہم، ورچوئل مشین کے لیے اصلاح کرنے کا کوئی طریقہ نہیں ہے StringBufferکیونکہ اس کے مواد کو ہر ایک مثال میں متضاد سمجھا جاتا ہے۔

آبجیکٹ کلاس میں تھریڈ کے بجائے انتظار اور اطلاع کے طریقوں کا اعلان کیوں کیا جاتا ہے؟

wait, notify, طریقوں کی notifyAllضرورت صرف اس وقت ہوتی ہے جب آپ چاہتے ہیں کہ آپ کے تھریڈز کو مشترکہ وسائل تک رسائی حاصل ہو اور مشترکہ وسائل ہیپ میں موجود کوئی بھی جاوا آبجیکٹ ہو سکتا ہے۔ اس طرح، ان طریقوں کی وضاحت بیس کلاس پر کی گئی ہے Objectتاکہ ہر آبجیکٹ کا ایک کنٹرول ہو جو تھریڈز کو اپنے مانیٹر پر انتظار کرنے کی اجازت دیتا ہے۔ جاوا میں کوئی خاص چیز نہیں ہے جو مشترکہ وسائل کو شیئر کرنے کے لیے استعمال ہوتی ہے۔ اس طرح کے ڈیٹا ڈھانچے کی وضاحت نہیں کی گئی ہے۔ لہذا، یہ کلاس کی ذمہ داری ہے Objectکہ وہ ایک مشترکہ وسیلہ بننے کے قابل ہو، اور مددگار طریقے فراہم کرے جیسے کہ wait(), notify(), notifyAll()۔ جاوا چارلس ہوئر کے مانیٹر کے خیال پر مبنی ہے۔ جاوا میں تمام اشیاء کا مانیٹر ہوتا ہے۔ دھاگے مانیٹر پر انتظار کرتے ہیں، لہذا انتظار کرنے کے لیے ہمیں دو پیرامیٹرز کی ضرورت ہوتی ہے:

• ایک دھاگہ
• مانیٹر (کوئی بھی چیز)۔

جاوا ڈیزائن میں، ایک دھاگے کی قطعی وضاحت نہیں کی جا سکتی؛ یہ ہمیشہ موجودہ تھریڈ ہوتا ہے جو کوڈ پر عمل کرتا ہے۔ تاہم، ہم ایک مانیٹر کی وضاحت کر سکتے ہیں (جو ایک ایسی چیز ہے جس پر ہم ایک طریقہ کہہ سکتے ہیں wait)۔ یہ ایک اچھا ڈیزائن ہے کیونکہ اگر ہم کسی دوسرے تھریڈ کو ایک مخصوص مانیٹر پر انتظار کرنے پر مجبور کر سکتے ہیں، تو اس کے نتیجے میں "حملہ" ہو جائے گا، جس سے متوازی پروگراموں کی ڈیزائننگ/پروگرامنگ مشکل ہو جائے گی۔ یاد رکھیں کہ جاوا میں، تمام آپریشنز جو دوسرے تھریڈز میں مداخلت کرتے ہیں فرسودہ ہیں (مثال کے طور پر، stop())۔

جاوا میں تعطل پیدا کرنے اور اسے ٹھیک کرنے کے لیے ایک پروگرام لکھیں۔

Java میں 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ان شعبوں کی نشاندہی کرنے کے لیے استعمال ہوتا ہے جو سیریلائز نہیں کیے جائیں گے۔" جاوا زبان کی تفصیلات کے مطابق: متغیرات کو عارضی اشارے سے نشان زد کیا جا سکتا ہے تاکہ یہ ظاہر کیا جا سکے کہ وہ آبجیکٹ کی مستقل حالت کا حصہ نہیں ہیں۔ مثال کے طور پر، آپ دوسرے فیلڈز سے اخذ کردہ فیلڈز پر مشتمل ہو سکتے ہیں، اور سیریلائزیشن کے ذریعے ان کی حالت کو بحال کرنے کے بجائے انہیں پروگرام کے مطابق حاصل کرنا بہتر ہے۔ مثال کے طور پر، ایک کلاس میں، (ڈائریکٹر) اور (ریٹ) BankPayment.javaجیسے شعبوں کو سیریلائز کیا جا سکتا ہے، اور (جمع شدہ سود) کو کسی بھی وقت، ڈی سیریلائزیشن کے بعد بھی شمار کیا جا سکتا ہے۔ اگر ہمیں یاد ہے تو جاوا میں ہر تھریڈ کی اپنی مقامی میموری ہوتی ہے اور وہ اس لوکل میموری پر پڑھنے/لکھنے کے کام انجام دیتی ہے۔ جب تمام آپریشنز ہو جاتے ہیں، تو یہ متغیر کی تبدیل شدہ حالت کو مشترکہ میموری میں لکھتا ہے، جہاں سے تمام تھریڈز متغیر تک رسائی حاصل کرتے ہیں۔ عام طور پر، یہ ورچوئل مشین کے اندر ایک عام دھاگہ ہوتا ہے۔ لیکن volatile modifier ورچوئل مشین کو بتاتا ہے کہ تھریڈ کی اس متغیر تک رسائی ہمیشہ اس متغیر کی اپنی کاپی کے ساتھ میموری میں متغیر کی ماسٹر کاپی کے ساتھ ہونی چاہیے۔ اس کا مطلب یہ ہے کہ جب بھی کوئی تھریڈ کسی متغیر کی حالت کو پڑھنا چاہتا ہے، اسے اندرونی میموری کی حالت کو صاف کرنا ہوگا اور مین میموری سے متغیر کو اپ ڈیٹ کرنا ہوگا۔ لاک فری الگورتھم میں سب سے زیادہ مفید۔ آپ مشترکہ ڈیٹا کو ذخیرہ کرنے والے متغیر کو غیر مستحکم کے بطور نشان زد کرتے ہیں، پھر آپ اس متغیر تک رسائی کے لیے تالے کا استعمال نہیں کرتے ہیں، اور ایک تھریڈ سے کی گئی تمام تبدیلیاں دوسروں کو دکھائی دیں گی۔ یا اگر آپ اس بات کو یقینی بنانے کے لیے کہ حسابات کو دہرایا نہ جائے، پھر سے تبدیلیاں حقیقی وقت میں نظر آنے کو یقینی بنانے کے لیے "ہپےنڈ آفٹر" تعلق بنانا چاہتے ہیں۔ غیر متغیر اشیاء کو کثیر دھاگے والے ماحول میں محفوظ طریقے سے شائع کرنے کے لیے اتار چڑھاؤ کا استعمال کیا جانا چاہیے۔ فیلڈ ڈیکلریشن اس بات کو یقینی بناتا ہے کہ تمام تھریڈز ہمیشہ مثال کے لیے دستیاب حوالہ دیکھیں۔ principalrateinterestVolatilepublic volatile ImmutableObject

Iterator اور ListIterator کے درمیان فرق؟

ہم استعمال کر سکتے ہیں ، یا Iteratorعناصر پر اعادہ کرنے کے لیے ۔ لیکن یہ صرف عناصر پر تکرار کرنے کے لیے استعمال کیا جا سکتا ہے ۔ دیگر اختلافات ذیل میں بیان کیے گئے ہیں۔ آپ کر سکتے ہیں: SetListMapListIteratorList

1. معکوس ترتیب میں اعادہ کریں۔
2. کہیں بھی انڈیکس حاصل کریں۔
3. کہیں بھی کوئی قدر شامل کریں۔
4. موجودہ پوزیشن پر کوئی بھی قدر مقرر کریں۔

آپ کی تعلیم کے ساتھ گڈ لک!! مضمون کے مصنف لوکیش گپتا اصل مضمون جاوا کور۔ انٹرویو کے سوالات، حصہ 1 جاوا کور۔ انٹرویو کے لیے سوالات، حصہ 3