الخيوط الافتراضية: التزامن بلا مجمّع خيوط

يعالج خادم Java التقليدي كل طلب على خيط مأخوذ من مجمّع خيوط (pool). وهذا الخيط هو خيط من خيوط نظام التشغيل: يكلّف نحو ميغابايت واحد من المكدس المحجوز، ويُقاس إنشاؤه بمئات الميكروثواني، وعلى النواة أن تتولى جدولته. لذلك لا يُحتفظ إلا بعدد قليل منها — مئتين أو أربعمئة — ويُعاد تدويرها. لكن ماذا يفعل هذا الخيط أثناء الطلب؟ إنه ينتظر. ينتظر PostgreSQL ثماني ميلي ثوانٍ، ثم خدمة HTTP خارجية مئة ميلي ثانية، ثم Redis. وفي طلب مدته مئة وخمسون ميلي ثانية، قد يعمل المعالج ثلاث ميلي ثوانٍ فقط. أما بقية الوقت فمورد نادر وغالٍ محجوز دون أن يفعل شيئًا.

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