الجزء الأول من ترجمة المقال الأصلي
أفضل 50 سؤالًا لمقابلة موضوع Java وإجابات للمبرمجين الجدد وذوي الخبرة.
جزء ثان.
ملاحظة: تبين أن المقالة كبيرة، ولهذا السبب لا تتناسب مع موضوع واحد. علاوة على ذلك، الأمر معقد للغاية، لقد بذلت قصارى جهدي للبحث عنه في جوجل، ولكن لا يزال. لذلك، نطلب من المشاركين الذين يجيدون اللغة الإنجليزية إلقاء نظرة على الأصل ومقارنته بالترجمة، في حال أخطأوا في فهم شيء ما أو ترجموه بشكل غير صحيح. شكرا لكم مقدما. في أي مقابلة، سواء كنت كبيرًا أو مبتدئًا، من ذوي الخبرة أو المبتدئين، ستواجه بضعة أسئلة حول الخيوط والتوازي والخيوط المتعددة. في الواقع، يعد هذا الدعم المدمج للتزامن أحد أعظم نقاط القوة في Java وقد ساعدها على تحقيق شعبية بين رواد الأعمال والمبرمجين على حدٍ سواء. تتطلب معظم وظائف مطوري Java المربحة مهارات ممتازة متعددة الخيوط وخبرة في تطوير وتصحيح الأخطاء وضبط التطبيقات عالية الأداء ومنخفضة الكمون. ولذلك فهي من أكثر المهارات المطلوبة في المقابلات. في مقابلة Java نموذجية، يبدأ القائم بإجراء المقابلة ببطء بالمفاهيم الأساسية للسلاسل، ويطرح أسئلة مثل سبب الحاجة إلى سلاسل الرسائل، وكيفية إنشائها، وأي طريقة أفضل لإنشائها، أو الوراثة من Thread أو تنفيذ Runnable، ثم يتحرك ببطء حول صعوبات التزامن، والصعوبات التي تمت مواجهتها في تطوير التطبيقات المتوازية، وأدوات التزامن عالية المستوى المقدمة في JDK 1.5، ومبادئ وأنماط تصميم التطبيقات المتوازية، ومشكلات تعدد العمليات الكلاسيكية. نظرًا لأنه لا يكفي مجرد معرفة أساسيات تعدد العمليات، يجب أن تعرف كيفية التعامل مع مشكلات التزامن مثل حالة الجمود، وظروف السباق، وعدم تناسق الذاكرة، ومشكلات سلامة الخيط المختلفة. تم اختبار هذه المهارات بدقة، مما يمثل تحديات متعددة للخيوط المتعددة والتزامن. عادةً ما يقرأ العديد من مطوري Java الأسئلة قبل المقابلة نفسها، وهذا ليس بالأمر السيئ، ولكن يجب أن تفهم ذلك. كما أن تجميع الأسئلة والقيام بنفس التمارين يضيع الكثير من الوقت، لذلك قمت بإنشاء هذه القائمة.
-
ما هو الخيط في جافا؟
الخيط هو مسار تنفيذ مستقل. هدفها هو الاستفادة من المعالجات المتعددة المتوفرة في الجهاز. باستخدام مؤشرات ترابط متعددة، يمكنك تسريع المهام المرتبطة بوحدة المعالجة المركزية. على سبيل المثال، إذا استغرق مؤشر ترابط واحد 100 مللي ثانية لإكمال مهمة، فيمكنك استخدام 10 سلاسل لتقليل هذه المهمة إلى 10 مللي ثانية. توفر Java دعمًا ممتازًا لسلاسل العمليات المتعددة على مستوى اللغة، وهذا علاوة على ذلك يعد أحد أقوى مزاياها.
-
الفرق بين المواضيع والعمليات في جافا؟
مؤشر الترابط هو مجموعة فرعية من العملية؛ بمعنى آخر، يمكن أن تحتوي عملية واحدة على العديد من سلاسل الرسائل. تعمل العمليتان في مساحات ذاكرة مختلفة، لكن جميع سلاسل العمليات تشترك في نفس مساحة الذاكرة. لا تخلط بين هذا وبين الذاكرة المكدسة، والتي تختلف باختلاف كل مؤشر ترابط ويتم استخدامها لتخزين البيانات المحلية لمؤشر الترابط هذا.
-
كيفية إنشاء موضوع؟
على مستوى اللغة، هناك طريقتان لإنشاء موضوع. يمثل كائن الفئة java.lang.Thread مؤشر ترابط، ولكنه يتطلب مهمة لتشغيلها، وهو كائن يقوم بتنفيذ واجهة java.lang.Runnable. نظرًا لأن فئة Thread تطبق واجهة Runnable، يمكنك تجاوز طريقة run() عن طريق اشتقاق فئتك من Thread أو عن طريق تنفيذ واجهة Runnable فيها.
-
متى تستخدم Runnable ومتى تستخدم Thread؟
وهذه إضافة للسؤال السابق. كما نعلم، يمكن إنشاء سلسلة رسائل عن طريق الوراثة من فئة Thread أو عن طريق تنفيذ الواجهة القابلة للتشغيل. السؤال الذي يطرح نفسه ما هي الطريقة الأفضل ومتى تستخدم أي منها؟ من السهل الإجابة على هذا السؤال إذا كنت تعلم أن Java لا تدعم وراثة الفئات المتعددة ولكنها تسمح لك بتنفيذ واجهات متعددة. مما يعني أنه من الأفضل تنفيذ Runnable إذا كنت تريد أن ترث من فئة أخرى.
-
الفرق بين طرق البدء () والتشغيل ()؟
أحد الأسئلة الخادعة من الماضي، لكنه لا يزال جيدًا بما يكفي لتمييز الفهم السطحي للخيوط المتعددة في Java. يتم استخدام طريقة start () لبدء موضوع جديد. على الرغم من أن start() تستدعي طريقة run() داخليًا، إلا أنها ليست مثل مجرد استدعاء run(). إذا قمت باستدعاء run() كطريقة عادية، فسيتم استدعاؤها على نفس الموضوع ولن يبدأ أي موضوع جديد، وهو ما يحدث عند استدعاء الأسلوب start().
-
الاختلافات بين Runnable و Callable؟
تمثل كلا الواجهتين المهام التي سيتم تنفيذها في سلاسل رسائل منفصلة. لقد كان Runnable موجودًا منذ JDK 1.0، وتمت إضافة Callable في JDK 1.5. يتمثل الاختلاف الرئيسي في أن طريقة call() الخاصة بـ Callable يمكنها إرجاع القيم وطرح الاستثناءات، وهو أمر غير ممكن مع طريقة run() الخاصة بـ Runnable. تقوم الدالة Callable بإرجاع كائن مستقبلي يمكن أن يحتوي على نتيجة عملية حسابية.
-
الاختلافات بين CyclicBarrier وCountDownLatch؟
في حين أن كلا المزامنين يسمحان للخيوط بانتظار بعضها البعض، فإن الاختلاف الرئيسي بينهما هو أنه لا يمكنك إعادة استخدام CountDownLatch بعد أن يصل عداده إلى الصفر، ولكن يمكنك استخدام CyclicBarrier مرة أخرى حتى بعد كسر الحاجز.
-
ما هو نموذج ذاكرة جافا؟
نموذج الذاكرة عبارة عن مجموعة من القواعد والإرشادات التي تسمح لبرامج Java بالعمل بشكل محدد عبر بنيات الذاكرة والمعالج ونظام التشغيل المتعددة. وهذا مهم بشكل خاص في حالة الخيوط المتعددة. يوفر نموذج الذاكرة ضمانات بأن التغييرات التي يتم إجراؤها بواسطة مؤشر ترابط واحد ستكون مرئية للآخرين، أحدها هو علاقة "الحدث قبل". تحدد هذه العلاقة عدة قواعد تسمح للمبرمجين بتوقع وتحديد سلوك البرامج المتوازية. على سبيل المثال يحدث-قبل الضمانات:
- يحدث كل إجراء في سلسلة المحادثات قبل كل إجراء في سلسلة المحادثات هذا والذي يتبع ترتيب البرنامج، والمعروف أيضًا بقاعدة ترتيب البرامج.
- يتم إلغاء قفل الشاشة قبل كل قفل لاحق لنفس الشاشة، وهو ما يُعرف أيضًا بقاعدة قفل الشاشة.
- تحدث الكتابة إلى حقل متقلب قبل كل قراءة لاحقة لهذا الحقل، وهي قاعدة متغيرة متقلبة.
- يتم استدعاء Thread.start() على مؤشر ترابط قبل أن يلاحظ أي مؤشر ترابط آخر أن مؤشر الترابط قد تم إيقافه، إما بعد نجاح Thread.join()، أو إذا قام Thread.isAlive() بإرجاع خطأ، فإن قاعدة Thread.start() .
- يحدث الخيط الذي تمت مقاطعته بواسطة خيط آخر قبل أن يلاحظ الخيط الذي تمت مقاطعته الانقطاع (إما من طرح InterruptedException أو من التحقق من isInterrupted())، وهي قاعدة مقاطعة الخيط.
- تحدث نهاية مُنشئ الكائن قبل بدء أداة الإنهاء لهذا الكائن، وهي قاعدة أداة الإنهاء.
- إذا حدث A قبل B، وB حدث قبل C، فإن A حدث قبل C، مما يعني أنه حدث قبل ضمانات العبور.
-
ما هو المتغير المتقلب؟
المتغير هو معدل خاص لا يمكن تطبيقه إلا على السمات. في برامج Java المتوازية، لا تكون التغييرات التي يتم إجراؤها بواسطة سلاسل رسائل مختلفة على السمات مرئية للآخرين في حالة عدم وجود مزامن. يضمن المتغير المتطاير أن تتم الكتابة قبل القراءة اللاحقة، كما هو مذكور في قاعدة المتغير المتطاير في السؤال السابق.
-
ما هو سلامة الخيط؟ هل فئة Vector آمنة؟
سلامة سلاسل العمليات هي خاصية لكائن أو رمز يضمن أنه عند تنفيذه أو استخدامه بواسطة سلاسل رسائل متعددة، فإن الكود سيتصرف على النحو المنشود. على سبيل المثال، لن يتخطى العداد الآمن لمؤشر الترابط أي عمليات حسابية إذا تم استخدام نفس مثيل العداد بين سلاسل رسائل متعددة. من الواضح أن فئات التجميع يمكن تقسيمها إلى فئتين، خيط آمن وغير آمن. يعتبر Vector آمنًا لمؤشر الترابط ويحقق ذلك عن طريق مزامنة الطرق التي تغير حالة Vector، ومن ناحية أخرى، فإن نظيره ArrayList ليس آمنًا لمؤشر الترابط.
-
ما هي حالة السباق؟
ظروف السباق هي سبب الأخطاء الدقيقة. كما يوحي الاسم نفسه، تحدث حالة السباق بسبب السباق بين سلاسل رسائل متعددة؛ إذا فقد الخيط الذي يجب تنفيذه أولاً السباق وتم تنفيذ الثاني، يتغير سلوك الكود، مما يتسبب في أخطاء غير حتمية. هذه بعض من أصعب الأخطاء التي يمكن اكتشافها وإعادة إنتاجها بسبب الطبيعة الفوضوية للسباقات بين الخيوط. مثال على حالة السباق هو التنفيذ غير المنتظم.
-
كيفية إيقاف الخيط؟
لقد قلت دائمًا أن Java توفر واجهات برمجة تطبيقات غنية لكل شيء، ولكن من المفارقات أنها لا توفر طرقًا مناسبة لإيقاف سلسلة محادثات. يحتوي JDK 1.0 على العديد من طرق التحكم، مثل stop()، وsuspension()، وsume()، والتي تم وضع علامة عليها على أنها مهملة في الإصدارات المستقبلية بسبب تهديدات الجمود المحتملة؛ ومنذ ذلك الحين، لم يقم مطورو Java API بأي محاولة لتوفير سلسلة رسائل - مقاومة - طريقة آمنة وأنيقة لإيقاف الخيوط. يعتمد المبرمجون في الغالب على حقيقة أن الخيط يتوقف عن نفسه بمجرد انتهاء تنفيذ أساليب التشغيل () أو الاتصال (). للإيقاف يدويًا، يستفيد المبرمجون من المتغير المنطقي المتطاير ويتحققون من قيمته في كل تكرار إذا كانت هناك حلقات في طريقة التشغيل () أو يقاطعون سلاسل الرسائل باستخدام طريقة المقاطعة () لإلغاء المهام فجأة.
-
ماذا يحدث عندما يلقي الخيط استثناءً؟
هذا هو واحد من تلك الأسئلة الخدعة الجيدة. بكلمات بسيطة، إذا لم يتم اكتشاف الاستثناء، فهذا يعني أن مؤشر الترابط ميت؛ وإذا تم تثبيت معالج للاستثناءات التي لم يتم اكتشافها، فسوف يتلقى رد اتصال. Thread.UncaughtExceptionHandler هي واجهة تم تعريفها على أنها واجهة متداخلة للمعالجات التي يتم استدعاؤها عندما يتوقف مؤشر الترابط فجأة بسبب استثناء لم يتم اكتشافه. عندما يكون مؤشر الترابط على وشك الموت بسبب استثناء لم يتم اكتشافه، سيتحقق JVM من وجود UncaughtExceptionHandler باستخدام Thread.getUncaughtExceptionHandler() ويستدعي أسلوب uncaughtException() الخاص بالمعالج، ويمرر الخيط والاستثناء كوسيطات.
-
كيفية مشاركة البيانات بين موضوعين؟
يمكنك مشاركة البيانات بين سلاسل العمليات باستخدام كائن مشترك أو هياكل بيانات متوازية مثل BlockingQueue.
-
الاختلافات بين الإخطار وإخطار الكل؟
هذا سؤال صعب آخر، نظرًا لأنه يمكن مراقبة شاشة واحدة بواسطة عدة سلاسل رسائل، يوفر مطورو Java API طريقة لإخطار مؤشر ترابط واحد فقط أو جميع مؤشرات الترابط بالتغيير في حالته، لكنهم يقدمون نصف التنفيذ فقط. لا تحتوي طريقة الإخطار () على طريقة لتحديد موضوع معين، لذلك فهي مفيدة فقط عندما تعرف على وجه اليقين أن هناك موضوعًا واحدًا فقط في انتظارك. من ناحية أخرى، notifyAll () يخطر جميع المواضيع ويسمح لهم بالتنافس على الشاشة، مما يضمن أن مؤشر ترابط واحد على الأقل يتحرك للأمام.
-
لماذا لا يتم الانتظار والإخطار والإخطار للجميع في فئة الموضوع؟
هذا سؤال تصميم يختبر ما يفكر فيه المرشح بشأن الأنظمة الحالية أو ما إذا كان قد فكر في شيء مشابه يبدو في غير محله في البداية. للإجابة على هذا السؤال، تحتاج إلى تقديم عدة أسباب لماذا يتم تنفيذ هذه الأساليب بشكل أفضل في فئة الكائن، ولماذا لا يتم تنفيذها في فئة الموضوع. السبب الأول الواضح هو أن Java تدعم الأقفال على مستوى الكائن، وليس على مستوى مؤشر الترابط. أي كائن له قفل يتم الحصول عليه بواسطة خيط. وإذا كان الخيط يحتاج إلى انتظار قفل معين، فمن المنطقي استدعاء الانتظار () على كائن بدلاً من استدعاء هذا الخيط. إذا تم الإعلان عن الانتظار () في فئة الموضوع، فلن يكون من الواضح أي قفل كان مؤشر الترابط ينتظره. باختصار، نظرًا لأن الانتظار والإخطار والإخطار يعمل على مستوى القفل، فمن الملائم أكثر الإعلان عنها في فئة الكائن لأن القفل يشير إلى كائن.
-
ما هو متغير ThreadLocal؟
تعد متغيرات ThreadLocal نوعًا خاصًا من المتغيرات المتاحة لمبرمج Java. مثلما تحتوي الحالات على متغير حالة، فإن الخيوط لها متغيرات ThreadLocal. تعد هذه طريقة جيدة لتحقيق أمان مؤشر الترابط للكائنات باهظة الثمن التي يتم إنشاؤها؛ على سبيل المثال، يمكنك جعل SimpleDateFormat آمنًا لمؤشر الترابط باستخدام ThreadLocal. نظرًا لأن هذه فئة باهظة الثمن، فمن غير المستحسن استخدامها في نطاق محلي يتطلب مثيلات منفصلة لكل استدعاء. من خلال إعطاء كل خيط نسخته الخاصة، فإنك تقتل عصفورين بحجر واحد. أولاً، يمكنك تقليل عدد مثيلات الكائنات باهظة الثمن باستخدام عدد ثابت جديد من المثيلات، وثانيًا، يمكنك تحقيق أمان الخيط دون فقدان المزامنة والثبات. مثال جيد آخر لمتغير مؤشر الترابط المحلي هو فئة ThreadLocalRandom، مما يقلل من عدد مثيلات الكائنات العشوائية المكلفة لإنشاءها في بيئة متعددة الخيوط.
-
ما هو فيوتشرتاسك؟
FutureTask عبارة عن حساب غير متزامن قابل للإلغاء في تطبيق Java الموازي. توفر هذه الفئة تطبيقًا أساسيًا للمستقبل، مع طرق بدء وإيقاف الحساب، وطرق الاستعلام عن حالة الحساب، واسترداد النتائج. لا يمكن الحصول على النتيجة إلا عند اكتمال الحساب، وسيتم حظر طريقة getter إذا لم يكتمل الحساب بعد. يمكن استخدام كائنات FutureTask لتغليف الكائنات القابلة للاستدعاء والقابلة للتشغيل. نظرًا لأن FutureTask يطبق Runnable، فيمكن تمريره إلى Executor للتنفيذ.
-
الفرق بين المقاطعة والمقاطعة؟
يتمثل الاختلاف الرئيسي بين Interrupt() وisInterrupted() في أن الأول يعيد تعيين حالة المقاطعة بينما لا يقوم الأخير بذلك. يتم تنفيذ آلية المقاطعة في Java باستخدام علامة داخلية تُعرف بحالة المقاطعة. تؤدي مقاطعة الخيط عن طريق استدعاء Thread.interrupt() إلى تعيين هذه العلامة. عندما يتحقق مؤشر ترابط تمت مقاطعته من حالة المقاطعة عن طريق استدعاء الأسلوب الثابت Thread.interrupted()، تتم إعادة تعيين حالة المقاطعة. لا تغير طريقة isInterrupted () غير الثابتة، والتي يستخدمها مؤشر ترابط للتحقق من حالة المقاطعة لمؤشر ترابط آخر، علامة المقاطعة. بشكل تقليدي، أي طريقة تنتهي عن طريق طرح InterruptedException تعيد تعيين علامة المقاطعة. ومع ذلك، هناك دائمًا احتمال أن يتم تعيين العلامة مرة أخرى على الفور إذا قام مؤشر ترابط آخر باستدعاء المقاطعة ().
-
لماذا يتم استدعاء أساليب الانتظار والإخطار في كتلة متزامنة؟
السبب الرئيسي لاستدعاء الانتظار والإخطار من كتلة أو طريقة ثابتة هو أن Java API يتطلب ذلك. إذا اتصلت بهم من خارج كتلة متزامنة، فسيقوم الكود الخاص بك بطرح IllegalMonitorStateException. السبب الأكثر ذكاءً هو تجنب حالة السباق بين مكالمات الانتظار والإخطار.
-
لماذا يجب عليك التحقق من حالة الانتظار في الحلقة؟
هناك احتمال أن يتلقى الخيط المنتظر تحذيرات كاذبة ومكالمات تنبيه كاذبة إذا لم يتحقق من حالة الانتظار في الحلقة، فسوف يخرج ببساطة حتى لو لم يتم الوصول إلى الحالة. عندما يستيقظ الخيط المنتظر، فإنه لا يفكر في حقيقة أن الحالة التي كان ينتظرها ربما لا تزال سارية. يمكن أن يكون في الماضي بالفعل، ولكن تم تغييره بعد استدعاء طريقة الإخطار () وقبل استيقاظ الخيط. لذلك، من الأفضل دائمًا استدعاء الانتظار () من داخل الحلقة.
-
الاختلافات بين المجموعات المتزامنة والمتزامنة؟
في حين أن كلاً من المجموعات المتزامنة والمتزامنة توفر مجموعات آمنة للسلاسل، فإن الأخيرة أكثر قابلية للتطوير. قبل Java 1.5، لم يكن لدى المبرمجين سوى إمكانية الوصول إلى المجموعات المتزامنة، الأمر الذي أصبح مصدرًا للخلاف عندما وصلت سلاسل رسائل متعددة إليها في وقت واحد، مما يجعل من الصعب توسيع نطاق النظام. قدمت Java 5 مجموعات متزامنة مثل ConcurrentHashMap، والتي لا توفر أمانًا لسلسلة المحادثات فحسب، بل تعمل أيضًا على تحسين قابلية التوسع باستخدام التقنيات الحديثة مثل تجريد القفل وتقسيم الجدول الداخلي.
-
الاختلافات بين المكدس والكومة؟
لماذا يوجد هذا السؤال في الأسئلة المتعلقة بتعدد العمليات؟ لأن المكدس عبارة عن قطعة من الذاكرة مرتبطة ارتباطًا وثيقًا بالخيوط. يحتوي كل مؤشر ترابط على مكدس خاص به، والذي يقوم بتخزين المتغيرات المحلية ومعلمات الطريقة ومكدس الاستدعاءات. المتغير المخزن في مكدس خيط واحد غير مرئي لآخر. من ناحية أخرى، الكومة هي منطقة مشتركة من الذاكرة مشتركة بين جميع المواضيع. يتم إنشاء الكائنات، سواء كانت محلية أو أي مستوى آخر، في الكومة. لتحسين الأداء، عادةً ما يقوم الخيط بتخزين القيم مؤقتًا من الكومة إلى مكدسها، حيث تلعب المتغيرات المتطايرة دورًا. يخبر المتطاير الخيوط بقراءة متغير من الذاكرة الرئيسية.
-
ما هو تجمع الموضوع؟
إنشاء موضوع مكلف من حيث الوقت والموارد. إذا قمت بإنشاء سلسلة رسائل أثناء معالجة الطلب، فسيؤدي ذلك إلى إبطاء وقت الاستجابة، ولا يمكن للعملية سوى إنشاء عدد محدود من سلاسل الرسائل. لتجنب هذه المشاكل، يتم إنشاء مجموعة من مؤشرات الترابط عند بدء تشغيل التطبيق ويتم إعادة استخدام مؤشرات الترابط لمعالجة الطلبات. يُطلق على تجمع الخيوط هذا اسم "تجمع الخيوط" ، وتسمى الخيوط الموجودة فيه بالخيط العامل. بدءًا من Java 1.5، توفر Java API إطار عمل Executor، والذي يسمح لك بإنشاء مجموعات سلاسل رسائل مختلفة، مثل تجمع سلاسل رسائل واحد، والذي يعالج مهمة واحدة فقط لكل وحدة زمنية، وتجمع سلاسل رسائل ثابت، وتجمع برقم ثابت من سلاسل الرسائل، وتجمع مؤشرات الترابط المخزن مؤقتًا، وتجمع قابل للتوسيع. مناسب للتطبيقات التي تحتوي على العديد من المهام قصيرة العمر.
-
كيفية حل مشكلة المستهلك المنتج؟
معظم مشاكل الخيط التي تحلها في الواقع هي من نمط Producer Consumer، حيث يقوم خيط واحد بإنشاء المشكلة بينما يستهلكها خيط آخر. تحتاج إلى معرفة كيفية بناء تفاعلات الخيط الداخلي لحل هذه المشكلة. على المستوى المنخفض يمكنك الاستفادة من طريقتي الانتظار والإخطار، وعلى المستوى العالي يمكنك الاستفادة من Semaphore أو BlockingQueue
-
كيفية تجنب الجمود؟
![الترجمة: أهم 50 سؤالاً للمقابلة حسب الموضوع. الجزء 1. - 1]()
حالة الجمود هي الحالة التي ينتظر فيها الخيط الخيط الثاني للقيام ببعض الإجراءات، والثاني، في نفس الوقت، ينتظر نفس الشيء من الأول. هذه مشكلة خطيرة جدًا تؤدي إلى تجميد برنامجك وعدم القيام بما هو مصمم للقيام به. يحدث الجمود عند الوصول إلى هذه الحالات الأربع:
- الاستبعاد المتبادل: يجب شغل مورد واحد على الأقل في وضع غير قابل للتجزئة. يمكن لعملية واحدة فقط استخدام المورد في أي وقت محدد.
- الانتظار والانتظار: تحتفظ العملية بمورد واحد على الأقل وتطلب موارد إضافية تحتفظ بها العمليات الأخرى.
- لا يوجد تنظيف مسبق: لا يقوم نظام التشغيل بإعادة تخصيص الموارد إذا كانت مشغولة بالفعل، بل يجب منحها طوعًا لعملية الاحتفاظ.
- الانتظار الدوري: تنتظر العملية حتى يتم تحرير الموارد من خلال عملية أخرى، والتي بدورها تنتظر تحرير الموارد من خلال العملية الأولى.
إن أبسط طريقة لتجنب حالة الجمود هي تجنب الانتظار في حلقة، ويمكن تحقيق ذلك عن طريق الحصول على الأقفال بترتيب معين وتحريرها بالترتيب العكسي.
-
الاختلافات بين Livelock والجمود؟
يشبه القفل المباشر حالة الجمود، فقط في حالة القفل المباشر تتغير حالات الخيوط أو العمليات المعنية باستمرار اعتمادًا على بعضها البعض. Livelock هي حالة خاصة من نقص الموارد. مثال حقيقي على Livelock هو عندما يلتقي شخصان في ممر ضيق ويتحرك كل منهما جانبًا، محاولًا أن يكون مهذبًا، وبالتالي يتحركان إلى ما لا نهاية من جانب إلى آخر.
حالة الجمود هي الحالة التي ينتظر فيها الخيط الخيط الثاني للقيام ببعض الإجراءات، والثاني، في نفس الوقت، ينتظر نفس الشيء من الأول. هذه مشكلة خطيرة جدًا تؤدي إلى تجميد برنامجك وعدم القيام بما هو مصمم للقيام به. يحدث الجمود عند الوصول إلى هذه الحالات الأربع:
GO TO FULL VERSION