تشرح JetBrains كيف تجمع ميزات Project Loom بين الخيوط الافتراضية والقيم المقيّدة والتزامن البنيوي لتقليل كلفة التزامن وتعقيد إدارته في Java. وتوضح المادة أن Structured Concurrency ما تزال ميزة تجريبية في Java 27، بينما أصبحت Virtual Threads مستقرة منذ Java 21 وScoped Values منذ Java 25.
تقدم JetBrains في تدوينة منشورة في 27 أغسطس 2026 قراءة عملية لثلاثة مكونات من Project Loom داخل IntelliJ IDEA: Virtual Threads، وScoped Values، وStructured Concurrency. الفكرة الأساسية ليست إضافة واجهات برمجية منفصلة، بل معالجة ثلاث مشكلات مترابطة في تطبيقات Java المتزامنة: قابلية التوسع، وتمرير السياق بين المهام، وإدارة دورة حياة الخيوط والأخطاء.
توضح المادة أن كتابة كود متعدد الخيوط تظل عرضة لتسرب الخيوط، وابتلاع الاستثناءات، وظروف السباق، وتأخر الإلغاء. كما أن الاعتماد التقليدي على تجمعات الخيوط وCompletableFuture قد يجعل منطق الإلغاء ومعالجة الأخطاء موزعاً على عدة فروع، ما يزيد احتمال عدم تحديثه عند إضافة مهمة متزامنة جديدة.
الخيوط الافتراضية تخفف كلفة الانتظار
تستند الخيوط الافتراضية إلى JEP 444، وهي مستقرة منذ Java 21. وعلى خلاف خيوط المنصة المرتبطة بخيوط نظام التشغيل، تُدار الخيوط الافتراضية بواسطة JVM، ويمكن إنشاؤها بكلفة أقل بكثير. تشير JetBrains إلى أن إنشاء خيط افتراضي يستغرق ميكروثوانٍ بدلاً من ميليثوانٍ، وأن الخيط يحرر خيط المنصة عندما يتوقف بانتظار قاعدة بيانات أو اتصال شبكي أو ملف أو آلية مزامنة.
هذا يجعلها مناسبة خصوصاً لأحمال العمل التي تعتمد على عمليات حجب، إذ تقل الحاجة إلى ضبط حجم تجمعات الخيوط مسبقاً. وتذكر المادة أيضاً أن Java 24 قدمت، عبر JEP 491، تحسيناً يسمح للخيوط الافتراضية المحجوبة داخل أساليب أو عبارات synchronized بتحرير خيط المنصة بدلاً من إبقائه محتجزاً.
سياق مشترك من دون مشكلات ThreadLocal
تعالج Scoped Values، المستقرة منذ Java 25 وفق JEP 506، مشكلة مختلفة. فالتطبيقات تحتاج غالباً إلى تمرير بيانات مثل معرّف الجلسة أو معرّف التتبع إلى أجزاء متعددة من الطلب. وكان ذلك يتم عادة عبر ThreadLocal، لكن قيمه قابلة للتغيير وتظل مرتبطة بعمر الخيط ما لم تُزل يدوياً، الأمر الذي قد يؤدي إلى تسربات في الذاكرة أو مشكلات أمنية. وتشير JetBrains إلى أن أطر عمل مثل Spring قد تستخدم ThreadLocal داخلياً حتى عندما لا يستعمله المطور مباشرة.
تقدم ScopedValue نموذجاً يعتمد على ربط القيمة مرة واحدة ضمن نطاق محدد، ثم إتاحتها تلقائياً للكود الذي يعمل داخله وتنظيفها عند انتهاء النطاق. ولا يمكن تعديل الربط من داخل النطاق، كما تنتقل القيمة إلى المهام الأبناء عند استخدامها مع التزامن البنيوي من دون تمرير صريح للسياق. عملياً، يقل ذلك من عدد نقاط التحكم التي يحتاج المطور إلى متابعتها عند تنفيذ مهام متوازية.
التزامن البنيوي يربط المهام بعمر واضح
يستهدف Structured Concurrency، المبني على JEP 533، المشكلات الهيكلية في الكود المتزامن. لكنه ما يزال في المعاينة السابعة ضمن Java 27، ولذلك لا توصي JetBrains باستخدامه في بيئات الإنتاج حتى الآن. يقوم المفهوم على التعامل مع مجموعة من المهام المرتبطة باعتبارها وحدة عمل واحدة لها مالك وعمر وسياسة فشل واضحة.
في المثال الذي تعرضه JetBrains، يجلب التطبيق سجل طلبات العميل وتوصيات المنتجات بالتوازي لبناء ملف العميل. باستخدام StructuredTaskScope، يمكن تحديد مهلة زمنية مقدارها ثانيتان، واشتراط نجاح المهمتين، وإلغاء المهمة الأخرى تلقائياً إذا فشلت إحداهما أو انتهت المهلة. وبدلاً من تكرار استدعاءات cancel() في فروع معالجة الاستثناءات، تصبح سياسة الإلغاء جزءاً من نطاق المهمة.
تشرح المادة أيضاً حالة مختلفة لا تتطلب نجاح كل المهام: إذا كان التطبيق يحصل على التوصيات من مخزنين مؤقتين ويكفيه أول رد ناجح، يمكن استخدام anySuccessfulOrThrow(). عند وصول نتيجة ناجحة، يُغلق النطاق وتُلغى المهمة الأخرى تلقائياً، أما إذا فشلت المهمتان فيُرفع استثناء يوضح سبب الفشل.
ما الذي يتغير داخل IntelliJ IDEA؟
لا تقتصر الفائدة على صياغة الكود. فمنذ IntelliJ IDEA 2026.1، تُجمع الخيوط الافتراضية التي تُنشأ داخل StructuredTaskScope في حاويات تمثل نطاقاتها، ما يجعل بنية العلاقة بين المهمة الأب والمهام الأبناء ظاهرة في مصحح الأخطاء. وبذلك لا يعرض تفريغ الخيوط قائمة مسطحة من خيوط تجمع عام فقط، بل يوفر مؤشراً أفضل إلى المهام التي تنتمي إلى الطلب نفسه.
لتجربة هذه الميزات، يحتاج المطور إلى Java 27، وهي نسخة Early Access وفق المادة، مع ضبط مستوى اللغة لاستخدام الميزات التجريبية. وتوفر IntelliJ IDEA تنزيل JDK من إعدادات المشروع، كما تعرض تلميحات مضمنة عند استخدام أدوات مثل SDKMAN! أو asdf لإدارة إصدارات JDK. ويمكن إنشاء هيكل أولي لـ StructuredTaskScope باستخدام القالب المباشر sts.
القراءة التحريرية من certi.news
التغيير الفعلي هنا هو انتقال جزء من إدارة التزامن من مسؤولية المطور اليدوية إلى نموذج تعبّر فيه بنية الكود عن عمر المهمة وسياسة فشلها. Virtual Threads تعالج كلفة التوسع، وScoped Values تضبط تمرير السياق، بينما يحاول Structured Concurrency جعل الإلغاء وانتشار الأخطاء قابلين للتوقع. اجتماع هذه الميزات قد يقلل الكود المكرر في التطبيقات التي تنفذ عدة عمليات انتظار بالتوازي.
لكن حدود التطور واضحة: Structured Concurrency لم تصبح مستقرة بعد، وJava 27 كانت نسخة وصول مبكر وقت نشر المادة. لذلك لا تثبت التدوينة أن كل تطبيق سيحقق تحسناً تلقائياً، ولا تلغي الحاجة إلى اختبار سلوك المكتبات والأطر المستخدمة مع هذه النماذج. القيمة الحالية للمطورين تتمثل في فهم النمط وتجربته بأمان، مع إبقاء الميزات التجريبية خارج الإنتاج إلى أن تستقر واجهاتها وتتوفر خبرة تشغيلية كافية.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.