أفضل الممارسات العمليّة لتعدّد الخيوط: طبعة Java ── اصطلاحات عصر الخيوط الافتراضيّة

«نريد موازاة دفعة أعمال في Java.» «ذاكرة التخزين المؤقّت المشتركة في تطبيق Spring للويب تفسد أحياناً.» «ورثنا تطبيقاً Swing قديماً مليئاً بـ new Thread.» — أدمجت Java تعدّد الخيوط في اللغة منذ JDK 1.0، ونضجت إلى صندوق أدوات java.util.concurrent، ثمّ أعادت مع الخيوط الافتراضيّة في JDK 21 كتابة الحكمة التقليديّة للبرمجة المتزامنة مرّة أخرى. ولأنّ مجموعة الأدوات غنيّة إلى هذا الحدّ، فإنّ الأداة التي تختارها تصبح جودة التصميم ذاتها.

هذا المقال هو طبعة Java من سلسلة تعدّد الخيوط في الممارسة. موجَّه إلى المطوّرين الذين يكتبون أنظمة أعمال ودفعات وتطبيقات خادم في Java، ويُسقِط مبادئ تصميم تعدّد الخيوط — لا تُنشئ الخيوط مباشرة، قلِّل الحالة المشتركة القابلة للتغيير، انضبط في الأقفال، صمِّم كيف توقف الأشياء قبل أيّ شيء آخر — على أدوات Java (مستهدفاً أساساً إصدار LTS، JDK 21 فما بعد)، ويجمع اختيارات عصر الخيوط الافتراضيّة والمطبّات الخاصّة بـ Java، مستنداً إلى مصادر أوّليّة حتّى أغسطس 2026. كُتب ليُقرأ وحده. المبادئ نفسها مطبَّقة على لغات أخرى تغطّيها المقالات المرافقة «طبعة .NET» و«طبعة C++» و«طبعة C».

1. الخلاصة أوّلاً

• لا تكتب new Thread في شيفرة الأعمال — القاعدة نفسها تنطبق في Java. سلِّم المهام إلى ExecutorService ودع المكتبة تدير دورات حياة الخيوط.¹
• وجِّه المهام التي تنتظر I/O في الغالب إلى الخيوط الافتراضيّة. تُستخدم الخيوط الافتراضيّة، التي صارت رسميّة في JDK 21، خيطاً واحداً لكلّ مهمّة ويجب ألّا تُجمَّع في بركة أبداً. قيِّد التزامن بـ Semaphore لا بحجم البركة.²³
• الخيوط الافتراضيّة أداة معدّل إنتاج، لا أداة لتسريع الحساب. موازاة الأعمال المرتبطة بالمعالج ما زالت من شأن خيوط المنصّة بحجم يقارب عدد الأنوية — بركة ثابتة أو parallel stream، كما من قبل.³
• اقفل على كائن قفل private final، أو على ReentrantLock مخصَّص. synchronized(this) والقفل على كائن مكشوف علناً يمكن أن يصطدما بشيفرة خارجيّة. إن احتجت اكتساباً مؤقّتاً (tryLock) فاستخدم ReentrantLock.
• في JDK 21-23 كانت المشكلة أنّ الحظر داخل كتلة synchronized يثبّت الخيوط الافتراضيّة؛ أصلحه JDK 24 (JEP 491). ميِّز التحذيرات القديمة عن الواقع الحالي.³⁴
• volatile يضمن الرؤية والترتيب، لا الذرّيّة. استخدم AtomicInteger / LongAdder للعدّادات، والأقفال للحالة المركّبة.⁵
• الإيقاف التعاوني عبر المقاطعة هو السبيل الصحيح الوحيد لإيقاف خيط. Thread.stop / suspend / resume ترمي الآن UnsupportedOperationException. لا تبتلع InterruptedException — إمّا تستعيد الحالة أو تعيد الرمي.⁶
• أوقف ExecutorService بالنمط ذي المرحلتين: shutdown → awaitTermination → shutdownNow. shutdownNow أفضل جهد (التنفيذ القياسي يعمل عبر المقاطعة)، لذا يفترض أنّ مهامك تستجيب للمقاطعة.¹
• واجهة Swing تخصّ EDT (Event Dispatch Thread) حصراً. اطلب التحديثات من خيوط أخرى عبر SwingUtilities.invokeLater.⁷

2. لماذا تعدّد الخيوط صعب ── حالات السباق والجمود ونموذج الذاكرة

اختصر المشكلات التي يدخلها تعدّد الخيوط، بغضّ النظر عن اللغة، تجد نوعين.

حالة السباق خطأ يعتمد فيه الناتج على ترتيب وصول خيوط متعدّدة إلى قطعة شيفرة معيّنة. المثال الكلاسيكي عدّاد مشترك: التعبير الواحد count++ ينقسم فعليّاً إلى ثلاث خطوات — اقرأ، أضِف، اكتب من جديد. إن دخل خيطان هذه الخطوات الثلاث في الوقت نفسه، تُمحى زيادة أحد الخيطين حين يكتب الآخر. يتغيّر الناتج في كلّ تشغيل، ولا سبيل للتنبّؤ بأيّ ناتج ستحصل.

sequenceDiagram
    participant A as الخيط A
    participant M as المتغيّرة المشتركة count
    participant B as الخيط B
    Note over M: count = 10
    A->>M: قراءة (10)
    B->>M: قراءة (10)
    A->>A: إضافة محلّيّة (11)
    B->>B: إضافة محلّيّة (11)
    A->>M: كتابة (11)
    B->>M: كتابة (11)
    Note over M: حدثت زيادتان,<br/>لكن count = 11 — ضاعت زيادة الخيط A

الشكل 1: حالة سباق كلاسيكيّة تضيع فيها زيادة على عدّاد مشترك. إن تداخل خيط آخر أثناء الخطوات الثلاث لـ count++، فإنّ آخر كتابة تُكتب تطمس الأخرى

الجمود حالة ينتظر فيها خيطان كلٌّ منهما قفلاً يمسكه الآخر، فلا يتقدّم أيٌّ منهما. الخيط A يمسك القفل 1 وينتظر القفل 2؛ الخيط B يمسك القفل 2 وينتظر القفل 1 — ذلك وحده يكفي ليتوقّف كلاهما إلى الأبد.

flowchart LR
    A["الخيط A<br/>يمسك القفل 1"] -->|"ينتظر تحرير القفل 2"| B["الخيط B<br/>يمسك القفل 2"]
    B -->|"ينتظر تحرير القفل 1"| A

الشكل 2: الانتظار الدائري للجمود. لحظة تشكّل أسهم الانتظار حلقة، يتوقّف كلّ خيط داخل تلك الحلقة إلى الأبد

كلاهما يعتمد على التوقيت. تداخل يظهر مرّة كلّ عشرات الآلاف من التشغيلات على آلة تطوير يمكن أن يحدث كلّ يوم على خادم إنتاج بعدد أنوية وحمل مختلفين. «يتوقّف عن التكرار حين أُرفِق منقِّحاً» و«اختفى حين أضفت تسجيلاً» كلاهما لأنّ الرصد يغيّر التوقيت — سلوك كلاسيكي لخطأ سباق. لهذا بالضبط تشير كلّ مبادئ هذا المقال في اتّجاه تقليل الأماكن التي تحتاج مزامنة، قبل القلق بشأن المزامنة الصحيحة.

2.1. مقدّمة خاصّة بـ Java ── نموذج الذاكرة وhappens-before

فوق ذلك، ما يخصّ Java هو أنّ كيفيّة رؤية البيانات المشتركة تُعرَّف بـ علاقات happens-before في نموذج ذاكرة Java (JMM).

قراءة متغيّرة مشتركة وكتابتها بلا مزامنة لا تصبح «سلوكاً غير معرَّف» بأسلوب C++، لكن يمكن أن ينتج عنها شرعاً استمرار رؤية قيم قديمة، أو ظهور الكتابات بغير ترتيبها. خطأ اتّساق ذاكرة حيث «حلقة تراقب راية boolean، لكنّ القيمة التي غيّرها خيط آخر لا تظهر أبداً» سلوك يسمح به JMM، لا خطأ في JVM.⁵ الأدوات التي تحمي من هذا هي الآليّات التي تُنشئ علاقات happens-before — synchronized وvolatile وأصناف java.util.concurrent. استخدم المجموعات المتزامنة استخداماً صحيحاً وتضمن لك المكتبة «علاقة happens-before بين عمليّة تحديث واسترجاع لاحق».⁸

بعبارة أخرى، يمكن تلخيص التوجيه العملي لـ Java هكذا: لا تتذاكَ بمتغيّرة مشتركة خام. استخدم أدوات java.util.concurrent للمشاركة، ودع المكتبة تُنشئ علاقات happens-before.

3. كيف تُنشئ الخيوط ── ExecutorService والخيوط الافتراضيّة

3.1. فصل المهمّة عن كيفيّة تشغيلها

ExecutorService هو ما يحمل مبدأ «لا تُنشئ الخيوط بنفسك» في Java. يفصل العمل (Runnable / Callable) عن كيفيّة تنفيذه — كم خيطاً، وأيّ طابور — ويترك إنشاء الخيوط وإعادة استخدامها والتخلّص منها للمكتبة.¹

من JDK 21 فصاعداً، صار اختيار كيفيّة التشغيل خياراً ثنائيّاً بسيطاً.²³

flowchart TB
    S["مهمّة تريد تشغيلها تزامنيّاً"] --> Q1{"ما الذي يقود المهمّة؟"}
    Q1 -->|"انتظار I/O في الغالب<br/>استدعاءات HTTP وقاعدة بيانات وملفّات"| VT["خيوط افتراضيّة<br/>Executors.newVirtualThreadPerTaskExecutor<br/>واحدة لكلّ مهمّة، لا تُجمَّع أبداً"]
    Q1 -->|"حساب مرتبط بالمعالج"| PT["بركة ثابتة من خيوط المنصّة<br/>Executors.newFixedThreadPool - تقريباً بعدد الأنوية<br/>أو parallel stream"]
    VT --> LIMIT["قيِّد التزامن نحو الخدمات الخارجيّة<br/>بـ Semaphore، لا بحجم البركة"]

الشكل 3: اختيار كيفيّة تنفيذ العمل من JDK 21 فصاعداً. ارسم الخطّ أوّلاً — «غيِّر كيف تنتظر I/O، ووازِ للحساب» — ثمّ سلِّم أعمال I/O-bound إلى الخيوط الافتراضيّة وأعمال المعالج إلى بركة تقليديّة

هناك تحفّظ واحد في جانب الأعمال المرتبطة بالمعالج. يحدّ Executors.newFixedThreadPool عدد الخيوط، لكن طابوره بلا حدود. في خدمة طويلة العمر تتجاوز فيها الإرسالات المعالجة باستمرار، يُحدّ فقط عدد الخيوط بعدد الأنوية — أمّا المهام المتراكمة في الطابور وبياناتها فتظلّ تأكل الذاكرة. في ذلك النوع من الإعداد، إمّا استخدم ThreadPoolExecutor مباشرة لتهيئة طابور محدود مع سياسة رفض، أو ضع تحكّماً في القبول مثل Semaphore في جهة الإرسال حتّى تتمكّن من تطبيق ضغط عكسي (المبدأ نفسه في نقاش الطوابير في القسم 4).

3.2. لا تُسئ استخدام الخيوط الافتراضيّة

الخيوط الافتراضيّة خيوط خفيفة منفصلة عن خيوط نظام التشغيل: أثناء عمليّة حظر في JDK (I/O والقفل والنوم وما شابه في المكتبة القياسيّة) تُحرّر خيط نظام التشغيل، ولهذا يمكن لـ JVM واحدة أن تشغّل ملايين منها. لكنّها لا تحرّره لكلّ نوع من الحظر. إن حُظر خيط افتراضي أثناء تنفيذ شيفرة أصليّة (JNI) أو دالّة أجنبيّة، يبقى مثبتاً على خيطه الحامل. ما أصلحه JDK 24 (JEP 491، أدناه) كان التثبيت الذي يسبّبه synchronized؛ أمّا التثبيت عند الحدود الأصليّة فيبقى، لذا فإنّ تحميل عدد كبير من الخيوط الافتراضيّة بعمليّات تحظر طويلاً عبر مولِّد JNI أو واجهة جهاز سيستنفد الخيوط الحاملة. لكن كما يؤكّد الدليل الرسمي، هي ليست «خيوطاً أسرع». سرعة تنفيذ الشيفرة لا تتغيّر — ما توفّره هو المقياس (معدّل الإنتاج).³

هناك ثلاثة ضوابط لاستخدامها.³

1. لا تُجمِّعها في بركة. الخيوط الافتراضيّة رخيصة وقابلة للرمي؛ «عدد المهام = عدد الخيوط الافتراضيّة» هو الحالة الصحيحة. وضع خيوط افتراضيّة في newFixedThreadPool خطأ — استخدم الشكل try (var executor = Executors.newVirtualThreadPerTaskExecutor()).
2. قيِّد التزامن بـ Semaphore. عبِّر عن قيد مثل «عشرة اتّصالات متزامنة على الأكثر بواجهة خارجيّة» بsemaphore، لا بحجم البركة.
3. لا تستخدمها لأعمال مرتبطة بالمعالج. خيوط المنصّة بحجم يقارب عدد الأنوية تبقى الأداة المناسبة لموازاة الحساب، كما من قبل.

لاحظ أنّ ما يعمل داخل خيط افتراضي شيفرة تزامنيّة عاديّة. بدل إعادة كتابة شيفرتك كما يفعل async/await في .NET، فلسفة تصميم الخيوط الافتراضيّة أن تدعك تشغّل شيفرة «خيط واحد لكلّ طلب» المستقيمة، دون تغيير، على مقياس هائل.²

3.3. سوء فهم شائع ── «لا حاجة للتجميع» ينطبق فقط على الخيوط الافتراضيّة

لا تقرأ ضابط «لا تُجمِّعها» بمعنى «ليس في Java شيء اسمه بركة خيوط (أو أنّها غير كفؤة)». الواقع عكس ذلك: برك Java جزء ناضج من المكتبة القياسيّة منذ JDK 5 (2004). البركة العامّة القابلة للتهيئة بدقّة ThreadPoolExecutor (تُنشأ عبر مصانع Executors المختلفة)، وForkJoinPool لسرقة العمل (ومثاله المشترك commonPool() هو هدف التنفيذ الافتراضي لـ parallel stream وCompletableFuture)، وScheduledThreadPoolExecutor للتنفيذ الدوري — هذه ما زالت اللاعبين الرئيسيّين لأعمال المعالج.

البركة في جوهرها تحسين قائم على أنّ «إنشاء خيط نظام تشغيل والإمساك به مكلف، لذا أعد استخدامه». تُلغي الخيوط الافتراضيّة هذه المقدّمة بجعل تكلفة الإنشاء قريبة من الصفر، فلم يعد هناك سبب لإعادة استخدامها — الفهم الدقيق ليس أنّ التجميع صار غير كفء، بل أنّ الخيوط صارت خفيفة بما يكفي ليصبح تحسين التجميع غير ضروري. وتحت الخيوط الافتراضيّة، يشغّل مجدول JDK مجموعة خيوط حاملة (خيوط نظام تشغيل) يقارب عددها عدد الأنوية، كـ ForkJoinPool لسرقة العمل.² بعبارة أخرى، شكل «عالج كمّاً هائلاً من العمل المتزامن ببركة صغيرة من خيوط نظام التشغيل» محفوظ؛ وحده إدارة تلك البركة انتقل من يد المطوّر إلى JVM. من الإنصاف القول إنّ Java تصل إلى الوجهة نفسها التي يصل إليها async/await في .NET، الذي يعيد خيطه إلى البركة عند نقطة await، دون تغيير شكل الشيفرة.

4. تقليل الحالة المشتركة القابلة للتغيير ── التقسيم واللامتغيّر والمجموعات المتزامنة والطوابير

ينشأ التنازع فقط حين يوجد «خيوط متعدّدة» و«بيانات مشتركة قابلة للتغيير» معاً. عدد الخيوط تحدّده المتطلّبات، لذا ما يستطيع التصميم قطعه هو الجزء المشترك. هناك ثلاث عائلات من التقنيات — التقسيم، وجعل الأشياء لامتغيّرة، وتسليم البيانات — وإليك كيف تكتبها في Java.

قسِّمها. للتجميع المتوازي، بدل أن يكتب كلّ خيط إلى متغيّرة مجموع مشتركة، اجعل كلّ خيط يبني نتيجة جزئيّة وادمجها في النهاية. يوفّر reduce / collect في parallel stream هذا الشكل إطاراً، وLongAdder المذكور أدناه كذلك تنفيذ لاستراتيجيّة التقسيم — يشطر داخليّاً إلى خلايا ليوزّع التنازع، ويجمعها عند القراءة. تقليل عدد مرّات الكتابة إلى الحالة المشتركة يأتي قبل كتابة المزامنة صحيحة.

اجعلها لامتغيّرة. ابنِ بيانات بـ record ومجموعات لامتغيّرة (List.copyOf / Map.copyOf) لا تُعاد كتابتها بعد البناء، ويمكنك مشاركتها بلا مزامنة. للإعدادات والبيانات الأساسيّة، النمط القياسي: حين تحتاج استبدالها، ابنِ كائناً جديداً واستبدل مرجعاً volatile. لكن «تبدو للقراءة فقط» و«هي لامتغيّرة» شيئان مختلفان. تُرجع وصولات record المراجع الخام لمكوّناتها، ونسخة List.copyOf أيضاً ضحلة (لا تكرّر كائنات العناصر)، لذا إن كانت العناصر قابلة للتغيير، فمن يملك اسماً مستعاراً يستطيع إعادة كتابة المحتوى، ويبقى التنازع. لا يأمن المشاركة بلا مزامنة إلّا حين يكون رسم الكائنات بالكامل — بما فيه العناصر — لامتغيّراً. إن دخلت عناصر قابلة للتغيير، فإمّا مرِّر نسخة عميقة أو ادفع العناصر أيضاً نحو record / أنواع لامتغيّرة.

استخدم العمليّات المركّبة على المجموعات المتزامنة. لنمط «أنشئه إن غاب، ثمّ أدرجه» في ConcurrentHashMap استخدم computeIfAbsent. هذا المنهج ينفّذ الاستدعاء كلّه ذرّيّاً، وإن غاب المفتاح تُستدعى دالّة الربط مرّة واحدة بالضبط داخل ذلك الاستدعاء الواحد.⁸ الضمان يختلف عن ConcurrentDictionary.GetOrAdd في .NET (الذي يمكن أن تعمل مصنعه أكثر من مرّة تحت التنازع) — نقطة يخلطها بسهولة من ينتقل بين اللغتين. لكنّه ليس «مرّة واحدة بالضبط على مدى حياة المفتاح». إن أرجعت الدالّة null أو رمت، لا يُسجَّل ربط، وتعمل الدالّة من جديد في استدعاء لاحق (الأمر نفسه إن حُذف الإدخال بعد التسجيل). إن لم يحتمل تهيئتك آثاراً جانبيّة مكرّرة، صمِّمها بحيث تنجح الدالّة وترجع غير null. ثمناً للذرّيّة تُحظر بعض تحديثات الخيوط الأخرى أثناء الحساب، لذا أبقِ دالّة الربط قصيرة، ولا تحدِّث هذه الخريطة نفسها من داخل الدالّة (تحديث تعاودي مكتشف يمكن أن يرمي IllegalStateException).⁸

// النمط القياسي لعدّاد تواتر: computeIfAbsent + LongAdder
ConcurrentHashMap<String, LongAdder> freqs = new ConcurrentHashMap<>();
freqs.computeIfAbsent(key, k -> new LongAdder()).increment();

سلِّم البيانات عبر طابور. وجِّه تدفّق البيانات بين الخيوط عبر BlockingQueue. مع ArrayBlockingQueue أُعطي سعة، يحظر put حين يمتلئ، فيعطي ضغطاً عكسيّاً طبيعيّاً — الشكل نفسه للقناة المحدودة في طبعة .NET. حتّى في عصر الخيوط الافتراضيّة، يبقى تصميم رسم حدّ واضح بين المنتج والمستهلك فعّالاً.

5. انضباط الأقفال ── synchronized وReentrantLock

5.1. على ماذا تقفل، وماذا لا تفعل وأنت تمسك قفلاً

فكِّر في وحدة القفل لا كـ «قسم شيفرة» بل كـ «بيانات». اربط كائن قفل واحداً بكلّ مجموعة بيانات قابلة للتغيير تريد حمايتها، وخذ ذلك القفل نفسه في كلّ مكان يلمس تلك البيانات — واقع خطأ السباق عادة أنّ هذا الربط انهار في مكان ما. تجنّب synchronized(this) وsynchronized(SomeClass.class)، لأنّ شيفرة خارجيّة تستطيع قفل الكائن نفسه؛ بدلاً من ذلك اقرن البيانات التي تريد حمايتها واحداً لواحد مع private final Object lock = new Object(); لا يُكشف خارجاً أبداً.

ضابطان إضافيّان فوق ذلك. أوّلاً، لا تفعل شيئاً بطيئاً، ولا شيئاً يلمس العالم الخارجي، وأنت تمسك قفلاً. I/O أو استدعاء مستمعين أو تشغيل شيفرة مجهولة وأنت ما زلت تمسك القفل يطيل مدّة الإمساك ويخاطر بأن يحاول المستدعى أخذ قفل آخر، فيُنشئ الانتظار الدائري من الشكل 2. ثانياً، ثبِّت ترتيب الاكتساب لأقفال متعدّدة. حيث تأخذ قفلين أو أكثر، اجعل قاعدة أنّ كلّ خيط يأخذها بالترتيب نفسه، وللأماكن التي لا تستطيع ضمان الترتيب فيها جهِّز مساراً «تخلَّ وأعد المحاولة إن لم تحصله» بـ tryLock(timeout) المذكور أدناه.

synchronized كافٍ لـ «إقصاء قصير بسيط». انتقل إلى ReentrantLock حين تحتاج ما يلي.

• اكتساب مؤقّت عبر tryLock(timeout) (تحويل تعليقة دائمة إلى فشل تستطيع تسجيله ومعالجته)
• سياسات عدل، أو عدّة Condition، أو حين تريد فصل اكتساب قفل وتحريره عبر مناهج مختلفة

حين تستخدم ReentrantLock، لا تكسر نمط try فوراً بعد lock() وunlock() في كتلة finally (ليس في Java مكافئ لـ RAII في C++، لذا هذا النمط هو الانضباط كلّه).

5.2. الخيوط الافتراضيّة والتثبيت ── ما تغيّر في JDK 24

حين قُدِّمت الخيوط الافتراضيّة أوّل مرّة (JDK 21-23)، كان هناك قيد بأنّ الحظر داخل كتلة synchronized يثبّت الخيط الافتراضي على خيط نظام التشغيل (لا يستطيع تحرير خيط نظام التشغيل، فيفقد فائدة المقياس)، وكان يُنصح باستبدال مواضع الحظر المتكرّرة أو الطويلة بـ ReentrantLock.³ أُزيل ذلك القيد حين أعاد JEP 491 في JDK 24 كتابة تنفيذ المراقب، وصار synchronized لا يثبّت الخيوط الافتراضيّة.⁴ إن كنت على JDK 24 أو أحدث، فلم يعد الاستبدال الآلي لـ synchronized كإجراء مضادّ للتثبيت ضروريّاً. يستحقّ التحقّق ممّا إذا كانت إرشادات منظّمتك الأقدم ما زالت عالقة عند تحذير عصر JDK 21.

5.3. أين تقع الذرّيّات وvolatile

التحديثات الذرّيّة لمتغيّرة واحدة تتولاها AtomicInteger / AtomicLong / AtomicReference (أو، لإحصاءات تُزاد فقط بتواتر عالٍ، LongAdder المقاوم للتنازع). يضمن volatile الرؤية والترتيب (happens-before)، لا الذرّيّة للعمليّات المركّبة.⁵ الاستنتاج نفسه في طبعتي .NET وC++ ينطبق في Java أيضاً: استخدم الذرّيّات للرايات والقيم المفردة، والأقفال للحالة المركّبة، ولا تحاول أن تجعل volatile يفعل ذلك وحده.

6. تصميم كيف تتوقّف ── المقاطعة كلغة مشتركة

6.1. آداب interrupt

الإيقاف والإلغاء في Java موحَّدان حول المقاطعة. يضبط t.interrupt() حالة مقاطعة الخيط المستهدف، وإن كان المستهدف محظوراً في sleep / wait / join أو ما شابه، يرمي InterruptedException ليوقظه فوراً (وعندها تُمسح حالة المقاطعة).⁶ Thread.stop / suspend / resume، الآليّات القسريّة في الماضي، غير آمنة جوهريّاً، لذا يؤدّي استدعاؤها الآن إلى UnsupportedOperationException.⁶

flowchart TB
    OWNER["المستدعي يوقفه - يستدعي t.interrupt"] --> ST["تُضبَط حالة المقاطعة"]
    ST --> A["خيط يحسب:<br/>يستطلع Thread.interrupted في حلقة"]
    ST --> B["محظور في sleep / wait / join:<br/>يُطلَق InterruptedException ويوقظه فوراً<br/>تُمسح الحالة"]
    A --> E["ينظِّف وينهي بنفسه"]
    B --> C{"ماذا يفعل catch؟"}
    C -->|"يستطيع الإنهاء بنفسه"| E
    C -->|"لا يستطيع الإنهاء - مثلاً داخل مكتبة"| R["Thread.currentThread.interrupt<br/>يستعيد الحالة ويترك الإشارة"]
    R --> E

الشكل 4: الإيقاف التعاوني عبر المقاطعة. ابتلاع InterruptedException يجعل إشارة التوقّف تختفي — حين تلتقطه فالخيار إمّا «أنهِ» أو «استعد»

هناك ضابط واحد فقط تحتاج تذكّره في الممارسة: لا تكتب شيفرة تلتقط InterruptedException ولا تفعل شيئاً. إن استطعت الإنهاء ضمن مسؤوليّتك فأنهِ هناك؛ وإن لم تستطع فاستعد الحالة بـ Thread.currentThread().interrupt() ومرِّر الإشارة إلى من استدعاك (انظر الأسئلة الشائعة).

6.2. الإيقاف ذو المرحلتين لـ ExecutorService

واجهات إيقاف ExecutorService تقف فوق نموذج المقاطعة. يوقف shutdown() قبول مهام جديدة ويدع المهام المُرسَلة أصلاً تجري حتّى الاكتمال؛ يحاول shutdownNow() إيقاف المهام الجارية. كمواصفة واجهة هذا أفضل جهد، ومُوثَّق صراحة أنّ تنفيذاً قياسيّاً (مثل ThreadPoolExecutor) يُلغي عادة عبر Thread.interrupt() — بمعنى أنّ مهمّة لا تستجيب للمقاطعة لن تتوقّف حتّى مع shutdownNow، وإن كنت تستخدم تنفيذاً مخصَّصاً لـ Executor فعليك مراجعة وثائقه لترى كيف يُلغي (وما إذا كان يرسل مقاطعة أصلاً).¹ نمط الإيقاف القياسي الذي تعرضه الوثائق الرسميّة هو النمط ذو المرحلتين التالي.¹

/** صحيح متى اكتمل الإيقاف. لا تنتقل إلى تحرير الموارد المشتركة ما دام هذا خاطئاً. */
boolean shutdownAndAwaitTermination(ExecutorService pool) {
    pool.shutdown();                    // المرحلة 1: أوقف قبول مهام جديدة وانتظر الاكتمال
    try {
        if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
            // المرحلة 2: اطلب الإلغاء. المهام التي أُسقطت قبل التشغيل
            // تُرجَع، لذا علِّم Future الخاصّ بها ملغاة لإيقاظ من ينتظر get()
            pool.shutdownNow().forEach(r -> {
                if (r instanceof Future<?> f) f.cancel(false);
            });
            if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
                System.err.println("Pool did not terminate");
                return false;           // لم يكتمل الإيقاف. بلِّغ بشكل يمكن تمييزه عن النجاح
            }
        }
        return true;
    } catch (InterruptedException ex) {
        pool.shutdownNow().forEach(r -> {
            if (r instanceof Future<?> f) f.cancel(false);
        });
        Thread.currentThread().interrupt();   // استعد حالة مقاطعة هذا الخيط أيضاً
        return false;                   // هذا المسار أيضاً قد يترك الإيقاف ناقصاً
    }
}

flowchart TB
    S["shutdown<br/>يوقف قبول مهام جديدة"] --> W1{"awaitTermination<br/>ينتظر الاكتمال"}
    W1 -->|"ينتهي ضمن المهلة"| DONE["اكتمل الإيقاف"]
    W1 -->|"تنتهي المهلة"| NOW["shutdownNow<br/>يرسل مقاطعة للمهام الجارية<br/>الاستجابة أمر يخصّ المهمّة"]
    NOW --> W2{"awaitTermination<br/>ينتظر من جديد"}
    W2 -->|"يكتمل"| DONE
    W2 -->|"ما زال لم ينتهِ"| LOG["سجِّله شذوذاً<br/>اشتبه في مهمّة تتجاهل المقاطعات"]

الشكل 5: الإيقاف ذو المرحلتين لـ ExecutorService. تصميم مرحلي «انتظر بأدب → اطلب عبر المقاطعة → إن لم ينتهِ بعد، راقبه شذوذاً»

هناك حدّ واحد لإلغاء كائنات Runnable التي يرجعها shutdownNow(). ما يعود هو الكائن الذي كان جالساً في طابور التنفيذ — لـ submit عادي هو FutureTask نفسه الذي سُلِّم للمستدعي، لكن للمهام المُرسَلة عبر غلاف مثل ExecutorCompletionService هو الغلاف داخل الطابور، كائن مختلف عن Future المستدعي. في ذلك التكوين لن يُكمل الإلغاء أعلاه Future المستدعي، لذا صمِّم الأمر ليحتفظ بقائمتك من Future عند الإرسال ويُلغي تلك عند الإيقاف (أو يُرجع المهام المُسقَطة إلى مالكها).

close() (AutoCloseable)، المتاح من JDK 19 فصاعداً، يغلِّف «استدعِ shutdown وانتظر الاكتمال» في شكل تستطيع كتابته بـ try-with-resources، وtry (var executor = ...) مع newVirtualThreadPerTaskExecutor للخيوط الافتراضيّة هو الشكل الأساسي الحديث.¹ لكن close() ليس بديلاً للنمط ذي المرحلتين أعلاه. لأنّه ينتظر الاكتمال بلا مهلة، إن لم تستجب مهمّة واحدة للمقاطعة أو لم تنتهِ أبداً، يحظر الخيط الذي يحاول إغلاقه إلى الأبد. هو أداة تناسب نطاقاً تكون فيه المهام محدودة ومضموناً اكتمالها (أرسلها هناك، وانتظرها هناك)؛ لأماكن مثل مسار إيقاف تطبيق، حيث تريد أن ينتهي دائماً ضمن زمن محدود، استخدم النمط ذا المرحلتين المؤقَّت بدلاً منه. إلغاء مهمّة فرديّة كذلك يتمّ عبر المقاطعة، بـ Future.cancel(true).

7. خيط الواجهة ── EDT في Swing

تطبيقات سطح المكتب، بغضّ النظر عن اللغة أو الإطار، تتبع قاعدة أنّ الواجهة تخصّ الخيط الذي يديرها حصراً. في Swing، ذلك الخيط الحصري هو Event Dispatch Thread (EDT): مناهج مكوّنات Swing، كقاعدة، ليست آمنة للخيوط، ولمسها من خيوط متعدّدة يدعو تداخل خيوط وأخطاء اتّساق ذاكرة. اطلب تحديثات الشاشة من خيوط أخرى عبر SwingUtilities.invokeLater إلى EDT، وبالعكس، لأنّ تشغيل عمليّات طويلة على EDT يجمد الواجهة، ادفع العمل الثقيل إلى خيط عامل عبر SwingWorker أو ما شابه.⁷ يتبع JavaFX الشكل نفسه: تُطلب تحديثات الواجهة على خيط التطبيق عبر Platform.runLater.

8. التحقّق والتنقيح ── مقالب الخيوط سلاحاً

لا تتوقّع أن تجد الاختبارات أخطاء السباق. الاختبارات العاديّة تعدّ تشغيلاً لم يحدث فيه تنازع بمحض الصدفة نجاحاً. فكِّر في الدفاع ثلاث طبقات.

خطّ الدفاع الأوّل هو التصميم. في المراجعة، تحقّق بجدول: أيّ بيانات قابلة للتغيير مشتركة، أيّ قفل يحمي كلّ عنصر (الربط من القسم 5.1)، هل ترتيب اكتساب الأقفال فريد، هل تبتلع أيّ كتلة catch InterruptedException، وهل يصل مسار التوقّف (shutdown/المقاطعة) إلى كلّ مهمّة.

ثانياً، أحسن استخدام مقالب الخيوط. لدى Java أداة قياسيّة لالتقاط «حالة كلّ خيط في هذه اللحظة المتجمّدة»: يطبع jstack (أو jcmd <pid> Thread.print) تتبّعات المكدّس، ويضيف الخيار -l معلومات الأقفال أيضاً.⁹ لاحظ أنّ صيغة المقلب التقليديّة هذه لخيوط المنصّة؛ ولا تتضمّن خيوط تطبيقك الافتراضيّة. حين تتتبّع طلباً محظوراً في تكوين يستخدم خيوطاً افتراضيّة (القسم 3)، استخدم jcmd <pid> Thread.dump_to_file -format=json <file>، الذي يستطيع قلب الخيوط الافتراضيّة أيضاً.² الإجراء الأساسي للتحقيق في تعليقة هو أخذ مقلبين أو ثلاثة بفاصل ثوانٍ ومقابلة أيّ قفل ينتظره كلّ خيط خامل، ومن يمسك ذلك القفل. إن سجّلت انتهاء مهلة tryLock(timeout) (القسم 5.2) يمكنك حتّى أتمتة محفّز أخذ المقلب.

ثالثاً، هزّ الأشياء تحت الحمل. اختبار الإجهاد — التشغيل طويلاً بتوازي أكثر من عدد الأنوية، وعشوائية ترتيب المعالجة، وحقن تأخيرات اصطناعيّة — سبيل عملي لجعل «إصابة» حالة سباق أكثر احتمالاً على آلة تطوير. نفِّذ اختباراً واحداً على الأقلّ بحجم بيانات وعدد خيوط بحجم الإنتاج قبل الإصدار.

9. إلى أين يتّجه تزامن Java ── التزامن المنظَّم

نظرة سريعة نصف خطوة إلى الأمام، للختام. مبنيّاً على افتراض الخيوط الافتراضيّة، Structured Concurrency (StructuredTaskScope) — الذي يعامل مهاماً فرعيّة متعدّدة كوحدة عمل واحدة وينظِّم انتشار الفشل والإلغاء — قيد التطوير، وحتّى أغسطس 2026 ما زال ميزة معاينة. عُدِّل إلى شكل واجهة مبنيّ على StructuredTaskScope.open() في المعاينة الخامسة لـ JDK 25 (JEP 505)، ويستمرّ إلى معاينة سادسة (JEP 525) في JDK 26 الحالي.¹⁰¹¹ في الأثناء، Scoped Values، مشاركة سياق لامتغيّرة تحلّ مشكلات ThreadLocal، أُنجزت في JDK 25.¹² مبادئ هذا المقال — حدود مهام واضحة، مشاركة لامتغيّرة، إيقاف تعاوني — تتوافق مع الاتّجاه الذي تسير إليه واجهات البرمجة الجديدة هذه أيضاً.

10. الخلاصة ── قائمة تحقّق Java

1. هل بقي أيّ new Thread في شيفرة الأعمال (هل بُني على ExecutorService / الخيوط الافتراضيّة)؟
2. هل وُجِّهت أعمال I/O-bound وأعمال المعالج إلى آليّات تنفيذ مختلفة (الفرع في الشكل 3)؟
3. هل الخيوط الافتراضيّة غير مجمَّعة في بركة، وهل يُقيَّد التزامن بـ Semaphore؟
4. هل البيانات المشتركة لامتغيّرة (record / List.copyOf)، أو مبنيّة على أدوات java.util.concurrent؟
5. ألا يوجد synchronized(this) أو قفل على كائن مكشوف علناً؟
6. هل تستخدم العمليّات المركّبة لـ ConcurrentHashMap (computeIfAbsent وغيرها) وتُبقي دالّة الربط قصيرة؟
7. ألا تتوقّع ذرّيّة من volatile (هل العدّادات تستخدم أصناف Atomic / LongAdder)؟
8. ألا توجد كتلة catch واحدة تبتلع InterruptedException؟
9. هل يتبع إيقاف ExecutorService النمط ذا المرحلتين المؤقَّت (وهل الأماكن التي تستخدم close() محدودة بنطاقات اكتمال المهام فيها مضمون)؟
10. هل تحديثات واجهة Swing/JavaFX مجمَّعة على EDT / خيط التطبيق؟

Java من أكثر اللغات تجهيزاً بأدوات التزامن، وقد فتح وصول الخيوط الافتراضيّة طريقاً لتوسيع شيفرة تزامنيّة مستقيمة دون إعادة كتابتها. لهذا بالضبط فإنّ الإمساك الصحيح بتقسيم العمل بين الأدوات — أيّها لمعدّل الإنتاج، وأيّها للإقصاء، وما الذي يشير إلى التوقّف — هو جوهر تصميم تعدّد الخيوط في Java.

مقالات ذات صلة

• أفضل الممارسات العمليّة لتعدّد الخيوط: طبعة .NET ── ما الذي تقرّره قبل أن تضيف مزيداً من الخيوط
• أفضل الممارسات العمليّة لتعدّد الخيوط: طبعة C++ ── إزالة الحوادث بالبنية مع RAII وjthread
• أفضل الممارسات العمليّة لتعدّد الخيوط: طبعة C ── الكتابة بأمان على طريقة Win32 API
• أفضل الممارسات لـ C# async/await - جدول قرار لـ Task.Run و ConfigureAwait

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع مراجعات تصميم تعدّد الخيوط لأنظمة الأعمال والمعالجة بالدفعات في Java، والتحقيق في السبب الجذري لعيوب التزامن مثل فساد الحالة المشتركة وأعراض «لا يتوقّف أحياناً / يتجمّد» (تحليل مقالب الخيوط)، والاستشارة التقنيّة حول تبنّي الخيوط الافتراضيّة.

• الاستشارات التقنيّة ومراجعة التصميم
• التحقيق في الأخطاء وتحليل السبب الجذري
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

إن كانت الخيوط الافتراضيّة موجودة الآن، فهل لم نعد نحتاج بركة خيوط (ExecutorService)؟

يعتمد على حالة الاستخدام. الخيوط الافتراضيّة آليّة لتشغيل أعداد هائلة من المهام التي تهيمن عليها انتظار I/O؛ فهي لا تجعل الشيفرة أسرع، بل ترفع معدّل الإنتاج. لأعمال I/O-bound استخدم خيطاً افتراضيّاً واحداً لكلّ مهمّة (Executors.newVirtualThreadPerTaskExecutor) ولا تُجمّع الخيوط الافتراضيّة في بركة أبداً. أمّا لموازاة حساب يستنفد المعالج، فما زالت بركة خيوط المنصّة المحدودة تقريباً بعدد الأنوية (أو parallel stream) هي الأداة المناسبة كما من قبل. وإن أردت تقييد عدد الاتّصالات المتزامنة بخدمة خارجيّة، فالتوصية في عصر الخيوط الافتراضيّة هي التقييد بـ Semaphore لا بحجم البركة.

أيّهما أستخدم، synchronized أم ReentrantLock؟

للإقصاء القصير البسيط يكفي synchronized، وتبقى الشيفرة موجزة. اختر ReentrantLock حين تحتاج ميزات مثل الاكتساب المؤقّت عبر tryLock، أو سياسة عدل، أو عدّة Condition. هناك تحفظ تاريخي عند الجمع مع الخيوط الافتراضيّة: في JDK 21-23 كانت المشكلة أنّ الحظر داخل كتلة synchronized يثبّت الخيط الافتراضي على خيط نظام التشغيل، لذا كان يُنصح باستبدال مواضع الحظر المتكرّرة أو الطويلة بـ ReentrantLock. أعاد JDK 24 (JEP 491) كتابة تنفيذ المراقب وأزال هذا القيد. من JDK 24 فصاعداً لا تحتاج استبدال synchronized لأسباب التثبيت.

هل إضافة volatile تجعل شيئاً آمناً للخيوط؟

لا. يُنشئ volatile في Java علاقة happens-before بين كتابة تلك المتغيّرة وقراءتها، فيضمن الرؤية (أن ترى الخيوط الأخرى أحدث كتابة) والترتيب، لكنّه لا يضمن الذرّيّة لعمليّة مركّبة مثل «اقرأ، احسب، اكتب من جديد». زِد عدّاد volatile int بـ ++ من خيوط متعدّدة فتضيع إضافات. استخدم AtomicInteger / AtomicLong (أو LongAdder للتجميع عالي التواتر) للعدّادات، وقفلاً حين تحمي عدّة متغيّرات معاً. يناسب volatile تقريباً فقط مواقف مثل راية حالة بسيطة — حيث يكتب خيط واحد والآخرون يقرأون فقط.

أيجوز التقاط InterruptedException وتجاهله؟

لا. المقاطعة هي إشارة Java القياسيّة للإيقاف والإلغاء، وابتلاعها يُنشئ خيطاً لا يتوقّف. حين يُرمى InterruptedException تكون حالة المقاطعة قد مُسحت أصلاً، فإن لم تستطع إنهاء العمل بنفسك فإمّا أن تستعيد الحالة بـ Thread.currentThread().interrupt() لتترك الإشارة لمن استدعاك، أو تعيد رمي الاستثناء كما هو. كتلة catch فارغة لا تفعل شيئاً سبب كلاسيكي لأخطاء لا يعمل فيها الإيقاف أو يُتجاهل فيها shutdownNow.

ألا أستطيع إيقاف خيط بـ Thread.stop؟

لا، لا تستطيع. Thread.stop غير آمن جوهريّاً (يُحرّر الأقفال وهو يتركها في حالة غير متّسقة، فيكشف كائنات مكسورة لخيوط أخرى)، لذا أُهمل منذ زمن طويل، واستدعاؤه في Java الحاليّة يرمي UnsupportedOperationException. الأمر نفسه ينطبق على Thread.suspend / resume. السبيل الشرعي الوحيد لإيقاف خيط هو الإيقاف التعاوني عبر المقاطعة. إن كنت تستخدم ExecutorService فإن shutdown يكتفي بوقف قبول مهام جديدة وانتظار الاكتمال — ولا يرسل مقاطعة للمهام الجارية. الذي يحاول إيقاف المهام الجارية هو shutdownNow، وهو أفضل جهد (التنفيذ القياسي يعمل عبر المقاطعة).

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.