virtual thread — Java 21-এর হালকা thread, লাখো অপেক্ষার সহজ সমাধান

১ · এক request, এক thread — সহজ মডেল আর তার দেয়াল

পর্ব ৪০-এ আপনি thread দেখেছেন — একটি প্রোগ্রামের ভেতরে একসাথে চলা আলাদা কাজের ধারা। পর্ব ৪১-এ দেখেছেন thread pool আর ExecutorService, যেখানে কয়েকটি thread বারবার কাজ নেয়। এবার একটি অনলাইন দোকানের সার্ভার ভাবুন। ঈদের আগের রাতে একসাথে দশ হাজার ক্রেতা “আমার কার্ট দেখাও” চাপলেন। প্রতিটি request-এর কাজ মোটামুটি এমন:

Cart handle(Request req) {
    User user   = userDb.find(req.userId());       // ডেটাবেসের উত্তরের অপেক্ষা
    Cart cart   = cartDb.load(user.id());          // আবার অপেক্ষা
    Price price = priceApi.fetch(cart.items());    // অন্য সার্ভারের অপেক্ষা
    return cart.withPrice(price);
}

কোডটি ওপর থেকে নিচে পড়া যায়, ভুল হলে stack trace-এ ঠিক লাইনটি দেখা যায়, ডিবাগারে ধাপে ধাপে চালানো যায়। প্রতিটি request-কে একটি আলাদা thread দিলে এই সহজ কোডই যথেষ্ট — একে বলে thread-per-request মডেল। বহু বছর ধরে Java সার্ভার (Tomcat, Jetty) এভাবেই চলেছে।

সমস্যা লুকিয়ে আছে মন্তব্যগুলোতে: “অপেক্ষা”। একটি সাধারণ request হয়তো সব মিলিয়ে ১০০ মিলিসেকেন্ড নেয়, কিন্তু তার মধ্যে CPU সত্যিই কাজ করে হয়তো ১-২ মিলিসেকেন্ড। বাকিটা thread বসে থাকে — ডেটাবেসের উত্তর, নেটওয়ার্কের প্যাকেট। এই অপেক্ষাকে বলে blocking I/O: thread ঘুমিয়ে থাকে, কিন্তু নিজের জায়গা ছাড়ে না।

কেন thread বাড়ালেই হয় না

Java 1.2-1.3-এর সময় থেকে প্রতিটি সাধারণ java.lang.Thread আসলে অপারেটিং সিস্টেমের একটি OS thread-এর পাতলা মোড়ক — এক Java thread, এক OS thread. Java 21-এ এদের নাম দেওয়া হয়েছে platform thread. প্রতিটির খরচ:

• বড় stack: প্রতিটি thread-এর নিজের call stack লাগে। 64-bit Linux বা Windows-এ ডিফল্টে সাধারণত প্রায় ১ MB জায়গা সংরক্ষিত (reserve) থাকে (-Xss দিয়ে বদলানো যায়)। পুরোটা সাথে সাথে আসল RAM খায় না, কিন্তু ঠিকানার জায়গা আর OS-এর হিসাব আটকে রাখে।
• তৈরি ও ধ্বংসে খরচ: প্রতিবার OS-এর কাছে আবেদন — এ জন্যই পর্ব ৪১-এ thread pool দিয়ে thread বারবার ব্যবহার করা হয়েছিল।
• OS-এর scheduler-এর ভার: হাজার হাজার thread-এর মধ্যে CPU ভাগ করতে context switch লাগে, যা নিজেই সময় খায়।
• সীমা: একটি সাধারণ সার্ভারে কয়েক হাজার thread-এর পর মেমরি বা OS-এর সীমায় পৌঁছানো যায়; তখন নতুন thread তৈরি করতে গেলে OutOfMemoryError আসে (বার্তায় বলা থাকে native thread তৈরি করা যায়নি)।

ফল: সার্ভারের CPU হয়তো ৫% ব্যস্ত, অথচ thread শেষ — নতুন ক্রেতা অপেক্ষায়। একে বলে thread-এর সংখ্যাই throughput-এর সীমা। সার্ভার কতগুলো request প্রতি সেকেন্ডে সামলাবে, তা ঠিক করছে CPU নয়, একসাথে কতগুলো thread রাখা যায় তা।

২ · async আর reactive — সমাধান, কিন্তু চড়া দামে

thread কম, অপেক্ষা বেশি — এই সমস্যার প্রথম সমাধান ছিল: অপেক্ষার সময় thread-কে বসিয়ে রাখব না। ডেটাবেসে প্রশ্ন পাঠিয়ে thread ফিরে যাবে অন্য কাজে, আর উত্তর এলে একটি callback চালানো হবে। পর্ব ৪১-এর CompletableFuture ঠিক এই ধাঁচ:

CompletableFuture<Cart> handle(Request req) {
    return userDb.findAsync(req.userId())
        .thenCompose(user -> cartDb.loadAsync(user.id()))
        .thenCompose(cart -> priceApi.fetchAsync(cart.items())
                                     .thenApply(cart::withPrice))
        .exceptionally(e -> Cart.empty());
}

এভাবে অল্প কয়েকটি thread দিয়ে লাখো সংযোগ সামলানো যায় — Netty, Vert.x, Spring WebFlux-এর মতো reactive programming framework এই নীতিতেই বানানো। কিন্তু দাম আছে:

অর্থাৎ বাছাই ছিল দুটির একটি: সহজ কোড কিন্তু কম scale, অথবা বড় scale কিন্তু কঠিন কোড। Virtual thread-এর লক্ষ্য দুটোই একসাথে দেওয়া — ব্লকিং কোড লিখুন, scale পাবেন async-এর মতো।

৩ · virtual thread কী — carrier, mount আর unmount

Virtual thread হলো এমন একটি Thread, যাকে OS চেনে না — JVM নিজে চালায়। Java 19-এ preview হিসেবে আসে (JEP 425), Java 20-এ দ্বিতীয় preview, আর Java 21 (সেপ্টেম্বর ২০২৩)-এ স্থায়ী হয় JEP 444-এর মাধ্যমে। কোনো flag লাগে না।

মূল কৌশল: virtual thread নিজে কোনো CPU-তে চলে না। চলার সময় সে একটি সাধারণ platform thread-এর পিঠে চড়ে — সেই platform thread-কে বলে carrier thread. Carrier-গুলো একটি ForkJoinPool-এর thread, ডিফল্টে সংখ্যায় মোটামুটি CPU core-এর সমান। একটি virtual thread যখন ব্লকিং কাজে পৌঁছায় — Thread.sleep, socket থেকে পড়া, java.util.concurrent-এর lock বা queue-তে অপেক্ষা — তখন JVM তাকে carrier থেকে নামিয়ে দেয়। তার চলমান অবস্থা, অর্থাৎ stack-এর ফ্রেমগুলো, একটি continuation object হিসেবে heap-এ রাখা হয়। Carrier মুক্ত, সে আরেকটি অপেক্ষমাণ virtual thread তুলে নেয়।

প্রস্তুত সারি: A  B  C  D  … (১০,০০০টি)
carrier C1: খালি     carrier C2: খালি
ধরা যাক মেশিনে ২টি core — তাই carrier ২টি

C1 ← A   (A-র কোড চলছে)
C2 ← B   (B-র কোড চলছে)
সারি: C  D  E  …
virtual thread চলে শুধু carrier-এর পিঠে চড়ে

A: cartDb.load(...)  → socket থেকে পড়া — উত্তর এখনো আসেনি
A-র stack ফ্রেম ──► heap-এ continuation
C1: খালি!
A নেমে গেল (unmount) — OS thread ঘুমায়নি

C1 ← C   (সারির পরেরটি)
C2 ← B   (এখনো চলছে)
heap: A (অপেক্ষায়)
কোনো carrier অলস বসে নেই

OS জানাল: A-র socket-এ ডেটা এসেছে
A → আবার প্রস্তুত সারিতে
সারি: D  E  …  A
A এখনো heap-এ, কোনো carrier-এ নয়

B শেষ হলো → C2 ← A
A-র stack heap থেকে ফেরত, পরের লাইন থেকে চলা শুরু
A-র কাছে মনে হলো load() শুধু একটু সময় নিয়েছে

এই পুরো নকশাকে বলে M:N scheduling: M সংখ্যক virtual thread চলে N সংখ্যক OS thread-এর ওপর, যেখানে M অনেক বড়। Scheduler-টি পর্ব ৩৫-এর parallel stream-এর মতোই work stealing করে, তবে এখানে FIFO ক্রমে।

৪ · মেমরির ছবি — ১০,০০০ platform বনাম ১০,০০০ virtual

সংখ্যাগুলো পাশাপাশি রাখলে পার্থক্যটা স্পষ্ট হয়। নিচের সংখ্যাগুলো মোটা দাগের — আসল মান OS, JDK সংস্করণ আর stack-এর গভীরতার ওপর নির্ভর করে।

Java Thread ──► OS thread (kernel জানে)
stack: আগে থেকেই ~1 MB জায়গা সংরক্ষিত (-Xss)
তৈরি: OS-এর কাছে system call
একটি-দুটিতে কোনো সমস্যা নেই

10,000 × ~1 MB  ≈  ~10 GB ঠিকানার জায়গা সংরক্ষিত
OS scheduler: ১০,০০০ thread-এর মধ্যে core ভাগ
বেশিরভাগ ঘুমিয়ে, তবু প্রতিটি জায়গা আটকে রেখেছে
OS-এর thread-সীমায় পৌঁছালে OutOfMemoryError

Java Thread object (heap-এ) + stack chunk (heap-এ)
শুরুতে খুব ছোট; call stack গভীর হলে বাড়ে, ছোট হলে কমে
তৈরি: সাধারণ object তৈরির মতো — OS জানেই না
GC অন্য object-এর মতোই এদের মেমরি ফেরত নেয়

10,000 × (কয়েকশো byte থেকে কয়েক KB) → সব মিলিয়ে সাধারণত কয়েক MB
carrier: মাত্র core-এর সমান সংখ্যক OS thread
১০ লাখ virtual thread-ও সাধারণ মেশিনে সম্ভব

২০০টি platform thread-এর pool বনাম virtual thread — ১০,০০০টি অপেক্ষার কাজ

JEP 444-এ নিজেই এই পরীক্ষাটি আছে। ১০,০০০টি কাজ, প্রতিটি ১ সেকেন্ড ঘুমায় (ডেটাবেসের অপেক্ষার ভান)। পর্ব ৪১-এর মতো Executors.newFixedThreadPool(200) দিলে একসাথে চলে মাত্র ২০০টি, তাই ১০,০০০ ÷ ২০০ = ৫০ দফা — মোট সময় মোটামুটি ৫০ সেকেন্ড, অর্থাৎ প্রতি সেকেন্ডে প্রায় ২০০টি কাজ। একই কোডে শুধু executor বদলে Executors.newVirtualThreadPerTaskExecutor() দিলে সব ১০,০০০টি একসাথে ঘুমায় — মোট সময় মোটামুটি ১ সেকেন্ডের কাছাকাছি (সাথে কিছু বাড়তি খরচ)। কোডের আর একটি অক্ষরও বদলায়নি। এটাই Little's law: W একই রইল, L বাড়ল ৫০ গুণ, তাই throughput-ও প্রায় ৫০ গুণ।

৫ · virtual thread তৈরি — চারটি উপায়, একটি পছন্দের

Thread.ofVirtual() একটি Thread.Builder দেয়; একই ধাঁচে Thread.ofPlatform() দিয়ে platform thread-ও বানানো যায়। Virtual thread সবসময় daemon thread — অর্থাৎ শুধু virtual thread বাকি থাকলে JVM তাদের জন্য অপেক্ষা না করেই বন্ধ হতে পারে। তাই ফল দরকার হলে join() করুন বা executor ব্যবহার করুন। এদের priority-ও বদলানো যায় না। এবার সেই দশ হাজার ক্রেতার সার্ভার, ছোট আকারে:

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.*;
class Main {
    static int askDatabase(int requestId) throws InterruptedException {
        Thread.sleep(10);                       // ডেটাবেসের উত্তরের অপেক্ষা (ভান)
        return requestId % 7;                   // ধরা যাক, কার্টে কয়টি পণ্য
    }

    public static void main(String[] args) throws Exception {
        Thread one = Thread.ofVirtual().start(() -> System.out.println("একটি virtual thread চলছে"));
        one.join();
        System.out.println("isVirtual = " + one.isVirtual());
        List<Future<Integer>> results = new ArrayList<>();
        try (ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 10_000; i++) {
                int id = i;
                results.add(pool.submit(() -> askDatabase(id)));   // প্রতি request-এ নতুন virtual thread
            }
        }                                       // close() সব কাজ শেষ হওয়া পর্যন্ত অপেক্ষা করে
        int total = 0;
        for (Future<Integer> f : results) total += f.get();          // জমা দেওয়ার ক্রমেই
        System.out.println(results.size() + "টি request শেষ, মোট পণ্য = " + total);
    }
}

বাস্তব উদাহরণ — ধীর API থেকে ১,০০০ পণ্যের দাম

একটি তুলনামূলক দামের সাইট ১,০০০টি পণ্যের দাম একটি সরবরাহকারীর API থেকে আনে; প্রতিটি ডাকে প্রায় আধা সেকেন্ড লাগে। একটি একটি করে আনলে প্রায় ৫০০ সেকেন্ড। Virtual thread দিয়ে লেখা একেবারে সাধারণ ব্লকিং কোড (এই অংশটি অনলাইনে চালানো যাবে না — বাইরের নেটওয়ার্ক নেই):

HttpClient http = HttpClient.newHttpClient();
List<Future<String>> prices = new ArrayList<>();
try (var pool = Executors.newVirtualThreadPerTaskExecutor()) {
    for (String id : productIds) {                      // ১,০০০টি পণ্য
        var req = HttpRequest.newBuilder(URI.create(API + id)).build();
        prices.add(pool.submit(() ->
            http.send(req, HttpResponse.BodyHandlers.ofString()).body()));   // ব্লকিং send — কোনো সমস্যা নেই
    }
}
// এখানে সব দাম হাতে; prices.get(i).resultNow() — productIds-এর ক্রমেই

কোনো callback নেই, কোনো thenCompose নেই — শুধু http.send, যা উত্তর না আসা পর্যন্ত আটকে থাকে। কিন্তু আটকে থাকে virtual thread, carrier নয়। মোট সময় প্রায় সবচেয়ে ধীর একটি ডাকের সমান — যদি সরবরাহকারী একসাথে ১,০০০টি ডাক মেনে নেয়। না নিলে? সেটাই অংশ ৭-এর Semaphore-এর গল্প।

৬ · কোথায় কাজে লাগে, কোথায় লাগে না

CPU-ভারী কাজের জন্য আগের সমাধানই ঠিক: core-এর সমান thread-এর একটি pool, অথবা পর্ব ৩৫-এর parallel stream বা ForkJoinPool. বরং virtual thread-এ লম্বা CPU-ভারী কাজ দিলে একটি সূক্ষ্ম সমস্যা হয়: Java 21-এর scheduler virtual thread-কে জোর করে থামায় না (time slicing নেই); একটি virtual thread নিজে ব্লক না করা পর্যন্ত carrier ছাড়ে না। কয়েকটি এমন কাজ সব carrier দখল করে রাখলে হাজারো ছোট I/O কাজ সারিতে আটকে থাকে।

৭ · pinning, Semaphore আর ভালো অভ্যাস

Pinning — যখন virtual thread নামতে পারে না

কিছু অবস্থায় ব্লক করার সময় virtual thread carrier থেকে নামতে পারে না; carrier-ও তার সাথে আটকে থাকে। একে বলে pinning. Java 21-এ দুটি প্রধান কারণ:

• synchronized block বা method-এর ভেতরে ব্লক করা — পর্ব ৪০-এর synchronized-এর monitor lock carrier-এর পরিচয়ের সাথে বাঁধা, তাই Java 21-এর JVM তখন virtual thread-কে সরাতে পারে না। synchronized-এর ভেতরে Object.wait()-ও একই।
• native method বা foreign function-এর ভেতর দিয়ে ডাকা — stack-এ C কোডের ফ্রেম থাকলে JVM সেটা heap-এ সরাতে পারে না।

1synchronized (cache) {           // monitor নেওয়া2    data = db.query(id);         // ব্লকিং I/O3}4lock.lock();                      // ReentrantLock5try { data = db.query(id); }6finally { lock.unlock(); }

Pool করবেন না — সীমা দিন Semaphore দিয়ে

পর্ব ৪১-এ thread pool-এর আকার দুটি কাজ করত: thread-এর খরচ বাঁচানো, আর একসাথে কতগুলো কাজ চলবে তার সীমা। Virtual thread-এ প্রথম কাজটির আর দরকার নেই। দ্বিতীয়টির আছে — ধরুন আপনার ব্যাংক বা মোবাইল অপারেটরের SMS গেটওয়ে বলে দিয়েছে, একসাথে ৫০টির বেশি অনুরোধ পাঠালে তারা প্রত্যাখ্যান করবে। কিন্তু virtual thread-এর একটি “৫০-এর pool” বানানো ভুল পথ। সীমার জন্য সঠিক যন্ত্র হলো Semaphore: কয়েকটি টোকেনের একটি ঝুড়ি — কাজের আগে একটি টোকেন নিন (acquire), শেষে ফেরত দিন (release). টোকেন না থাকলে অপেক্ষা — আর virtual thread-এর অপেক্ষা সস্তা।

import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;
class Main {
    static final Semaphore gateway = new Semaphore(50);    // গেটওয়ে একসাথে ৫০টির বেশি নেয় না
    static final AtomicInteger inFlight = new AtomicInteger(), peak = new AtomicInteger();
    static boolean sendSms(int customer) throws InterruptedException {
        gateway.acquire();                                   // টোকেন না পেলে এখানে অপেক্ষা
        try {
            peak.accumulateAndGet(inFlight.incrementAndGet(), Math::max);
            Thread.sleep(20);                                // গেটওয়ের উত্তরের অপেক্ষা (ভান)
            return customer % 100 != 0;                      // প্রতি ১০০-তে ১টি নম্বর ভুল (ভান)
        } finally {
            inFlight.decrementAndGet();
            gateway.release();                               // টোকেন ফেরত — সবসময়
        }
    }
    public static void main(String[] args) throws Exception {
        List<Future<Boolean>> results = new ArrayList<>();
        try (var pool = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int c = 1; c <= 2_000; c++) { int id = c; results.add(pool.submit(() -> sendSms(id))); }
        }
        long sent = results.stream().filter(Future::resultNow).count();
        System.out.println("পাঠানো: " + sent + ", ব্যর্থ: " + (results.size() - sent));
        System.out.println("একসাথে ৫০-এর বেশি কখনো? " + (peak.get() > 50));
    }
}

1Semaphore gate = new Semaphore(3);2gate.acquire();          // টোকেন নিন3try { callGateway(); }4finally { gate.release(); }   // ফেরত দিন

ThreadLocal — লাখো thread, লাখো কপি

ThreadLocal প্রতিটি thread-কে একটি ভ্যারিয়েবলের নিজস্ব কপি দেয়। পুরোনো দিনে এটা প্রায়ই একটি cache হিসেবে ব্যবহার হতো — যেমন প্রতিটি thread-এর জন্য একটি দামি SimpleDateFormat বা বড় buffer, কারণ pool-এর ২০০টি thread বছরের পর বছর বেঁচে থাকত, আর ২০০টি কপি কোনো ব্যাপার ছিল না। Virtual thread-এ এই হিসাব উল্টে যায়: প্রতিটি কাজের জন্য নতুন thread, তাই cache কখনো পুনর্ব্যবহার হয় না, আর এক লাখ একসাথের কাজ মানে এক লাখ কপি — মেমরি ফুরিয়ে যেতে পারে। Virtual thread ThreadLocal সমর্থন করে (পুরোনো library ভাঙে না), কিন্তু নতুন কোডে এভাবে cache রাখবেন না; দরকার হলে একটি thread-safe ভাগাভাগির object (যেমন immutable DateTimeFormatter) ব্যবহার করুন।

Request-এর তথ্য (কে লগইন করেছে, কোন transaction) এক method থেকে আরেক method-এ না পাঠিয়ে পৌঁছে দেওয়ার জন্য Java 21-এ একটি নতুন API preview হিসেবে এসেছে: ScopedValue (JEP 446). এটি একটি নির্দিষ্ট পরিসরের জন্য অপরিবর্তনীয় মান বাঁধে, আর পরিসর শেষ হলে নিজে থেকেই মুছে যায় — ThreadLocal-এর মতো remove() ভুলে যাওয়ার ঝুঁকি নেই। Java 21-এ এটি preview feature, অর্থাৎ --enable-preview ছাড়া চলে না; পরের সংস্করণগুলোতে কয়েক দফা preview-এর পর Java 25-এ (JEP 506) এটি স্থায়ী হয়েছে। নিজের JDK সংস্করণের documentation দেখে তবেই ব্যবহার করুন।

Structured concurrency — একসাথে শুরু, একসাথে শেষ

একটি request-এর ভেতরে দুটি কাজ একসাথে চালাতে চাইলেন — দাম আর স্টক। একটি ব্যর্থ হলে অন্যটি বাতিল হওয়া উচিত, আর দুটি শেষ না হলে method ফেরত আসা উচিত নয়। এই ধারণার নাম structured concurrency: কাজের জীবনকাল কোডের block-এর সাথে বাঁধা, ঠিক যেমন try block শেষ হলে ভেতরের সব শেষ। Java 21-এ এর API StructuredTaskScope (JEP 453) শুধু preview — নিচের কোডটি ধারণা বোঝানোর জন্য, সাধারণভাবে চলবে না:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {   // Java 21-এর preview API
    var price = scope.fork(() -> priceApi.fetch(id));    // প্রতিটি fork একটি virtual thread
    var stock = scope.fork(() -> stockDb.count(id));
    scope.join().throwIfFailed();      // দুটির অপেক্ষা; একটি ব্যর্থ হলে অন্যটি বাতিল
    return new Offer(price.get(), stock.get());
}

--enable-preview ছাড়া Java 21-এর javac সরাসরি আপত্তি করে:

prog.java:1: error: StructuredTaskScope is a preview API and is disabled by default.
import java.util.concurrent.StructuredTaskScope;
                           ^
  (use --enable-preview to enable preview APIs)

পরের সংস্করণগুলোতে এই API-র নকশা বদলেছে (যেমন Java 25-এর preview-তে StructuredTaskScope.open()), তাই উপরের রূপটি মুখস্থ করবেন না — ধারণাটা বুঝুন: “যে block কাজগুলো শুরু করে, সেই block-ই তাদের শেষ দেখে।”

৮ · বাস্তব প্রজেক্টে — framework, thread dump আর migration

বেশিরভাগ মানুষ virtual thread নিজে হাতে তৈরি করবেন না; তাঁদের framework করবে। Spring Boot 3.2 থেকে (Java 21 লাগে) একটি সেটিংই যথেষ্ট — তখন embedded Tomcat প্রতিটি HTTP request একটি virtual thread-এ চালায়, আর Spring-এর আরও কিছু অংশও virtual thread ব্যবহার করে। পর্ব ৫০-এ Spring Boot নিজেই আসবে:

spring.threads.virtual.enabled=true

Tomcat আর Jetty-র সাম্প্রতিক সংস্করণ নিজেরাও virtual thread-এ request চালানোর option দেয়; Helidon-এর মতো কিছু framework পুরোপুরি virtual thread ঘিরে নতুন করে লেখা হয়েছে। প্রতিটির নির্দিষ্ট সংস্করণ আর সেটিং তাদের documentation-এ দেখুন — এই এলাকা দ্রুত বদলাচ্ছে।

দেখা ও খোঁজা — thread dump

সমস্যা হলে প্রথম হাতিয়ার thread dump — কোন thread এই মুহূর্তে কোথায় আটকে, তার ছবি। লাখো virtual thread-এর জন্য পুরোনো dump যথেষ্ট নয়, তাই JDK 21-এ jcmd-এর নতুন একটি কমান্ড আছে, যা virtual thread-সহ dump একটি ফাইলে লেখে (সাধারণ লেখা বা JSON):

jcmd <pid> Thread.dump_to_file -format=json threads.json

যেহেতু virtual thread আসল Thread, ব্যর্থ হলে stack trace-এ পুরো ডাকার পথ দেখা যায় — reactive কোডের তুলনায় এটা বিশাল সুবিধা। ডিবাগারেও ধাপে ধাপে চালানো যায়।

Migration-এর চেকলিস্ট

1. JDK 21 বা পরের সংস্করণ — আর আপনার framework ও driver-এর virtual-thread-বান্ধব সংস্করণ।
2. কাজটি কি I/O-bound আর একসাথে অনেক? না হলে লাভ সামান্য।
3. Thread pool-গুলো খুঁজুন: newFixedThreadPool(200)-এর মতো যেগুলো শুধু “অনেক অপেক্ষা” সামলাতে, সেগুলো newVirtualThreadPerTaskExecutor()-এ বদলান। সীমা দরকার হলে Semaphore.
4. নিচের সম্পদের সীমা মনে রাখুন: ১০,০০০ virtual thread একসাথে ডেটাবেসে গেলে connection pool (ধরুন ২০টি connection) এখন আসল সীমা — সেখানে অপেক্ষাও virtual thread-বান্ধব হতে হবে, আর ডেটাবেস নিজে কতটা চাপ নেবে তা ভাবুন।
5. Java 21-এ থাকলে pinning খুঁজুন: ঘন ঘন চলা, ভেতরে I/O থাকা synchronized block → ReentrantLock. JFR বা -Djdk.tracePinnedThreads দিয়ে যাচাই।
6. ThreadLocal-এর cache সরান; per-request তথ্যের জন্য ছোট ThreadLocal চলে, তবে নতুন নকশায় ScopedValue-এর দিকে নজর রাখুন।
7. মাপুন: আগে-পরে load test — throughput, latency, মেমরি। অনুমানে নয়।

৯ · AI-এর যুগে — পুরোনো অভ্যাস নতুন thread-এ

AI-এর শেখার উপাদানের বেশিরভাগই Java 21-এর আগের কোড — যেখানে thread মানেই দামি, pool মানেই ভালো অভ্যাস। তাই virtual thread চাইলে AI প্রায়ই পুরোনো অভ্যাস নতুন API-তে বসিয়ে দেয়:

AI-এর virtual thread কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কাজটি সত্যিই I/O-bound আর একসাথে অনেক; CPU-ভারী অংশ আলাদা platform pool-এ
• কোথাও virtual thread-এর fixed pool নেই; প্রতি কাজে নতুন thread
• বাইরের সম্পদের (API, ডেটাবেস) সীমা Semaphore বা connection pool দিয়ে রক্ষা করা, release finally-তে
• Java 21-এ থাকলে I/O-যুক্ত গরম synchronized block নেই; থাকলে ReentrantLock
• কোনো বড় ThreadLocal cache নেই
• preview API থাকলে সেটা চিহ্নিত, আর JDK সংস্করণ মিলিয়ে দেখা
• executor try-with-resources-এ, ফল জমা দেওয়ার ক্রমে সংগ্রহ; আউটপুট নির্দিষ্ট