جاوا ڈویلپر کی پوزیشن کے لیے نوکری کے انٹرویو سے سوالات اور جوابات تلاش کرنا۔ حصہ 12

ہائے! علم طاقت ہے. اپنے پہلے انٹرویو میں آپ کے پاس جتنا زیادہ علم ہوگا، اتنا ہی زیادہ اعتماد آپ محسوس کریں گے۔ اگر آپ علم سے بھرا ہوا بڑا دماغ لاتے ہیں، تو آپ کے انٹرویو لینے والے کو آپ کو الجھانے میں مشکل پیش آئے گی اور اس کے لیے خوشگوار حیرت کا امکان ہے۔ لہذا مزید اڈو کے بغیر، آج ہم جاوا ڈویلپر کے لیے سوالات کا جائزہ لے کر آپ کی نظریاتی بنیاد کو مضبوط کرنا جاری رکھیں گے۔

103. وراثت کے دوران استثنیٰ کی جانچ پر کون سے اصول لاگو ہوتے ہیں؟

اگر میں سوال کو صحیح طور پر سمجھتا ہوں، تو وہ وراثت کے دوران مستثنیات کے ساتھ کام کرنے کے قواعد کے بارے میں پوچھ رہے ہیں۔ متعلقہ قوانین درج ذیل ہیں:

• ڈیسنڈنٹ/عمل درآمد میں اوور رائیڈڈ یا لاگو شدہ طریقہ چیک شدہ مستثنیات کو نہیں پھینک سکتا جو سپر کلاس/انٹرفیس طریقہ میں مستثنیات سے زیادہ درجہ بندی میں ہیں۔

مثال کے طور پر، فرض کریں کہ ہمارے پاس ایک ایسے طریقہ کے ساتھ کچھ Animal انٹرفیس ہے جو IOException پھینکتا ہے :

public interface Animal {
   void speak() throws IOException;
}

اس انٹرفیس کو لاگو کرتے وقت، ہم زیادہ عام پھینکنے کے قابل استثناء کو سامنے نہیں لا سکتے (مثلاً Exception , Throwable )، لیکن ہم موجودہ استثنا کو ذیلی طبقے سے بدل سکتے ہیں، جیسے FileNotFoundException :

public class Cat implements Animal {
   @Override
   public void speak() throws FileNotFoundException {
// Some implementation
   }
}

• سب کلاس کنسٹرکٹر کے تھرو کلاز میں سپر کلاس کنسٹرکٹر کے ذریعہ پھینکی گئی تمام استثنائی کلاسیں شامل ہونی چاہئیں جنہیں آبجیکٹ بنانے کے لیے بلایا گیا ہے۔

فرض کریں کہ اینیمل کلاس کا کنسٹرکٹر بہت زیادہ مستثنیات پھینکتا ہے:

public class Animal {
  public Animal() throws ArithmeticException, NullPointerException, IOException {
  }

پھر ایک ذیلی کلاس کنسٹرکٹر کو بھی انہیں پھینکنا ہوگا:

public class Cat extends Animal {
   public Cat() throws ArithmeticException, NullPointerException, IOException {
       super();
   }

یا، طریقوں کے ساتھ، آپ مختلف، زیادہ عام استثناء کی وضاحت کر سکتے ہیں۔ ہمارے معاملے میں، ہم Exception کی نشاندہی کر سکتے ہیں ، کیونکہ یہ زیادہ عام ہے اور سپر کلاس میں اشارہ کردہ تینوں مستثنیات کا مشترکہ اجداد ہے:

public class Cat extends Animal {
   public Cat() throws Exception {
       super();
   }

104. کیا آپ کوئی ایسا کوڈ لکھ سکتے ہیں جہاں آخر میں بلاک پر عمل نہ ہو؟

سب سے پہلے، یاد رکھیں کہ آخر کیا ہے؟ اس سے پہلے، ہم نے استثنیٰ کیچنگ میکانزم کا جائزہ لیا: ایک ٹرائی بلاک یہ بتاتا ہے جہاں استثناء کو پکڑا جائے گا، اور کیچ بلاک (زبانیں) وہ کوڈ ہیں جو متعلقہ استثناء کے پکڑے جانے پر استعمال کیے جائیں گے۔ کوڈ کا ایک تیسرا بلاک جس کو آخر میں مطلوبہ الفاظ سے نشان زد کیا گیا ہے وہ کیچ بلاکس کی جگہ لے سکتا ہے یا اس کے بعد آ سکتا ہے۔ اس بلاک کے پیچھے خیال یہ ہے کہ اس کے کوڈ کو ہمیشہ عمل میں لایا جاتا ہے اس سے قطع نظر کہ کسی کوشش یا کیچ بلاک میں کیا ہوتا ہے ( قطع نظر اس کے کہ کوئی استثناء ہے یا نہیں)۔ مثالیں، جہاں اس بلاک پر عمل نہیں کیا جاتا ہے وہ غیر معمولی ہیں اور وہ غیر معمولی ہیں۔ سب سے آسان مثال یہ ہے کہ جب System.exit(0) کو آخر میں بلاک کرنے سے پہلے بلایا جاتا ہے، اس طرح پروگرام کو ختم کیا جاتا ہے:

try {
   throw new IOException();
} catch (IOException e) {
   System.exit(0);
} finally {
   System.out.println("This message will not be printed on the console");
}

کچھ دوسرے حالات بھی ہیں جہاں آخر میں بلاک نہیں چلے گا:

• مثال کے طور پر، نظام کی اہم خرابیوں کی وجہ سے غیر معمولی پروگرام کا خاتمہ، یا کچھ خرابی جو ایپلیکیشن کے کریش ہونے کا سبب بنتی ہے (مثال کے طور پر، StackOverflowError ، جو اس وقت ہوتا ہے جب ایپلیکیشن اسٹیک اوور فلو ہو جاتا ہے)۔

• ایک اور صورتحال یہ ہے کہ جب ڈیمون تھریڈ ٹرائی اینڈ بلاک میں داخل ہوتا ہے، لیکن پھر پروگرام کا مین تھریڈ ختم ہو جاتا ہے۔ بہر حال، ڈیمون تھریڈز پس منظر کے کام کے لیے ہیں جو اعلیٰ ترجیح یا لازمی نہیں ہے، اس لیے ایپلیکیشن ان کے ختم ہونے کا انتظار نہیں کرے گی۔

• سب سے ذہین مثال ایک کوشش یا کیچ بلاک کے اندر ایک نہ ختم ہونے والا لوپ ہے — ایک بار اندر جانے کے بعد، ایک دھاگہ ہمیشہ کے لیے وہاں پھنس جائے گا:

  try {
     while (true) {
     }
  } finally {
     System.out.println("This message will not be printed on the console");
  }

یہ سوال جونیئر ڈویلپر کے انٹرویوز میں بہت مقبول ہے، اس لیے ان میں سے کچھ غیر معمولی حالات کو یاد رکھنا اچھا خیال ہے۔

105. ایک مثال لکھیں جہاں آپ ایک ہی کیچ بلاک میں متعدد مستثنیات کو ہینڈل کرتے ہیں۔

1) مجھے یقین نہیں ہے کہ یہ سوال صحیح طریقے سے پوچھا گیا تھا۔ جہاں تک میں سمجھتا ہوں، یہ سوال کئی کیچ بلاکس اور ایک ہی کوشش کا حوالہ دے رہا ہے :

try {
  throw new FileNotFoundException();
} catch (FileNotFoundException e) {
   System.out.print("Oops! There was an exception: " + e);
} catch (IOException e) {
   System.out.print("Oops! There was an exception: " + e);
} catch (Exception e) {
   System.out.print("Oops! There was an exception: " + e);
}

اگر ٹرائی بلاک میں کوئی استثناء پھینکا جاتا ہے، تو متعلقہ کیچ بلاکس اسے پکڑنے کی کوشش کرتے ہیں، ترتیب وار اوپر سے نیچے تک۔ ایک بار استثناء کیچ بلاکس میں سے کسی ایک سے مماثل ہونے کے بعد، کوئی بھی باقی بلاک اسے پکڑنے اور سنبھالنے کے قابل نہیں رہے گا۔ اس سب کا مطلب یہ ہے کہ کیچ بلاکس کے سیٹ میں زیادہ عام مستثنیات کے اوپر تنگ مستثنیات ترتیب دی گئی ہیں ۔ مثال کے طور پر، اگر ہمارا پہلا کیچ بلاک Exception کلاس کو پکڑتا ہے ، تو اس کے بعد کے بلاکس چیک شدہ استثناء کو نہیں پکڑیں ​​گے (یعنی، Exception کے ذیلی طبقات کے ساتھ باقی بلاکس بالکل بیکار ہوں گے)۔ 2) یا شاید سوال صحیح پوچھا گیا تھا۔ اس صورت میں، ہم مندرجہ ذیل مستثنیات کو سنبھال سکتے ہیں:

try {
  throw new NullPointerException();
} catch (Exception e) {
   if (e instanceof FileNotFoundException) {
       // Some handling that involves a narrowing type conversion: (FileNotFoundException)e
   } else if (e instanceof ArithmeticException) {
       // Some handling that involves a narrowing type conversion: (ArithmeticException)e
   } else if(e instanceof NullPointerException) {
       // Some handling that involves a narrowing type conversion: (NullPointerException)e
   }

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

106. کون سا آپریٹر آپ کو استثنیٰ پر مجبور کرنے دیتا ہے؟ ایک مثال لکھیں۔

میں نے پہلے ہی اسے اوپر کی مثالوں میں کئی بار استعمال کیا ہے، لیکن میں اسے ایک بار پھر دہراؤں گا: تھرو کی ورڈ۔ دستی طور پر ایک استثناء پھینکنے کی مثال:

throw new NullPointerException();

107. کیا بنیادی طریقہ استثناء دے سکتا ہے؟ اگر ایسا ہے تو پھر کہاں جاتا ہے؟

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

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

اس کے مطابق، یہ استثناء پھینک سکتا ہے. جب main کو پروگرام کے نقطہ آغاز کے طور پر کہا جاتا ہے (بجائے کہ کسی اور طریقے سے)، تو اس کے ذریعے پھینکی جانے والی کسی بھی رعایت کو UncaughtExceptionHandler کے ذریعے ہینڈل کیا جائے گا ۔ ہر تھریڈ میں ایک ایسا ہینڈلر ہوتا ہے (یعنی ہر تھریڈ میں ایک ایسا ہینڈلر ہوتا ہے)۔ اگر ضروری ہو تو، آپ اپنا ہینڈلر بنا سکتے ہیں اور عوامی جامد باطل مین(String[] args) تھرو IOException {setDefaultUncaughtExceptionHandler طریقہ عوامی جامد void main(String[] args) تھرو IOException {تھریڈ آبجیکٹ پر کال کرکے اسے سیٹ کرسکتے ہیں۔

ملٹی تھریڈنگ

108. ملٹی تھریڈ والے ماحول میں کام کرنے کا کون سا طریقہ کار آپ جانتے ہیں؟

جاوا میں ملٹی تھریڈنگ کے بنیادی طریقہ کار یہ ہیں:

• مطابقت پذیر کلیدی لفظ، جو کہ تھریڈ کے داخل ہونے پر کسی طریقہ/بلاک کو لاک کرنے کا ایک طریقہ ہے، دوسرے تھریڈز کو داخل ہونے سے روکتا ہے۔

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

• رن ایبل - ہم اس انٹرفیس کو نافذ کر سکتے ہیں (جو ایک ہی رن () طریقہ پر مشتمل ہے ) کچھ کلاس میں:

  public class CustomRunnable implements Runnable {
     @Override
     public void run() {
         // Some logic
     }
  }

  اور ایک بار جب ہم اس کلاس کا کوئی آبجیکٹ بناتے ہیں، تو ہم اپنا آبجیکٹ تھریڈ کنسٹرکٹر کو دے کر اور پھر start() طریقہ کو کال کرکے ایک نیا تھریڈ شروع کر سکتے ہیں ۔

  Runnable runnable = new CustomRunnable();
  new Thread(runnable).start();

  شروع کا طریقہ ایک الگ تھریڈ پر نافذ شدہ run() طریقہ کو چلاتا ہے۔

• تھریڈ - ہم اس کلاس کو وراثت میں لے سکتے ہیں اور اس کے چلانے کے طریقہ کو اوور رائیڈ کر سکتے ہیں:

  public class CustomThread extends Thread {
     @Override
     public void run() {
         // Some logic
     }
  }

  ہم اس کلاس کا ایک آبجیکٹ بنا کر اور پھر start() طریقہ کو کال کرکے ایک نیا تھریڈ شروع کر سکتے ہیں۔

  new CustomThread().start();

• ہم آہنگی - یہ کثیر تھریڈ ماحول میں کام کرنے کے لیے ٹولز کا ایک پیکج ہے۔

  یہ مشتمل ہے:

  • کنکرنٹ کلیکشنز - یہ ان مجموعوں کا مجموعہ ہے جو واضح طور پر ملٹی تھریڈ ماحول میں کام کرنے کے لیے بنایا گیا ہے۔

  • قطاریں — کثیر تھریڈ ماحول کے لیے مخصوص قطاریں (بلاکنگ اور نان بلاکنگ)۔

  • سنکرونائزرز - یہ ملٹی تھریڈڈ ماحول میں کام کرنے کے لیے خصوصی یوٹیلیٹیز ہیں۔

  • ایگزیکیوٹرز - تھریڈ پول بنانے کا طریقہ کار۔

  • تالے - تھریڈ سنکرونائزیشن میکانزم جو معیاری سے زیادہ لچکدار ہیں (مطابقت پذیر، انتظار کریں، مطلع کریں، سبھی کو مطلع کریں)۔

  • ایٹمکس - ملٹی تھریڈنگ کے لیے موزوں کلاسز۔ ان کا ہر عمل ایٹمی ہے۔

109. ہمیں تھریڈز کے درمیان ہم آہنگی کے بارے میں بتائیں۔ انتظار()، نوٹیفائی()، نوٹیفائی آل()، اور جوائن() کے طریقے کیا ہیں؟

دھاگوں کے درمیان مطابقت پذیری مطابقت پذیر مطلوبہ الفاظ کے بارے میں ہے۔ یہ ترمیم کنندہ یا تو براہ راست بلاک پر رکھا جا سکتا ہے:

synchronized (Main.class) {
   // Some logic
}

یا براہ راست طریقہ کے دستخط میں:

public synchronized void move() {
   // Some logic }

جیسا کہ میں نے پہلے کہا، مطابقت پذیری ایک دھاگہ داخل ہونے کے بعد دوسرے تھریڈز کو بلاک/طریقہ بند کرنے کا طریقہ کار ہے۔ آئیے ایک کوڈ بلاک/طریقہ کو ایک کمرے کے طور پر سوچتے ہیں۔ کچھ دھاگہ کمرے کے قریب آتا ہے، اس میں داخل ہوتا ہے، اور اپنی چابی سے دروازہ بند کر دیتا ہے۔ جب دوسرے دھاگے کمرے کے قریب آتے ہیں، تو وہ دیکھتے ہیں کہ دروازہ بند ہے اور کمرے کے دستیاب ہونے تک قریب ہی انتظار کریں۔ ایک بار جب پہلا دھاگہ کمرے میں اپنے کاروبار کے ساتھ مکمل ہو جاتا ہے، تو یہ دروازہ کھول دیتا ہے، کمرے سے نکل جاتا ہے، اور چابی جاری کر دیتا ہے۔ میں نے ایک وجہ کے لئے ایک دو بار ایک کلید کا ذکر کیا ہے - کیونکہ کچھ یکساں واقعی موجود ہے۔ یہ ایک خاص چیز ہے جس کی مصروف/آزاد حالت ہے۔ جاوا میں ہر شے میں ایسی چیز ہوتی ہے، لہذا جب ہم مطابقت پذیر بلاک استعمال کرتے ہیں، تو ہمیں اس چیز کی نشاندہی کرنے کے لیے قوسین استعمال کرنے کی ضرورت ہوتی ہے جس کا mutex مقفل ہو جائے گا:

Cat cat = new Cat();
synchronized (cat) {
   // Some logic
}

ہم کلاس کے ساتھ منسلک ایک mutex بھی استعمال کر سکتے ہیں، جیسا کہ میں نے پہلی مثال ( Main.class ) میں کیا تھا۔ سب کے بعد، جب ہم کسی طریقہ پر مطابقت پذیری کا استعمال کرتے ہیں، تو ہم اس چیز کی وضاحت نہیں کرتے ہیں جسے ہم لاک کرنا چاہتے ہیں، ٹھیک ہے؟ اس صورت میں، غیر جامد طریقوں کے لیے، mutex جو مقفل ہو جائے گا وہ یہ آبجیکٹ ہے، یعنی کلاس کا موجودہ آبجیکٹ۔ جامد طریقوں کے لیے، موجودہ کلاس ( this.getClass(); ) سے وابستہ mutex مقفل ہے۔ wait() ایک ایسا طریقہ ہے جو mutex کو آزاد کرتا ہے اور موجودہ دھاگے کو انتظار کی حالت میں رکھتا ہے، جیسے کہ موجودہ مانیٹر سے منسلک ہو (اینکر کی طرح کچھ)۔ اس کی وجہ سے، یہ طریقہ صرف مطابقت پذیر بلاک یا طریقہ سے بلایا جا سکتا ہے . بصورت دیگر، یہ کس چیز کا انتظار کرے گا اور کس چیز کو جاری کیا جائے گا؟) یہ بھی نوٹ کریں کہ یہ آبجیکٹ کلاس کا ایک طریقہ ہے۔ ٹھیک ہے، ایک نہیں، لیکن تین:

• wait() موجودہ تھریڈ کو انتظار کی حالت میں رکھتا ہے جب تک کہ دوسرا تھریڈ اس اعتراض پر notify() یا notifyAll() طریقہ کو کال نہیں کرتا ہے (ہم ان طریقوں کے بارے میں بعد میں بات کریں گے)۔

• wait(لمبی ٹائم آؤٹ) موجودہ تھریڈ کو انتظار کی حالت میں رکھتا ہے جب تک کہ کوئی دوسرا تھریڈ اس آبجیکٹ پر notify() یا notifyAll() طریقہ کو کال نہ کرے یا ٹائم آؤٹ کے ذریعہ بیان کردہ وقت کا وقفہ ختم نہ ہوجائے۔

• wait (لمبی ٹائم آؤٹ، int nanos) پچھلے طریقہ کی طرح ہے، لیکن یہاں nanos آپ کو نینو سیکنڈز (ایک زیادہ درست ٹائم آؤٹ) بتانے دیتا ہے۔

• notify() آپ کو موجودہ مطابقت پذیری بلاک پر انتظار کر رہے ایک بے ترتیب دھاگے کو جگانے دیتا ہے۔ ایک بار پھر، یہ طریقہ صرف ایک مطابقت پذیر بلاک یا طریقہ کار میں بلایا جا سکتا ہے (آخر، دوسری جگہوں پر جاگنے والا کوئی نہیں ہوگا)۔

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

110. ہم دھاگے کو کیسے روک سکتے ہیں؟

یہاں کہنے کی پہلی بات یہ ہے کہ جب run() مکمل ہونے پر چلتا ہے تو تھریڈ خود بخود ختم ہوجاتا ہے۔ لیکن بعض اوقات ہم ایک دھاگے کو شیڈول سے پہلے ختم کرنا چاہتے ہیں، طریقہ کار مکمل ہونے سے پہلے۔ تو ہم کیا کریں؟ شاید ہم Thread آبجیکٹ پر stop() طریقہ استعمال کر سکتے ہیں ؟ Nope کیا! وہ طریقہ فرسودہ ہے اور سسٹم کریش کا سبب بن سکتا ہے۔ ٹھیک ہے، پھر کیا؟ ایسا کرنے کے دو طریقے ہیں: پہلا ، اس کا اندرونی بولین پرچم استعمال کریں۔ آئیے ایک مثال دیکھتے ہیں۔ ہمارے پاس ایک تھریڈ کا نفاذ ہے جس میں ایک خاص جملہ اسکرین پر ظاہر ہونا چاہیے جب تک کہ تھریڈ مکمل طور پر بند نہ ہو جائے:

public class CustomThread extends Thread {
private boolean isActive;

   public CustomThread() {
       this.isActive = true;
   }

   @Override
   public void run() {
       {
           while (isActive) {
               System.out.println("The thread is executing some logic...");
           }
           System.out.println("The thread stopped!");
       }
   }

   public void stopRunningThread() {
       isActive = false;
   }
}

stopRunningThread() طریقہ کو کال کرنے سے اندرونی پرچم غلط ہو جاتا ہے، جس کی وجہ سے run() طریقہ ختم ہو جاتا ہے۔ آئیے اسے مین میں کہتے ہیں :

System.out.println("Program starting...");
CustomThread thread = new CustomThread();
thread.start();
Thread.sleep(3);
// As long as our main thread is asleep, our CustomThread runs and prints its message on the console
thread.stopRunningThread();
System.out.println("Program stopping...");

نتیجے کے طور پر، ہم کنسول میں کچھ اس طرح دیکھیں گے: اس کا مطلب ہے کہ ہمارا تھریڈ شروع ہوا، کنسول پر کئی پیغامات پرنٹ کیے، اور پھر کامیابی کے ساتھ بند ہو گئے۔ نوٹ کریں کہ دکھائے گئے پیغامات کی تعداد لانچ سے لانچ تک مختلف ہوگی۔ اور بعض اوقات معاون دھاگہ کچھ بھی ظاہر نہیں کرسکتا ہے۔ مخصوص رویہ اس بات پر منحصر ہے کہ مرکزی دھاگہ کتنی دیر تک سوتا ہے۔ یہ جتنی دیر سوتا ہے، اتنا ہی کم امکان ہوتا ہے کہ معاون تھریڈ کچھ بھی ظاہر کرنے کا انتظام نہیں کرے گا۔ 1 ایم ایس کے سونے کے وقت کے ساتھ، آپ تقریباً کبھی بھی پیغامات نہیں دیکھ پائیں گے۔ لیکن اگر آپ اسے 20 ms پر سیٹ کرتے ہیں، تو پیغامات تقریباً ہمیشہ ظاہر ہوتے ہیں۔ جب نیند کا وقت کم ہوتا ہے تو دھاگے کے پاس اپنا کام شروع کرنے اور کرنے کا وقت نہیں ہوتا۔ اس کے بجائے، یہ فوری طور پر روک دیا جاتا ہے. دوسرا طریقہ Thread آبجیکٹ پر interrupted() طریقہ استعمال کرنا ہے ۔ یہ اندرونی مداخلت والے جھنڈے کی قدر لوٹاتا ہے، جو ڈیفالٹ کے لحاظ سے غلط ہے۔ یا اس کا interrupt() طریقہ، جو اس جھنڈے کو سچ پر سیٹ کرتا ہے (جب جھنڈا سچ ہے تو تھریڈ کو چلنا بند کر دینا چاہیے)۔ آئیے ایک مثال دیکھتے ہیں:

public class CustomThread extends Thread {

   @Override
   public void run() {
       {
           while (!Thread.interrupted()) {
               System.out.println("The thread is executing some logic...");
           }
           System.out.println("The thread stopped!");
       }
   }
}

مین میں چل رہا ہے :

System.out.println("Program starting...");
Thread thread = new CustomThread();
thread.start();
Thread.sleep(3);
thread.interrupt();
System.out.println("Program stopping...");

اس کو چلانے کا نتیجہ وہی ہے جیسا کہ پہلی صورت میں ہے، لیکن مجھے یہ نقطہ نظر زیادہ پسند ہے: ہم نے کم کوڈ لکھا اور زیادہ تیار شدہ، معیاری فعالیت کا استعمال کیا۔ ٹھیک ہے، یہ آج کے لئے ہے!