تھریڈ ڈمپ کو پڑھنے اور اپنی ایپلیکیشن کے رن ٹائم رویے کو کنٹرول کرنے کا طریقہ سیکھیں۔

جب آپ کا Adobe Experience Manager (یا عام طور پر کوئی JAVA ایپلیکیشن) مثال میں سستی کے آثار دکھاتا ہے، تو یہ وقت ہے کہ آپ اپنی آستینیں لپیٹیں اور دھاگوں کے ڈمپ کی دنیا میں ڈوب جائیں۔ IBM تھریڈ اینالائزر (TDA) دھاگوں کے جال کو حل کرنے اور کارکردگی کی رکاوٹوں کی نشاندہی کرنے میں آپ کی مدد کرنے کے لیے حاضر ہے۔ اس گائیڈ میں، ہم آپ کو بتائیں گے کہ IBM TDA کو AEM میں کارکردگی کے مسائل کی تشخیص کے لیے کس طرح استعمال کیا جائے۔

مرحلہ 1: IBM TDA ڈاؤن لوڈ اور انسٹال کریں۔

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

مرحلہ 2: اپنے AEM مثال سے تھریڈ ڈمپ کیپچر کریں۔

تھریڈ ڈمپ ایک مخصوص لمحے پر آپ کے AEM مثال میں چلنے والے تمام تھریڈز کے سنیپ شاٹس ہیں۔ ان کو پکڑنے کے لیے:

1. اپنے AEM سرور تک رسائی حاصل کریں۔
2. تھریڈ ڈمپ بنانے کے لیے jstack ، kill -3 ، یا AEM کی بلٹ ان فعالیت جیسے ٹولز کا استعمال کریں۔ Adobe Docs پر ایک اچھی طرح سے دستاویزی صفحہ ہے۔
3. تھریڈ ڈمپ فائلوں کو اپنی مقامی مشین میں محفوظ کریں۔

پرو ٹِپ: طویل عرصے سے چلنے والے مسائل کی واضح تصویر حاصل کرنے کے لیے وقفوں پر (مثلاً، ہر 10 سیکنڈ میں) متعدد تھریڈ ڈمپ کیپچر کریں۔

مرحلہ 3: IBM TDA میں تھریڈ ڈمپ کھولیں۔

IBM TDA لانچ کریں اور تھریڈ ڈمپ فائلوں کو کھولیں جو آپ نے کیپچر کی ہیں۔ بس فائلوں کو ایپلیکیشن میں گھسیٹیں اور چھوڑیں یا انہیں لوڈ کرنے کے لیے "اوپن" آپشن کا استعمال کریں۔ لوڈ ہونے کے بعد، آپ کو بائیں ہاتھ کے پینل پر تھریڈ ڈمپ کی فہرست نظر آئے گی۔

مرحلہ 4: تھریڈ کی تفصیلات میں غوطہ لگائیں۔

ایک مخصوص تھریڈ ڈمپ کا تجزیہ کرنے کے لیے:

1. فہرست سے فائل کو منتخب کریں۔
2. سب سے اوپر تھریڈ ڈیٹیل بٹن پر کلک کریں۔

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

مرحلہ 5: دلچسپی کے موضوعات کی شناخت کریں۔

10 لائنوں یا اس سے زیادہ لمبی گہرائی والے دھاگوں پر فوکس کریں۔ یہ تھریڈز عام طور پر سب سے زیادہ وسائل استعمال کرنے والے ہوتے ہیں۔ کسی بھی تھریڈز پر نوٹ لیں جو نمایاں ہوں — چاہے ان کے ناموں، ریاستوں یا اسٹیک ٹریس کی وجہ سے ہوں۔

مرحلہ 6: تھریڈ اسٹیٹ کے لحاظ سے ترتیب دیں۔

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

• بیک گراؤنڈ جاب تھریڈز: انڈیکسنگ یا نقل جیسے کاموں کو ہینڈل کرنا۔
• تھریڈز کی درخواست کریں: 127.0.0.1 [timestamp] GET /path HTTP/1.1 طرح نام دیا گیا ہے۔

مرحلہ 7: درخواست کے ٹائم اسٹیمپ کو ڈی کوڈ کریں۔

ہر درخواست کے سلسلے کے لیے، اس کے نام سے ٹائم اسٹیمپ نکالیں (مثلاً، 1347028187737 )۔ یہ یونکس دور کا ٹائم اسٹیمپ آپ کو بتاتا ہے کہ صارف کے براؤزر نے کب درخواست کی تھی۔ https://www.epochconverter.com/ جیسے ٹول کا استعمال کرتے ہوئے اسے انسانی پڑھنے کے قابل تاریخ/وقت میں تبدیل کریں۔ اس کا موازنہ تھریڈ ڈمپ کے ٹائم اسٹیمپ سے کریں تاکہ حساب لگ سکے کہ درخواست کتنی دیر سے فعال ہے۔

اگر فرق غیر معمولی طور پر بڑا ہے (مثلاً، کئی سیکنڈ یا منٹ)، تو یہ آپ کی درخواست میں رکاوٹ کی نشاندہی کر سکتا ہے۔

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

مرحلہ 8: انتظار کے سلسلے کی چھان بین کریں۔

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

تھریڈ اسٹیٹس کو سمجھنا

TDA میں دھاگوں کی جانچ کرتے وقت، آپ کو کئی اہم حالتوں کا سامنا کرنا پڑے گا:

چلانے کے قابل : یہ تھریڈز یا تو فی الحال ایگزیکیویٹ ہو رہے ہیں یا CPU ٹائم دستیاب ہونے پر عمل کرنے کے لیے تیار ہیں۔ رن ایبل اسٹیٹ ضروری طور پر کسی مسئلے کی نشاندہی نہیں کرتی ہے - یہ فعال طور پر کام کرنے والے تھریڈز کے لیے قدرتی حالت ہے۔

انتظار کرنا : ان تھریڈز نے کسی شرط کے پورا ہونے کا انتظار کرتے ہوئے عمل درآمد کو عارضی طور پر روک دیا ہے۔ انتظار کی حالت کئی جائز وجوہات کی بناء پر ہو سکتی ہے، بشمول:

• وسائل کی دستیابی (ڈیٹا بیس کنکشن، فائل ہینڈل)
• دوسرے دھاگوں میں کام کی تکمیل
• طے شدہ تاخیر
• نیٹ ورک I/O کی تکمیل
• پیغام کی قطار کی کارروائیاں

مسدود : یہ تھریڈز خاص طور پر مانیٹر یا لاک حاصل کرنے کے منتظر ہیں۔ انتظار کی طرح، مسدود ریاستیں خاص طور پر مطابقت پذیری سے متعلق وقفوں کی نشاندہی کرتی ہیں۔

دھاگے کے تعلقات کا تجزیہ کرنا

جب آپ دلچسپی کے دھاگے کی شناخت کرتے ہیں، تو اس منظم طریقہ کو استعمال کرتے ہوئے دوسرے دھاگوں کے ساتھ اس کے تعلقات کا جائزہ لیں:

1. براہ راست لاک تعلقات:

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

2. وسائل کے استعمال کے نمونے:

• وسائل کے حصول اور رہائی میں نمونے تلاش کریں۔
• ممکنہ وسائل کی رکاوٹوں کی نشاندہی کریں۔
• متبادل وسائل کے انتظام کی حکمت عملیوں پر غور کریں۔

3. تعمیراتی اثرات:

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

لاک کی اقسام اور مرئیت کو سمجھنا

تھریڈ ڈمپ ہر قسم کے تنازعات کو نہیں دکھا سکتے ہیں۔ جدید جاوا ایپلی کیشنز مختلف ہم آہنگی کے طریقہ کار کا استعمال کرتی ہیں:

1. اندرونی تالے (مطابقت پذیر مطلوبہ الفاظ):

• تھریڈ ڈمپ میں نظر آتا ہے۔
• واضح مالک ویٹر تعلقات دکھائیں۔
• اسٹیک کے نشانات مطابقت پذیری پوائنٹس کی نشاندہی کرتے ہیں۔

2. واضح تالے (java.util.concurrent):

• ReentrantLock
• ReadWriteLock
• سٹیمپڈ لاک
• تصور کرنے کے لیے اضافی ٹولنگ کی ضرورت پڑ سکتی ہے۔

3. نان بلاکنگ میکانزم (روایتی تالے کے طور پر ظاہر نہیں ہوتے ہیں لیکن کارکردگی کو متاثر کر سکتے ہیں):

• جوہری متغیرات
• کنکرنٹ ہیش میپ
• مکمل مستقبل

اصلاح کی حکمت عملی

جب آپ حقیقی تنازعات کی نشاندہی کرتے ہیں، تو ان طریقوں پر غور کریں:

1. کوڈ کی سطح میں بہتری

• تالا کا دائرہ کم کریں۔
• باریک دانوں والے لاکنگ کو لاگو کریں۔
• غیر مسدود متبادل پر غور کریں۔

2. وسائل کا انتظام

• پول کے سائز کو بہتر بنائیں
• بیک آف حکمت عملی کو نافذ کریں۔
• کیشنگ کے حل پر غور کریں۔

3. تعمیراتی تبدیلیاں

• غیر مطابقت پذیر پروسیسنگ کا اندازہ کریں۔
• متوازی عملدرآمد کے راستوں پر غور کریں۔
• قطار پر مبنی طریقوں کو نافذ کریں۔

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

مرحلہ 9: طویل عرصے سے چلنے والے تھریڈز کے لیے ایک سے زیادہ تھریڈ ڈمپ کا موازنہ کریں۔

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

اس بات کا تعین کرنے کے لیے کہ آیا کوئی دھاگہ ہر وقت برقرار رہتا ہے:

1. وقت میں مختلف پوائنٹس سے متعدد تھریڈ ڈمپ منتخب کریں۔
2. IBM TDA میں تھریڈز کا موازنہ کریں بٹن پر کلک کریں۔
3. ایسے دھاگوں کی تلاش کریں جو تمام ڈمپوں میں چلنے کے قابل حالت میں رہیں، خاص طور پر وہ دھاگوں کے ساتھ جو مستقل طور پر لمبے ڈھیر کے نشانات رکھتے ہیں۔

مختلف ٹائم پوائنٹس سے ڈمپ کا تجزیہ کرنے کے لیے IBM TDA کی کمپیئر تھریڈز فیچر استعمال کریں۔ ان تھریڈز پر توجہ مرکوز کریں جو متعدد ڈمپوں میں برقرار رہتے ہیں، ان کی حالتوں، اسٹیک کی گہرائیوں اور وسائل کے استعمال کا جائزہ لیتے ہیں۔ یاد رکھیں کہ صرف تھریڈ کا استقامت خود بخود کسی مسئلے کی نشاندہی نہیں کرتا ہے — پس منظر کی خدمات قدرتی طور پر مسلسل چلتی ہیں، جبکہ درخواست کے تھریڈز کو متوقع ٹائم فریم میں مکمل ہونا چاہیے۔

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

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

ایک بار جب آپ کو یقین ہو جائے کہ آپ نے کارکردگی کا ایک حقیقی مجرم پکڑا ہے (یقیناً ٹھوس ثبوت کے ساتھ)، اسے ٹھیک کرنے کا وقت آگیا ہے۔

مرحلہ 10: مانیٹر کی تفصیلات دریافت کریں اور بیکار دھاگوں کی شناخت کریں۔

اگر تھریڈز کا تجزیہ کرنے سے قابل عمل بصیرت حاصل نہیں ہوتی ہے تو مانیٹر ڈیٹیل ویو پر جائیں:

1. دھاگے کی فہرست پر واپس جائیں۔
2. تھریڈ ڈمپ کو منتخب کریں اور مانیٹر ڈیٹیل بٹن پر کلک کریں۔
3. IBM TDA مانیٹر کی ملکیت والے دھاگوں اور ان کے انتظار کے دھاگوں کا ٹری ویو دکھائے گا۔

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

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

تاہم، تمام تھریڈز یکساں اہم نہیں ہیں:

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

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

ایڈوانسڈ ٹِپ: اگر آپ دیکھتے ہیں کہ بعض مانیٹر اکثر متنازع ہوتے ہیں، تو لاک گرینولریٹی کو کم کرنے کے لیے اپنے کوڈ کو ری فیکٹر کرنے پر غور کریں۔ مثال کے طور پر:

• موٹے دانے والے تالے کو باریک دانوں سے بدل دیں۔
• جہاں ممکن ہو نان بلاکنگ الگورتھم یا سمورتی ڈیٹا ڈھانچے کا استعمال کریں۔
• تالے کے انتظار میں تھریڈز کے وقت کو کم کرنے کے لیے ڈیٹا بیس کے سوالات کو بہتر بنائیں۔

بونس انسائٹ: کلکٹر سروس

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

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

• میموری لیکس: وہ اشیاء جو کوڑا کرکٹ جمع نہیں کر رہی ہیں وہ بار بار GC سائیکلوں کا سبب بن سکتی ہیں۔
• ہائی آبجیکٹ چرن: اشیاء کی تیزی سے تخلیق اور تباہی کوڑا اٹھانے والے کو مغلوب کر سکتی ہے۔
• غلط JVM ترتیبات: غلط کنفیگر شدہ ہیپ سائز یا GC الگورتھم ناکارہیوں کا باعث بن سکتے ہیں۔

وسائل کے استعمال کو بہتر بنانے کے لیے یہاں کچھ تحفظات ہیں:

• اپنی JVM سیٹنگز کو ٹیون کرنا (مثال کے طور پر، ہیپ کا سائز بڑھانا، G1GC پر سوئچ کرنا)۔
• لیک کی نشاندہی کرنے کے لیے Eclipse MAT یا YourKit جیسے ٹولز کے ساتھ میموری کے استعمال کی پروفائلنگ۔
• غیر ضروری آبجیکٹ کی تخلیق کو کم کرنے کے لیے آپ کی ایپلیکیشن کے میموری ایلوکیشن پیٹرن کا جائزہ لینا۔

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

حتمی خیالات

تھریڈ ڈمپ تجزیہ ایک ڈویلپر کی سپر پاور ہے — آپ کو کوڈ رائٹر سے پرفارمنس ڈیٹیکٹیو میں تبدیل کرتا ہے۔ IBM Thread Analyzer (TDA) پیچیدہ نظام کے رویوں کو سمجھنے کے لیے آپ کی کلید ہے، چھپی ہوئی رکاوٹوں کو ظاہر کرتا ہے جو آپ کے Java/AEM مثال کی کارکردگی کو متاثر کرتے ہیں۔

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

یاد رکھیں، پریکٹس کامل بناتی ہے - جتنا زیادہ آپ تھریڈ ڈمپ کا تجزیہ کریں گے، آپ کی تشخیصی صلاحیتیں اتنی ہی تیز ہوتی جائیں گی۔ 📊💪

🛠 ️مسئلہ حل مبارک ہو! اور اپنی جاوا/AEM مثال کو آسانی سے چلانے کے لیے اپنی ٹیم کے ساتھ اپنے نتائج کا اشتراک کرنا نہ بھولیں۔