پاسخ به سوالات تئوری — هوم‌وورک نهم

⚛️ متغیرهای اتمیک و همگام‌سازی (Atomic Variables & Synchronization)

۱. متغیرهای اتمیک چیستند، چه هدفی دارند و تفاوتشان با متغیرهای معمولی چیست؟

متغیرهای اتمیک کلاس‌هایی در جاوا هستند که به ما اجازه می‌دهند عملیات‌های خواندن و نوشتن (مثل افزایش یا کاهش مقدار) را روی یک متغیر بدون نیاز به قفل‌های سنگین (مثل بلوک‌های synchronized)، به صورت کاملاً «یکپارچه و غیرقابل‌تفکیک» یا همان اتمیک انجام دهیم.

• تفاوت با متغیرهای معمولی: عملیاتی مثل count++ روی متغیرهای معمولی در ظاهر یک خط است، اما در سطح پردازنده شامل ۳ مرحله است (خواندن مقدار قدیمی، اضافه کردن یک واحد، و نوشتن مقدار جدید). اگر چند ترد همزمان این کار را بکنند، تداخل (Race Condition) پیش می‌آید و دیتا خراب می‌شود. اما متغیرهای اتمیک این عملیات ۳ مرحله‌ای را به کمک سخت‌افزار (دستورات سطح پایین پردازنده مثل CAS - Compare-And-Swap) به یک عملیات واحد و تفکیک‌ناپذیر تبدیل می‌کنند تا بدون بلاک شدن تردها، امنیت داده‌ها حفظ شود.

---

۲. نام بردن حداقل ۴ کلاس از پکیج java.util.concurrent.atomic و توضیح کاربرد یکی از آن‌ها

چهار کلاس پرکاربرد عبارتند از:

1. AtomicInteger
2. AtomicLong
3. AtomicBoolean
4. AtomicReference<V>

• توضیح کاربرد AtomicInteger: از این کلاس معمولاً برای ساختن شمارنده‌های سراسری (Global Counters) یا تولید شناسه‌های یکتا در برنامه‌های چندنخی استفاده می‌شود. مثلاً اگر یک وب‌سرور داشته باشیم که بخواهد تعداد درخواست‌های ورودی را بشمارد، به جای استفاده از قفل که سرعت را پایین می‌آورد، از متد incrementAndGet() در این کلاس استفاده می‌کنیم تا تردها همزمان و با بالاترین سرعت تعداد را بالا ببرند.

---

۳. مقایسه قفل‌ها (Locks) با متغیرهای اتمیک (در چه سناریوهایی کدام‌یک بر دیگری برتری دارد؟)

• برتری متغیرهای اتمیک: وقتی که فقط با یک متغیر مستقل (مثل یک کانتر یا یک فلگ وضعیت) سر و کار داریم و رقابت بین تردها معمولی یا متوسط است، متغیرهای اتمیک بسیار سریع‌تر هستند چون تردها وارد وضعیت Block نمی‌شوند و هزینه سنگین Context Switching رخ نمی‌دهد.
• برتری قفل‌ها (Locks): وقتی که منطق برنامه پیچیده است و شامل چندین متغیر وابسته به هم می‌شود (مثلاً در همین پروژه بانک، کسر از یک حساب و واریز به حساب دیگر باید با هم قفل شوند)، متغیرهای اتمیک به تنهایی نمی‌توانند کل این فرآیند چندمرحله‌ای را اتمیک کنند. در این سناریوها و یا زمانی که رقابت بین تردها فوق‌العاده بالاست، استفاده از قفل‌ها (مانند ReentrantLock یا ReadWriteLock) گزینه بهتری است.

---

🔒 قفل‌ها و طراحی همزمان (Locks & Concurrent Design)

۴. چطور ممکن است برنامه‌ای کاملاً بدون Race Condition باشد اما زیر بار شدید کارایی پایینی داشته باشد؟ (۳ عامل محدودکننده قابلیت مقیاس‌پذیری)

دلیلش این است که برای حل Race Condition ممکن است از قفل‌گذاری‌های بیش از حد بزرگ یا ناشیانه استفاده کرده باشیم. سه عامل اصلی که جلوی مقیاس‌پذیری (Scalability) برنامه را می‌گیرند عبارتند از:

1. انحصار متقابل بیش از حد (Coarse-Grained Locking): اگر کل متدهای یک کلاس بزرگ را قفل انحصاری کنیم، در بار شدید تردها مجبور می‌شوند پشت سر هم در یک صف طولانی بایستند و برنامه عملاً از حالت موازی خارج شده و ترتیبی کار می‌کند.
2. هزینه تعویض کانکشن/ترد (Context Switching Overhead): وقتی تردهای زیادی برای گرفتن یک قفل تلاش می‌کنند، سیستم‌عامل مدام باید یک ترد را متوقف و ترد دیگری را فعال کند. این جابه‌جایی بین هسته‌های پردازنده، منابع زیادی از CPU را هدر می‌دهد.
3. محدودیت قانون امدال (Amdahl's Law): طبق این قانون، سرعت کل برنامه محدود به آن بخشی از کد است که مجبور است به صورت ترتیبی و غیرموازی اجرا شود. هر چقدر بخش‌های دارای قفل انحصاری در برنامه بیشتر باشد، افزایش هسته‌های CPU کمک خاصی به سرعت نخواهد کرد.

---

۵. چرا افزایش تعداد تردها همیشه کارایی را بهتر نمی‌کند؟

چهار دلیل فنی برای این موضوع وجود دارد:

• تعویض زمینه (Context Switching): ساختن تردهای بیشتر از تعداد هسته‌های واقعی پردازنده باعث می‌شود CPU بخش زیادی از زمانش را صرف جابه‌جایی بین تردها و ذخیره/بازیابی وضعیت آن‌ها کند، به جای اینکه کار واقعی انجام دهد.
• رقابت بر سر منابع (Contention): وقتی تعداد تردها خیلی زیاد شود، همه برای گرفتن قفل منابع مشترک می‌جنگند و زمان زیادی را در صفِ انتظار قفل تلف می‌کنند.
• انسجام حافظه نهان (Cache Coherence Overhead): وقتی تردهای مختلف روی هسته‌های مختلف مدام یک دیتای مشترک را تغییر می‌دهند، پردازنده مجبور است سیگنال‌های مداومی برای به‌روزرسانی حافظه کش بین هسته‌ها بفرستد (Cache Invalidation) که پهنای باند حافظه را به شدت درگیر می‌کند.
• بار اضافی همگام‌سازی (Synchronization Overhead): مکانیزم‌های مدیریت قفل در سیستم‌عامل و جاوا خودشان مصرف‌کننده منابع هستند و اجرای دستوراتِ هماهنگی بین تردها، بار پردازشی اضافه به سیستم تحمیل می‌کند.

---

💀 بن‌بست (Deadlocks)

۶. چرا ددلاک‌ها معمولاً در تست‌ها دیده نمی‌شوند و فقط در محیط پروداکشن (زیر بار واقعی) رخ می‌دهند؟ معرفی ۲ استراتژی برای آشکار کردن آن‌ها.

چرا در تست‌ها دیده نمی‌شوند؟ ددلاک برای رخ دادن نیاز به یک توالی زمانی بسیار خاص و نادر (Timing/Interleaving) دارد. در محیط تست‌های معمولی، بار روی سیستم کم است و زمان‌بندی تردها توسط سیستم‌عامل به گونه‌ای جلو می‌رود که تردها معمولاً با هم تلاقی پیدا نمی‌کنند. اما در محیط واقعی (Production)، حجم درخواست‌ها بالا می‌رود و احتمال اینکه دو ترد دقیقاً در یک لحظه به طور متقاطع منابع هم را طلب کنند بالا رفته و ددلاک رخ می‌دهد.

دو استراتژی برای آشکار کردن ددلاک در طول تست:

1. استفاده از تست‌های استرس طولانی‌مدت به همراه آشکارسازها (Thread Dumps): اجرای تست‌ها با تعداد ترد بالا و حجم دیتای سنگین برای مدت طولانی، و گرفتن Thread Dump به کمک ابزارهایی مثل jstack تا متوجه شویم کدام تردها در وضعیت BLOCKED روی هم قفل شده‌اند.
2. استفاده از ابزارهای مانیتورینگ زنده (مثل JConsole یا VisualVM): این ابزارها بخشی به نام "Detect Deadlock" دارند که به صورت گرافیکی ساختار کدهای در حال اجرا را آنالیز کرده و در صورت وجود حلقه‌های ددلاک سریعاً آن را گزارش می‌دهند.