Project Loom: مدل جدید همزمانی جاوا را درک کنید

Project Loom با حفظ سازگاری با موضوعات جاوا، کارایی منابع را به شدت افزایش می دهد. در اینجا نگاهی به Loom و نقشه راه پیش رو داریم.

• رشته های مجازی در جاوا
• ادامه‌ها و همزمانی ساختاریافته
• جایگزین‌های رشته‌های مجازی
• کلاس VirtualThread جدید جاوا
• ناهمگام سازی سطح پایین با ادامه
• حذف تماس دنباله دار
• چیز بعدی برای Loom
• لوم و آینده جاوا

Loom یک پروژه جدیدتر در اکوسیستم جاوا و JVM است. پروژه Loom که توسط OpenJDK میزبانی می‌شود، محدودیت‌های موجود در مدل سنتی جاوا را برطرف می‌کند. به ویژه، جایگزین سبک تری برای رشته ها، همراه با ساختارهای زبانی جدید برای مدیریت آنها ارائه می دهد. در حال حاضر مهم ترین بخش Loom، رشته های مجازی بخشی از JDK از جاوا ۲۱ هستند.

برای مروری بر Project Loom و روشی که برای مدرن کردن هم‌زمان جاوا پیشنهاد می‌کند، به ادامه مطلب مراجعه کنید.

رشته های مجازی در جاوا

هم‌زمانی جاوا سنتی با کلاس‌های Thread و Runnable مدیریت می‌شود، همانطور که در فهرست ۱ نشان داده شده است.

Thread thread = new Thread("My Thread") {
      public void run(){
        System.out.println("run by: " + getName());
      }
   };
   thread.start();
   System.out.println(thread.getName());

درک همزمانی جاوای سنتی در موارد ساده نسبتاً آسان است و جاوا یک ثروت ارائه می‌کند. پشتیبانی برای کار با رشته ها.

فیبرها در مقابل رشته‌های مجازی

رشته‌های مجازی برای مدتی «فیبر» نامیده می‌شدند، اما این نام به نفع «رشته‌های مجازی» کنار گذاشته شد تا با فیبرها در زبان‌های دیگر اشتباه گرفته نشود.

عیب این است که رشته‌های جاوا مستقیماً به رشته‌های موجود در سیستم عامل (OS) نگاشت می‌شوند. این محدودیت سختی در مقیاس پذیری برنامه های جاوای همزمان ایجاد می کند. نه تنها دلالت بر یک رابطه یک به یک بین رشته های برنامه و رشته های سیستم عامل دارد، بلکه مکانیزمی برای سازماندهی رشته ها برای چیدمان بهینه وجود ندارد. برای مثال، رشته‌هایی که ارتباط نزدیکی با هم دارند ممکن است فرآیندهای مختلفی را به اشتراک بگذارند، در حالی که می‌توانند از اشتراک‌گذاری پشته در یک فرآیند سود ببرند.

برای اینکه بفهمید تغییرات در Loom چقدر جاه طلبانه هستند، رشته جاوا فعلی، حتی با سرورهای سنگین، در هزاران رشته (حداکثر) محاسبه می شود. Loom پیشنهاد می‌کند این محدودیت را به میلیون‌ها رشته منتقل کند. پیامدهای این امر برای مقیاس‌پذیری سرور جاوا خیره‌کننده است، زیرا پردازش درخواست استاندارد با تعداد موضوعات مرتبط است.

راه حل این است که نوعی رشته مجازی را معرفی کنیم، که در آن رشته جاوا از رشته سیستم عامل اصلی انتزاع می شود و JVM می تواند به طور مؤثرتری رابطه بین این دو را مدیریت کند. Project Loom با معرفی یک کلاس رشته مجازی جدید این کار را انجام می دهد. از آنجایی که کلاس جدید VirtualThread دارای سطح API مشابه رشته های معمولی است، انتقال آن آسان است.

ادامه ها و همزمانی ساختاریافته

ادامه‌ها یک ویژگی سطح پایین است که زیربنای رشته‌های مجازی است. اساساً Continuations به JVM اجازه می دهد تا جریان اجرا را پارک کرده و مجدداً راه اندازی کند.

همانطور که پیشنهاد پروژه Loom بیان می‌کند: p>

یکی دیگر از ویژگی های Loom، همزمانی ساختاریافته، جایگزینی برای معناشناسی رشته برای همزمانی ارائه می دهد. ایده اصلی همزمانی ساختاریافته این است که یک نحو همزمان برای رسیدگی به جریان‌های ناهمزمان به شما ارائه شود (چیزی شبیه به کلیدواژه‌های ناهمگام و منتظر جاوا اسکریپت). این امر برای توسعه دهندگان جاوا بسیار مفید خواهد بود و بیان وظایف ساده همزمان را آسان تر می کند.

اگر تا به حال در معرض Quasar قرار گرفته‌اید، که رشته‌های سبک وزن را از طریق دستکاری بایت کد به جاوا آورده است، شما شاید رهبر فناوری، ران پرسلر را به یاد بیاورید. پرسلر، که اکنون رئیس Loom برای Oracle است، همزمانی ساختاریافته را اینگونه توضیح داد:

اطلاعات بیشتر در مورد همزمانی ساختاریافته

برای کسب اطلاعات بیشتر درباره ساختار یافته، به اسناد جاوا ۲۱ مراجعه کنید همزمانی در عمل.

جایگزین رشته های مجازی

قبل از بررسی دقیق‌تر Loom، بیایید توجه کنیم که روش‌های مختلفی برای همزمانی در جاوا پیشنهاد شده است. به طور کلی، اینها به مدل های برنامه نویسی ناهمزمان می رسد. برخی مانند CompletableFutures و IO غیر مسدود کننده، با بهبود کارایی استفاده از thread، در اطراف لبه ها کار می کنند. سایرین، مانند RXJava (پیاده سازی جاوا ReactiveX)، جایگزین های ناهمزمان عمده فروشی هستند.

اگرچه RXJava یک رویکرد قدرتمند و بالقوه با کارایی بالا برای همزمانی است، اما دارای اشکالاتی است. به ویژه، کاملاً متفاوت از مدل های مفهومی است که توسعه دهندگان جاوا به طور سنتی استفاده می کردند. همچنین، RXJava نمی‌تواند با عملکرد نظری قابل دستیابی با مدیریت رشته‌های مجازی در لایه ماشین مجازی مطابقت داشته باشد.

کلاس VirtualThread جدید جاوا

همانطور که ذکر شد، کلاس جدید VirtualThread یک رشته مجازی را نشان می دهد. در زیر کاپوت، آکروباتیک ناهمزمان در حال انجام است. چرا به جای استفاده از چیزی مانند ReactiveX در سطح زبان، به این مشکل برسیم؟ پاسخ این است که هم درک آن را برای توسعه‌دهندگان آسان‌تر می‌کند و هم انتقال کدهای موجود را آسان‌تر می‌کند. به عنوان مثال، درایورهای ذخیره داده را می توان به راحتی به مدل جدید منتقل کرد.

یک مثال ساده از استفاده از رشته های مجازی در فهرست ۲ نشان داده شده است. توجه داشته باشید که بسیار شبیه به کد Thread موجود است. (این قطعه کد از معرفی Oracle به بافندگی و رشته های مجازی.)

Thread.startVirtualThread(
  () -> {
    System.out.println("Hello World");
  }
);

فراتر از این مثال بسیار ساده، طیف وسیعی از ملاحظات برای زمان بندی وجود دارد. این مکانیسم‌ها هنوز مشخص نشده‌اند و پیشنهاد لوم نمای کلی خوبی از ایده های درگیر ارائه می دهد.

یک نکته مهم در مورد رشته های مجازی Loom این است که هر تغییری که در کل سیستم جاوا مورد نیاز است، نباید کد موجود را خراب کند. کد رشته ای موجود در آینده کاملاً سازگار خواهد بود. می توانید از رشته های مجازی استفاده کنید، اما مجبور نیستید. دستیابی به این سازگاری عقب مانده یک کار نسبتاً هرکول است و بیشتر زمان صرف شده توسط تیم کار بر روی Loom را به خود اختصاص می دهد.

ناهمگام‌سازی سطح پایین با ادامه‌ها

اکنون که رشته‌های مجازی را دیدیم، اجازه دهید نگاهی به ویژگی ادامه‌ها بیندازیم. که هنوز در حال توسعه است. Loom از ادامه در رشته های مجازی و همزمانی ساختاریافته پشتیبانی می کند. همچنین صحبت هایی در مورد در دسترس بودن ادامه به عنوان یک API عمومی برای توسعه دهندگان وجود دارد. بنابراین، ادامه چیست؟

در سطح بالا، ادامه نمایشی در کد جریان اجرا در یک برنامه است. به عبارت دیگر، یک Continuation به توسعه دهنده اجازه می دهد تا با فراخوانی توابع، جریان اجرا را دستکاری کند. مستندات Loom مثالی را در فهرست ۳ ارائه می دهد که تصویر ذهنی خوبی از نحوه کار ادامه ها ارائه می دهد.

foo() { // (2)
  ...
  bar()
  ...
}
bar() {
  ...
  suspend // (3)
  ... // (۵)
}
main() {
  c = continuation(foo) // (0)
  c.continue() // (1)
  c.continue() // (4)
}

جریان اجرا را همانطور که با هر شماره نظر توضیح داده شده است در نظر بگیرید:

• (۰) یک ادامه ایجاد می شود که از تابع foo شروع می شود
• (۱) کنترل را به نقطه ورودی ادامه می دهد
• (۲) تا نقطه تعلیق بعدی که در (۳) است اجرا می شود
• (۳) کنترل را به مبدأ، در (۱) رها می کند
• (۴) اکنون اجرا می شود که در ادامه continue را فراخوانی می کند و جریان به جایی که در (۵) معلق بود برمی گردد

حذف تماس دنباله دار

یکی دیگر از اهداف اعلام شده Loom حذف دم تماس است (که بهینه سازی دم تماس نیز نامیده می شود). این یک عنصر نسبتاً باطنی سیستم پیشنهادی است. ایده اصلی این است که سیستم قادر خواهد بود تا جایی که امکان دارد از تخصیص پشته های جدید برای ادامه ها اجتناب کند. در چنین مواردی، مقدار حافظه مورد نیاز برای اجرای ادامه به جای ساختن مداوم، ثابت باقی می‌ماند، زیرا هر مرحله در این فرآیند مستلزم ذخیره شدن پشته قبلی و در دسترس قرار گرفتن هنگام باز شدن پشته تماس است.

اطلاعات بیشتر در مورد رشته های مجازی

برای آشنایی کامل تر با رشته های مجازی، به معرفی من برای رشته های مجازی در جاوا مراجعه کنید.

چیز بعدی برای Loom

اگرچه در حال حاضر چیزهای زیادی برای کاوش در آنچه توسط Loom ارائه شده وجود دارد، حتی بیشتر برنامه ریزی شده است. از ران پرسلر در مورد نقشه راه پیش رو پرسیدم:

در کوتاه‌مدت، ما در حال رفع مشکلی هستیم که احتمالاً بزرگترین مانع برای پذیرش کاملاً شفاف رشته‌های مجازی است: پین کردن به دلیل همگام‌سازی شده. در حال حاضر، در داخل بلوک‌ها یا روش‌های همگام‌سازی شده، عملیات IO که به طور معمول رشته‌های سیستم‌عامل زیرین را آزاد می‌کنند، آن را مسدود می‌کنند. این پین کردن نامیده می شود، و اگر به طور مکرر و برای مدت طولانی اتفاق بیفتد، می تواند به مزایای مقیاس پذیری رشته های مجازی آسیب برساند. راه‌حل امروز شناسایی آن نمونه‌ها با ابزارهای مشاهده در JDK و جایگزینی آنها با قفل‌های java.util.concurrent است که از پین کردن رنج نمی‌برند. ما در تلاشیم تا از پین کردن همگام‌سازی جلوگیری کنیم تا به این کار نیازی نباشد. علاوه بر این، ما در حال کار بر روی بهبود کارایی زمان‌بندی عملیات IO توسط رشته‌های مجازی هستیم و عملکرد آنها را بیشتر بهبود می‌بخشیم.

در میان‌مدت می‌خواهیم io_uring را، در صورت وجود، برای ارائه مقیاس‌بندی برای عملیات‌های سیستم فایل، علاوه بر عملیات شبکه، ترکیب کنیم. ما همچنین می‌خواهیم زمان‌بندی‌های سفارشی را ارائه دهیم: رشته‌های مجازی در حال حاضر توسط زمان‌بندی برنامه‌ریزی می‌شوند که برای سرورهای همه منظوره مناسب است، اما استفاده‌های عجیب‌تر ممکن است به الگوریتم‌های زمان‌بندی دیگری نیاز داشته باشد، بنابراین مایلیم از زمان‌بندی‌های سفارشی قابل اتصال پشتیبانی کنیم.

در ادامه، می‌خواهیم کانال‌هایی را اضافه کنیم (که مانند مسدود کردن صف‌ها هستند اما با عملیات اضافی مانند بستن صریح) و احتمالاً ژنراتورهایی مانند Python که نوشتن تکرارکننده‌ها را آسان می‌کنند.

>

لوم و آینده جاوا

Loom و جاوا به طور کلی به طور برجسته به ساخت برنامه های کاربردی وب اختصاص داده شده اند. بدیهی است که جاوا در بسیاری از زمینه های دیگر مورد استفاده قرار می گیرد و ایده های معرفی شده توسط Loom ممکن است در برنامه های مختلف مفید باشد. به راحتی می توان دید که چگونه افزایش کارایی thread و کاهش چشمگیر منابع مورد نیاز برای رسیدگی به نیازهای رقیب متعدد منجر به توان عملیاتی بیشتر برای سرورها می شود. مدیریت بهتر درخواست‌ها و پاسخ‌ها یک پیروزی نهایی برای کل برنامه‌های جاوا موجود و آینده است.

مثل هر پروژه جدید جاه طلبانه، Loom بدون چالش نیست. پرداختن به درهم آمیختگی پیچیده رشته ها (مجازی یا غیر مجازی) همیشه پیچیده است، و باید منتظر بمانیم تا ببینیم دقیقاً چه الگوهای پشتیبانی و طراحی کتابخانه ای برای مقابله با مدل همزمانی Loom ظاهر می شود.

تماشای حرکت Project Loom به شاخه اصلی جاوا و تکامل در پاسخ به استفاده در دنیای واقعی بسیار جذاب خواهد بود. همانطور که این اتفاق می افتد، و مزایای ذاتی در سیستم جدید در زیرساختی که توسعه دهندگان به آن متکی هستند (به سرورهای برنامه کاربردی جاوا مانند Jetty و Tomcat فکر کنید) استفاده می شود، می توانیم شاهد یک تغییر دریایی در اکوسیستم جاوا باشیم. .

از قبل، جاوا و رقیب اصلی آن در سمت سرور Node.js گردن و گردن در اجرا. افزایش مرتبه ای از عملکرد جاوا در موارد استفاده معمولی از برنامه های کاربردی وب می تواند چشم انداز را برای سال های آینده تغییر دهد.