लगभग दो दशकों से, जावा में उच्च समवर्ती को संभालने के लिए मानक पैटर्न थ्रेड पूल रहा है। जब भी किसी सर्वर को एक साथ कई अनुरोधों को संसाधित करने की आवश्यकता होती थी, डेवलपर्स ऑपरेटिंग सिस्टम थ्रेड्स की एक निश्चित संख्या को प्रबंधित करने के लिए एक्ज़ीक्यूटर्स को कॉन्फ़िगर करते थे।
लेकिन जावा २१ में वर्चुअल थ्रेड्स (प्रोजेक्ट लूम) के साथ, जावा में समवर्तीता बहुत अलग तरीके से काम करती है।
प्लेटफ़ॉर्म थ्रेड्स के साथ समस्या
परंपरागत रूप से, प्रत्येक P२ एक ऑपरेटिंग सिस्टम (ओएस) थ्रेड में १:१ मैप होता था। इन्हें प्लेटफ़ॉर्म थ्रेड्स के रूप में जाना जाता है।
प्लेटफ़ॉर्म थ्रेड्स भारी होते हैं: १. उच्च मेमोरी ओवरहेड: प्रत्येक ओएस थ्रेड अपने स्टैक के लिए लगभग १-२ एमबी मेमोरी की खपत करता है। १०,००० थ्रेड बनाने के लिए तुरंत १०-२० जीबी रैम की आवश्यकता होती है। २. कंटेक्स्ट स्विचिंग लागत: ओएस कर्नेल इन थ्रेड्स के शेड्यूलिंग को संभालता है। जब कोई थ्रेड ब्लॉक होता है (उदाहरण के लिए, डेटाबेस प्रतिक्रिया या एचटीटीपी कॉल की प्रतीक्षा में), तो कर्नेल को दूसरे थ्रेड पर एक महंगा कंटेक्स्ट स्विच करना पड़ता है। ३. थ्रेड थकावट: उनके वजन के कारण, हमें थ्रेड पूल का उपयोग करके उन्हें सीमित करना पड़ता है (जैसे, टॉमकैट का डिफ़ॉल्ट अधिकतम २००)। यदि आपके एप्लिकेशन में ब्लॉकिंग आई/ओ कॉल में वृद्धि होती है, तो पूल समाप्त हो जाता है, जिससे टाइमआउट और कैस्केडिंग विफलताएं होती हैं।
इसे हल करने के लिए, फ्रेमवर्क ने एसिंक्रोनस / रिएक्टिव प्रोग्रामिंग (जैसे स्प्रिंग वेबफ्लक्स या आरएक्सजावा) पेश किया। इसने कुछ थ्रेड्स पर कई समवर्ती कनेक्शनों को संभालने की अनुमति दी, लेकिन यह एक भारी कीमत पर आया: कोड जटिलता, "कॉल बैक हेल", और टूटे हुए स्टैक निशान।
वर्चुअल थ्रेड्स का प्रवेश
वर्चुअल थ्रेड्स हल्के थ्रेड होते हैं जो ऑपरेटिंग सिस्टम द्वारा नहीं, बल्कि जावा वर्चुअल मशीन (जेवीएम) द्वारा प्रबंधित किए जाते हैं।
कई वर्चुअल थ्रेड्स को अंतर्निहित ओएस कैरियर थ्रेड्स के एक छोटे पूल पर मल्टीप्लेक्स किया जाता है। जब कोई वर्चुअल थ्रेड ब्लॉकिंग आई/ओ कॉल करता है (जैसे डेटाबेस को क्वेरी करना), तो जेवीएम स्वचालित रूप से इसे निलंबित कर देता है, इसकी स्थिति को हीप में ले जाता है। अंतर्निहित ओएस थ्रेड तुरंत दूसरे वर्चुअल थ्रेड को निष्पादित करने के लिए मुक्त हो जाता है।
जब आई/ओ ऑपरेशन पूरा हो जाता है, तो जेवीएम वर्चुअल थ्रेड को वहीं से फिर से शुरू करता है जहां उसने छोड़ा था।
P३ से वर्चुअल थ्रेड बनाना
वर्चुअल थ्रेड बनाना बहुत आसान है:
P०
चूंकि वर्चुअल थ्रेड्स केवल कुछ बाइट्स मेमोरी की खपत करते हैं, इसलिए आपको उन्हें पूल करने की आवश्यकता नहीं है। वास्तव में, वर्चुअल थ्रेड्स को पूल करना एक एंटी-पैटर्न माना जाता है। आप आसानी से एक साथ दस लाख वर्चुअल थ्रेड्स बना सकते हैं:
P१
यह कोड एक मानक लैपटॉप पर लगभग १ सेकंड में पूरा होता है, जो कि प्लेटफ़ॉर्म थ्रेड्स के साथ पूरी तरह से असंभव है।
वर्चुअल थ्रेड्स का उपयोग कब करें
वर्चुअल थ्रेड्स आई/ओ-बाउंड एप्लिकेशन में चमकते हैं। यदि आपकी माइक्रोसर्विस अपना अधिकांश समय डेटाबेस, बाहरी रेस्ट एपीआई या फ़ाइल सिस्टम की प्रतीक्षा में बिताती है, तो वर्चुअल थ्रेड्स आपके थ्रूपुट और संसाधन दक्षता को बड़े पैमाने पर बढ़ा देंगे।
आप सरल, पठनीय और सिंक्रोनस कोड लिखते हुए रिएक्टिव प्रोग्रामिंग के प्रदर्शन लाभ प्राप्त करते हैं। स्टैक निशान बरकरार रहते हैं, और पारंपरिक डिबगर पूरी तरह से काम करते हैं।
वर्चुअल थ्रेड्स का उपयोग कब न करें
वर्चुअल थ्रेड्स हर समस्या का हल नहीं हैं। इनसे बचें जब:
- सीपीयू-बाउंड कार्य: वीडियो एन्कोडिंग, भारी गणितीय गणना, या टाइट लूप। चूंकि वर्चुअल थ्रेड्स अभी भी कैरियर ओएस थ्रेड्स पर चलते हैं, इसलिए वे आपके सीपीयू की गणना को तेज नहीं करेंगे।
- पिन किए गए थ्रेड्स: ऑपरेशन जो नेटिव कोड (जेएनआई) को कॉल करते हैं या P४ ब्लॉक का उपयोग करते हैं, वे वर्चुअल थ्रेड को उसके कैरियर ओएस थ्रेड में "पिन" कर सकते हैं, जिससे जेवीएम को इसे स्वैप करने से रोका जा सकता है। वर्चुअल थ्रेड्स को अपनाते समय P५ ब्लॉक को P६ में माइग्रेट करें।
बेंचमार्किंग और प्रदर्शन विश्लेषण
पारंपरिक प्लेटफ़ॉर्म थ्रेड्स की तुलना में वर्चुअल थ्रेड्स के व्यावहारिक प्रभाव को देखने के लिए, मैंने एक आई/ओ-बाउंड वर्कलोड के तहत मानक टॉमकैट थ्रेड पूल प्रदर्शन (एक स्प्रिंग बूट ३.x ऐप का उपयोग करके) की तुलना करते हुए एक बेंचमार्क चलाया।
लोड परीक्षण ने प्रत्येक अनुरोध के लिए १००एमएस के सिम्युलेटेड आई/ओ विलंब के साथ विभिन्न समरूपता स्तरों (५०, १५०, ३००, ५००, १०००) पर कुल ३,००० अनुरोधों का अनुकरण किया। संपूर्ण कोडबेस और सेटअप [गिटहब रिपॉजिटरी](P८) में पाया जा सकता है।
थ्रूपुट तुलना (अधिक बेहतर है)
| समरूपता | प्लेटफ़ॉर्म थ्रेड्स (अनुरोध/सेकंड) | वर्चुअल थ्रेड्स (अनुरोध/सेकंड) | स्केल सुधार |
|---|---|---|---|
| ५० | ४६७.२६ | ४५५.२८ | ०.९७x |
| १५० | १३१६.२४ | १२८८.७९ | ०.९८x |
| ३०० | १७६८.७९ | २२९७.४१ | १.३०x |
| ५०० | १७८०.१२ | ३४५१.०८ | १.९४x |
| १००० | १७५४.७६ | ५०७०.७४ | २.८९x |
विलंबता तुलना (कम बेहतर है)
| समरूपता | प्लेटफ़ॉर्म विलंबता (औसत / पी९५) | वर्चुअल विलंबता (औसत / पी९५) | विलंबता में कमी |
|---|---|---|---|
| ५० | १०७.०एमएस / १०८एमएस | १०९.८एमएस / ११०एमएस | -२.६% (ओवरहेड सीमा) |
| १५० | ११४.०एमएस / १११एमएस | ११६.४एमएस / ११३एमएस | -२.१% (ओवरहेड सीमा) |
| ३०० | १६९.६एमएस / २१२एमएस | १३०.६एमएस / ११६एमएस | २३.०% |
| ५०० | २८०.९एमएस / ३६२एमएस | १४४.९एमएस / १३६एमएस | ४८.४% |
| १००० | ५६९.९एमएस / ७११एमएस | १९७.२एमएस / २६०एमएस | ६५.४% |
परिणामों की कल्पना करना

प्रमुख अवलोकन
१. कम समरूपता (<= २००)**: २०० से कम समरूपता (टॉमकैट की अधिकतम थ्रेड पूल सीमा से नीचे) के तहत, प्लेटफ़ॉर्म थ्रेड्स और वर्चुअल थ्रेड्स समान रूप से प्रदर्शन करते हैं। यह दर्शाता है कि वर्चुअल थ्रेड्स सीधे सीपीयू कोड निष्पादन को तेज़ नहीं करते हैं; वे केवल अधिक लोड (स्केल) को सक्षम बनाते हैं। २. **कतारबद्धता की समस्या (> २००): जैसे ही समरूपता टॉमकैट की अधिकतम थ्रेड सीमा (२००) से अधिक हो जाती है, प्लेटफ़ॉर्म थ्रेड्स पूल समाप्त हो जाता है। आने वाले अनुरोध टीसीपी कतार में प्रतीक्षा करते हैं, जिससे औसत विलंबता तेजी से बढ़ती है (उदाहरण के लिए १००० समरूपता पर ५६९.९एमएस)। ३. थ्रूपुट स्केलिंग: प्लेटफ़ॉर्म थ्रेड्स का थ्रूपुट लगभग १७८० अनुरोध/सेकंड (२०० थ्रेड × १० अनुरोध/सेकंड/थ्रेड) पर सीमित हो जाता है। वर्चुअल थ्रेड्स समरूपता को शालीनता से संभालते हैं, थ्रूपुट को ५०७०.७४ अनुरोध/सेकंड (एक २.८९x सुधार) तक बढ़ा देते हैं, जबकि औसत विलंबता को २००एमएस से कम रखते हैं।
निष्कर्ष
जावा २१ के वर्चुअल थ्रेड्स जावा ८ की लैम्ब्डा के बाद समवर्तीता में बड़े बदलावों में से एक हैं। थ्रेड्स को सस्ता बनाकर, प्रोजेक्ट लूम जटिल रिएक्टिव कोड और बहुत बड़े थ्रेड पूल की जरूरत कम करता है, और उच्च-समवर्ती जावा ऐप्स लिखना आसान बनाता है।
