thread আর synchronization — একসাথে অনেক কাজ, নিরাপদে

১ · thread কী — এক দোকানে কয়েকজন ক্যাশিয়ার

এ পর্যন্ত আমাদের প্রতিটি প্রোগ্রাম চলেছে একটিমাত্র পথে: main শুরু হয়, একটার পর একটা statement চলে, শেষ হয়। কিন্তু বাস্তবের সফটওয়্যার — যেমন শত শত গ্রাহকের অনুরোধ একসাথে সামলানো একটি web server — একসাথে অনেক কিছু করে। এর পেছনে আছে thread — একই প্রোগ্রামের ভেতরে একটি স্বাধীন কাজের পথ (path of execution). একটি প্রোগ্রামে অনেকগুলো thread থাকতে পারে, আর তারা একই সময়ে এগোতে পারে।

Process বনাম thread

অপারেটিং সিস্টেমে প্রতিটি চলমান প্রোগ্রাম একটি process — নিজের আলাদা মেমরি নিয়ে। একটি process আরেকটির মেমরিতে সরাসরি হাত দিতে পারে না। java Main চালালে একটি JVM process তৈরি হয়, আর তার ভেতরে শুরুতে একটি thread — main thread — আপনার main method চালায় (পেছনে garbage collector-এর মতো JVM-এর নিজের কিছু thread-ও থাকে)। পর্ব ০৫-এ দেখেছেন, JVM-এর মেমরির দুটি বড় অংশ heap আর stack. এখানে মূল কথা:

তাই নিয়মটা মনে রাখুন: local variable সবসময় নিরাপদ, কারণ সেটা একটি thread-এরই। বিপদ শুধু heap-এর এমন object-এ, যা একাধিক thread ভাগ করে আর অন্তত একজন বদলায়। JVM-এর মেমরি বিন্যাস নিয়ে আরও গভীরে যাবেন পর্ব ৪৪-এ।

Concurrency বনাম parallelism

দুটি শব্দ প্রায়ই গুলিয়ে যায়। Concurrency মানে অনেকগুলো কাজ একই সময়সীমার মধ্যে এগোচ্ছে — হয়তো পালা করে। একজন চা-দোকানি একাই চা বানাচ্ছেন, টাকা নিচ্ছেন, বিস্কুট দিচ্ছেন — এক মুহূর্তে একটি কাজ, কিন্তু সব কাজই এগোচ্ছে। Parallelism মানে আক্ষরিক অর্থে একই মুহূর্তে একাধিক কাজ চলছে — তিনজন দোকানি তিনটি কাজ একসাথে করছেন। এক core-এর CPU-তেও concurrency সম্ভব: অপারেটিং সিস্টেম খুব দ্রুত thread বদলায় — একে বলে context switch — ফলে মনে হয় সব একসাথে চলছে। একাধিক core থাকলে thread-গুলো সত্যিই parallel চলে।

Thread দুটি কারণে দরকার: (ক) অপেক্ষার সময় আটকে না থাকা — নেটওয়ার্ক বা ডিস্কের উত্তরের অপেক্ষায় পুরো অ্যাপ জমে যাবে না; আর (খ) একাধিক core কাজে লাগানো — ভারী হিসাব ভাগ করে দ্রুত শেষ করা। দাম হলো জটিলতা: thread-এর চলার ক্রম অপারেটিং সিস্টেম ঠিক করে, আপনি নন। প্রতিবার চালালে ক্রম আলাদা হতে পারে।

২ · thread তৈরি — Runnable, start(), join() আর জীবনচক্র

Java-তে একটি thread মানে java.lang.Thread class-এর একটি object. কী কাজ করবে, সেটা দেওয়া হয় একটি Runnable দিয়ে — একটি functional interface, যার একটিমাত্র method void run(). তাই পর্ব ৩৪-এর lambda দিয়েই কাজটা লেখা যায়:

Runnable job = () -> System.out.println("রিপোর্ট তৈরি হচ্ছে...");
Thread t = new Thread(job, "report-worker");   // নাম দেওয়া ঐচ্ছিক, debug-এ কাজে লাগে
t.start();      // নতুন thread তৈরি হয়ে job.run() চালায়
t.join();       // main অপেক্ষা করে, যতক্ষণ না t শেষ হয়

পুরোনো বইয়ে দেখবেন class MyThread extends Thread লিখে run() override করা। এটা চলে, কিন্তু আধুনিক কোডে Runnable (বা lambda) আলাদা রাখাই ভালো: কাজ আর কাজ-চালানোর যন্ত্র আলাদা থাকে, আর পরে একই কাজ পর্ব ৪১-এর thread pool-এ পাঠানো যায়।

সবচেয়ে বিখ্যাত ফাঁদ — run() বনাম start()

t.start() অপারেটিং সিস্টেমের কাছে একটি নতুন thread চায়, আর সেই নতুন thread-এ run() চালায়; start() নিজে সাথে সাথে ফেরত আসে। কিন্তু t.run() লিখলে? সেটা একটি সাধারণ method call — কোনো নতুন thread হয় না, কাজটা চলে যে thread ডেকেছে সেখানেই, আর শেষ না হওয়া পর্যন্ত পরের লাইনে যাওয়া যায় না। কোড compile হয়, চলে, ফলও ঠিক আসে — শুধু “একসাথে” কিছুই হয় না। অংশ ৪-এর প্রোগ্রামে নিজের চোখে দেখবেন: run() ডাকলে thread-এর নাম আসে main.

আরও দুটি নিয়ম: একটি Thread object-এ start() মাত্র একবার ডাকা যায়। দ্বিতীয়বার ডাকলে (Wandbox-এ যাচাই করা):

Exception in thread "main" java.lang.IllegalThreadStateException
	at java.base/java.lang.Thread.start(Thread.java:1525)
	at Main.main(Main.java:6)

আর Thread.sleep(ms) বর্তমান thread-কে কিছুক্ষণ ঘুম পাড়ায়। এটি একটি checked exception — InterruptedException — ছুড়তে পারে, তাই না সামলালে compile হয় না:

Main.java:5: error: unreported exception InterruptedException; must be caught or declared to be thrown
        Thread.sleep(100);
                    ^

এই exception-এর মানে কী, অংশ ৫-এ interrupt()-এর সাথে দেখবেন। ছোট উদাহরণে আমরা main-এ throws InterruptedException লিখে দিই।

join() — শেষ হওয়ার অপেক্ষা

t.join() ডাকা thread-কে থামিয়ে রাখে, যতক্ষণ না t শেষ হয়। এটা শুধু অপেক্ষা নয় — একটি নিশ্চয়তাও: t যা যা লিখেছে, join() ফেরত আসার পর ডাকা thread সব দেখতে পাবে (অংশ ৫-এর happens-before). তাই এই পর্বের সব চালানো যায় এমন প্রোগ্রাম একই কৌশলে লেখা: কাজ ভাগ করো, সব thread-এ join(), তারপর ফল ছাপো। এতে আউটপুট প্রতিবার এক হয়।

একটি thread-এর ছয় অবস্থা

t.getState() একটি Thread.State enum ফেরত দেয়। ছয়টি মান — ধাপে ধাপে দেখুন একটি thread কখন কোনটিতে থাকে:

Thread t = new Thread(job);
t.getState()   → NEW
object আছে, কিন্তু অপারেটিং সিস্টেমে কোনো thread নেই

t.start();
t.getState()   → RUNNABLE
CPU-তে চলছে, অথবা core পাওয়ার লাইনে আছে —
Java এই দুটি আলাদা করে না

synchronized (account) {   // অন্য thread তালা ধরে আছে
    ...
}
→ BLOCKED  তালা খালি হলে আবার RUNNABLE

other.join();          → WAITING        (সময়সীমা নেই)
Thread.sleep(500);     → TIMED_WAITING  (সময়সীমা আছে)
lock.wait();           → WAITING
ঘটনা ঘটলে বা সময় ফুরালে আবার RUNNABLE

run() ফেরত এসেছে (বা exception-এ শেষ)
t.getState()   → TERMINATED
t.start()      → IllegalThreadStateException

Daemon thread — পটভূমির সাহায্যকারী

JVM তখনই বন্ধ হয়, যখন সব সাধারণ thread শেষ। কিন্তু প্রতি মিনিটে cache পরিষ্কার করার মতো পটভূমির কাজের জন্য প্রোগ্রাম আটকে থাকা অর্থহীন। t.setDaemon(true) (অবশ্যই start()-এর আগে) দিলে সেটি একটি daemon thread: বাকি সব সাধারণ thread শেষ হলে JVM তার জন্য অপেক্ষা না করেই বেরিয়ে যায়। সতর্কতা: daemon thread মাঝপথে থেমে যেতে পারে, তাই ফাইলে লেখার মতো যে কাজ অর্ধেক থামলে ক্ষতি, সেটা daemon-এ দেবেন না।

৩ · race condition — যখন ফল নির্ভর করে কে আগে পৌঁছাল

এবার বিপদটা দেখি। একটি সাধারণ counter, যা দুটি thread এক লাখ বার করে বাড়ায়। যোগফল হওয়া উচিত দুই লাখ:

class Counter {
    private int count = 0;
    void increment() { count++; }          // synchronized নেই!
    int get() { return count; }
}
// main-এ:
Counter c = new Counter();
Runnable task = () -> { for (int i = 0; i < 100_000; i++) c.increment(); };
Thread a = new Thread(task), b = new Thread(task);
a.start(); b.start();
a.join(); b.join();
System.out.println("count = " + c.get() + " (প্রত্যাশিত 200000)");

এই কোডটি ইচ্ছা করেই চালানোর বোতাম ছাড়া রাখা হয়েছে, কারণ এর আউটপুট নির্দিষ্ট নয়। Wandbox-এ চারবার চালিয়ে পাওয়া একটি সম্ভাব্য আউটপুট (প্রতিবার আলাদা):

count = 187599 (প্রত্যাশিত 200000)     ← প্রথমবার
count = 200000 (প্রত্যাশিত 200000)     ← পরের তিনবার

প্রথমবার বারো হাজারের বেশি যোগ হারিয়ে গেছে। আর পরের তিনবার ফল ঠিক! এটাই race-এর সবচেয়ে বিপজ্জনক দিক — বেশিরভাগ সময় ঠিক চলে, টেস্ট পাস করে, তারপর একদিন production-এ, বেশি load-এ, ভুল টাকার হিসাব। যখন একটি প্রোগ্রামের ফল thread-গুলোর চলার সময়ক্রমের ওপর নির্ভর করে, তাকে বলে race condition.

count++ একটি কাজ নয়, তিনটি

পর্ব ০৭-এ count++-কে একটি increment operator হিসেবে দেখেছেন। দেখতে একটি কাজ, কিন্তু CPU-র কাছে তিনটি আলাদা ধাপ: মেমরি থেকে মান পড়া, এক যোগ করা, ফল মেমরিতে লেখা। এই ধাঁচকে বলে read-modify-write. দুই ধাপের মাঝখানে অপারেটিং সিস্টেম thread বদলে দিতে পারে — আর তখনই:

1// count++ আসলে তিনটি কাজ:2tmp = count;      // ১. পড়া (read)3tmp = tmp + 1;    // ২. বদলানো (modify)4count = tmp;      // ৩. লেখা (write)

এখানে একটি প্রশ্ন আসে: count-কে lambda-র ভেতরে সরাসরি local variable হিসেবে বাড়ালে কী হয়? Java সেটা হতেই দেয় না:

Main.java:4: error: local variables referenced from a lambda expression must be final or effectively final
        Runnable r = () -> count++;
                           ^

পর্ব ৩৪-এর effectively final নিয়মের একটি বড় কারণ ঠিক এটাই — local variable stack-এ থাকে, আর অন্য thread-এ চলা lambda-কে তা বদলাতে দিলে race তৈরি হতো। তাই ভাগাভাগি করা অবস্থা রাখতে হয় একটি object-এর field-এ (যেমন Counter), আর সেখানেই সুরক্ষা লাগে।

Check-then-act — শেষ সিটের লড়াই

Race শুধু counter-এ নয়। আরেকটি প্রচলিত রূপ: আগে শর্ত দেখা, তারপর সেই শর্তের ওপর ভরসা করে কাজ। একটি বাস-টিকিট অ্যাপে ঈদের আগে শেষ সিটটি বাকি:

class Bus {
    private int seatsLeft = 1;
    boolean book(String user) {
        if (seatsLeft > 0) {        // check: সিট আছে?
            seatsLeft--;            // act: সিট নাও
            return true;
        }
        return false;
    }
}

রহিম আর করিম একই মুহূর্তে “বুক করুন” চাপলেন। দুই thread-ই seatsLeft > 0 দেখে true পায় — কেউ তখনো কমায়নি। তারপর দুজনই কমায়: seatsLeft হয় −1, আর দুজনের কাছেই নিশ্চিতকরণ SMS যায়। একে বলে check-then-act ভুল: যাচাই আর কাজের মাঝখানে পৃথিবী বদলে যেতে পারে। একই ভুল ব্যাংকে: একটি যৌথ হিসাবে ১০,০০০ টাকা, স্বামী আর স্ত্রী দুটি ATM থেকে একসাথে ৮,০০০ করে তুলতে চাইলেন — if (balance >= amount) balance -= amount; দুজনের জন্যই সত্য হতে পারে। সমাধান একটাই: যাচাই আর কাজ — দুটোকে একসাথে একটি অবিভাজ্য (atomic) একক বানানো, যাতে মাঝখানে কেউ ঢুকতে না পারে। কোডের যে অংশে এক সময়ে একজনের বেশি ঢোকা চলবে না, তাকে বলে critical section.

৪ · synchronized — এক সময়ে একজন

Java-র প্রতিটি object-এর সাথে জন্ম থেকেই একটি অদৃশ্য তালা থাকে — একে বলে intrinsic lock বা monitor. synchronized keyword সেই তালা ব্যবহার করে: একটি thread তালা নিয়ে ভেতরে ঢোকে, কাজ শেষে বেরোনোর সময় ছেড়ে দেয়; এর মধ্যে একই তালা চাওয়া অন্য সব thread দরজায় অপেক্ষা করে (BLOCKED). এই নিশ্চয়তার নাম mutual exclusion — পারস্পরিক বর্জন। দুটি রূপ:

class Account {
    private long balance;
    private final Object lock = new Object();

    synchronized void deposit(long amt) {      // ১. পুরো method — তালা: this
        balance += amt;
    }
    boolean withdraw(long amt) {
        synchronized (lock) {                  // ২. শুধু একটি block — তালা: lock
            if (balance < amt) return false;   // check আর act একসাথে সুরক্ষিত
            balance -= amt;
            return true;
        }
    }
}

(বাস্তব কোডে একটি class-এর সব জায়গায় একই তালা ব্যবহার করুন — এখানে দুটি রূপ পাশাপাশি দেখানোর জন্য আলাদা।) synchronized instance method-এর তালা হলো this; static synchronized method-এর তালা হলো class object (Account.class). Block রূপে আপনি নিজে বলে দেন কোন object-এর তালা — আর block ছোট রাখা যায়, শুধু যেখানে ভাগাভাগি করা ডেটা ছোঁয়া হয়। Intrinsic lock reentrant: একই thread তালা ধরে থাকা অবস্থায় আবার সেই তালার আরেকটি synchronized method ডাকলে নিজেই নিজেকে আটকায় না।

1synchronized (lock) {        // তালা নাও (না পেলে অপেক্ষা)2    balance += amount;3}                            // তালা ছাড়ো

এবার চালিয়ে দেখুন — প্রথম অংশে run() বনাম start()-এর ফাঁদ আর thread-এর অবস্থা, দ্বিতীয় অংশে দুই thread একসাথে এক লাখ করে জমা দিচ্ছে, কিন্তু synchronized থাকায় কিছু হারায় না:

class Account {
    private long balance;
    synchronized void deposit(long amount) { balance += amount; }   // এক সময়ে একজন
    synchronized long balance() { return balance; }
}
class Main {
    public static void main(String[] args) throws InterruptedException {
        Runnable hello = () -> System.out.println("চলছে: " + Thread.currentThread().getName());
        Thread t = new Thread(hello, "worker-1");
        System.out.println("start-এর আগে: " + t.getState());
        t.run();                      // ফাঁদ: নতুন thread নয়, main-এই চলে
        t.start();                    // ঠিক: নতুন thread তৈরি হয়ে hello চালায়
        t.join();                     // worker-1 শেষ না হওয়া পর্যন্ত main অপেক্ষা করে
        System.out.println("join-এর পর: " + t.getState());
        Account acc = new Account();
        Runnable task = () -> { for (int i = 0; i < 100_000; i++) acc.deposit(1); };
        Thread a = new Thread(task), b = new Thread(task);
        a.start(); b.start();         // দুই thread একসাথে জমা দেয়
        a.join(); b.join();
        System.out.println("synchronized balance = " + acc.balance());
    }
}

ভুল object-এ তালা — সবচেয়ে চুপচাপ bug

তালা কাজ করে শুধু যখন সব thread একই object-এর তালা চায়। এই তিনটি ভুল প্রায়ই দেখা যায়:

• প্রতিবার নতুন তালা: synchronized (new Object()) { balance += amt; } — প্রতিটি thread নিজের নতুন তালা পায়, কেউ কারো জন্য অপেক্ষা করে না। কোনো সুরক্ষাই নেই।
• বদলে যাওয়া field-এ তালা: synchronized (count) যেখানে count একটি Integer — count++ প্রতিবার নতুন Integer object বসায়, তালাও বদলে যায়। তালার field সবসময় private final রাখুন।
• দুই জায়গায় দুই তালা: deposit লেখে synchronized (this)-এ, আর withdraw লেখে synchronized (lock)-এ — একই balance দুটি আলাদা তালায় “সুরক্ষিত”, অর্থাৎ অরক্ষিত। নিয়ম: একটি ডেটার জন্য একটিই তালা।

৫ · দৃশ্যমানতা — Java Memory Model, happens-before আর volatile

Race-এর বাইরেও একটি অদ্ভুত সমস্যা আছে, যা নতুনদের অবাক করে: এক thread একটি মান লিখল, অন্য thread হয়তো সেটা কখনো দেখবেই না। কারণ আধুনিক হার্ডওয়্যার। প্রতিটি CPU core-এর নিজের দ্রুত cache আছে; একটি core নতুন মান হয়তো কিছুক্ষণ নিজের cache-এ রাখে। আর JIT compiler ও CPU গতি বাড়াতে নির্দেশের ক্রম বদলাতে পারে — একটি thread-এর ভেতরে ফল একই থাকলে। একটি thread-এর দিক থেকে সব ঠিক থাকে; অন্য thread থেকে দেখলে ক্রম আর মান অন্যরকম লাগতে পারে।

কোন লেখা কোন thread কখন দেখবে, তার নিয়মকানুন লেখা আছে Java Memory Model (JMM)-এ, Java Language Specification-এর অধ্যায় ১৭-এ। এর কেন্দ্রীয় ধারণা happens-before: যদি কাজ X, কাজ Y-এর আগে “happens-before” সম্পর্কে থাকে, তাহলে X-এর সব লেখা Y দেখতে পাবে। এমন সম্পর্ক না থাকলে কোনো নিশ্চয়তা নেই। প্রধান নিয়মগুলো:

তাই visibility (দৃশ্যমানতা) আর atomicity (অবিভাজ্যতা) দুটি আলাদা সমস্যা। synchronized দুটোই সমাধান করে। কিন্তু কখনো শুধু দৃশ্যমানতা দরকার — যেমন একটি stop flag.

volatile — একটি flag সবাইকে দেখানো

একটি ডাউনলোড চলছে আলাদা thread-এ; ব্যবহারকারী “বাতিল” চাপলে UI thread একটি flag বদলায়:

class Downloader implements Runnable {
    private volatile boolean running = true;   // volatile ছাড়া লুপ হয়তো কখনো থামবে না
    public void run() {
        while (running) {
            downloadNextChunk();
        }
        System.out.println("ডাউনলোড থামল");
    }
    void stop() { running = false; }           // অন্য thread (যেমন UI) ডাকে
}

volatile না থাকলে JMM অনুযায়ী worker thread-এর running-এর নতুন মান দেখার কোনো নিশ্চয়তা নেই। বাস্তবে JIT লক্ষ করতে পারে যে লুপের ভেতরে কেউ running বদলায় না, আর পড়াটা লুপের বাইরে একবারে সরিয়ে নিতে পারে — if (running) while (true) { … } — ফলে লুপ চিরকাল চলে। এটা সব মেশিনে, সব সময় ঘটে না; ঠিক সেজন্যই বিপজ্জনক। volatile বলে দেয়: এই field-এর প্রতিটি পড়া মূল মেমরির সর্বশেষ মান দেখবে, আর লেখার আগের সব লেখাও পাঠকের কাছে দৃশ্যমান হবে।

interrupt() — ভদ্রভাবে থামতে বলা

নিজের flag-এর বদলে Java-র নিজস্ব একটি থামার সংকেত আছে: worker.interrupt(). এটা thread-কে জোর করে থামায় না — শুধু তার গায়ে একটি “থামো” flag বসায়। Thread নিজে Thread.currentThread().isInterrupted() দেখে সিদ্ধান্ত নেয়। আর thread যদি sleep, wait বা join-এ ঘুমিয়ে থাকে, তাকে সাথে সাথে জাগিয়ে InterruptedException ছোড়া হয় — volatile flag এটা পারে না, ঘুমন্ত thread flag দেখে না:

Thread worker = new Thread(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            syncNextFile();
            Thread.sleep(5_000);              // ৫ সেকেন্ড পরপর
        } catch (InterruptedException e) {
            return;                           // থামার অনুরোধ — গুছিয়ে বেরিয়ে যাও
        }
    }
});
worker.start();
// ... পরে, অ্যাপ বন্ধের সময়:
worker.interrupt();

Interrupt হলো সহযোগিতামূলক বাতিল: thread নিজে ঠিক করে কোথায় থামা নিরাপদ। পুরোনো Thread.stop() একটি thread-কে যেকোনো জায়গায় মেরে ফেলত — তালা ছেড়ে, ডেটা অর্ধেক লেখা অবস্থায়; সেজন্য বহু বছর আগে deprecated, আর Java 20 থেকে সেটি আর কাজই করে না — ডাকলে শুধু UnsupportedOperationException আসে। InterruptedException চুপ করে গিলবেন না; নিজে থামতে না পারলে Thread.currentThread().interrupt() দিয়ে flag আবার বসিয়ে দিন।

৬ · তালা ছাড়া নিরাপদ — atomic class, আর ReentrantLock

AtomicInteger — ডাউনলোডের অগ্রগতি গোনা

একটি অ্যাপ চারটি thread দিয়ে একটি ফাইলের ১০০টি টুকরো নামাচ্ছে, আর স্ক্রিনে দেখাচ্ছে “৪৭/১০০ সম্পন্ন”। প্রতিটি thread টুকরো শেষ করে counter বাড়ায়। শুধু একটি সংখ্যা বাড়ানোর জন্য পুরো synchronized লাগে না — java.util.concurrent.atomic package-এর AtomicInteger যথেষ্ট:

AtomicInteger done = new AtomicInteger();
// প্রতিটি worker thread, একটি টুকরো শেষে:
int now = done.incrementAndGet();         // ++ অবিভাজ্যভাবে, নতুন মান ফেরত
System.out.println(now + "/100 সম্পন্ন");  // (বাস্তবে UI-তে দেখানো হয়)

incrementAndGet(), addAndGet(n), getAndIncrement() — সবই পড়া-বদলানো-লেখাকে একটি অবিভাজ্য কাজে পরিণত করে। এর নিচে কোনো তালা নেই; আছে CPU-র একটি বিশেষ নির্দেশ — compare-and-swap (CAS): “মেমরিতে মান যদি এখনো 5 থাকে, তবেই 6 বসাও; নইলে জানাও।” ব্যর্থ হলে thread নতুন মান পড়ে আবার চেষ্টা করে। অংশ ৩-এর stepper-এ B যখন 6 লিখতে যেত, CAS দেখত মান আর 5 নেই (A ইতিমধ্যে 6 করেছে), B-র চেষ্টা ব্যর্থ হতো, B আবার পড়ত 6 আর লিখত 7. কেউ ঘুমায় না, কেউ BLOCKED হয় না। Atomic variable-এর লেখা-পড়া volatile-এর মতো দৃশ্যমানতাও দেয়।

খুব বেশি thread একটি counter নিয়ে কাড়াকাড়ি করলে CAS বারবার ব্যর্থ হয়। তখন Java 8 থেকে আসা LongAdder ভালো: সে ভেতরে কয়েকটি আলাদা ঘর রাখে, প্রতিটি thread সাধারণত নিজের ঘরে যোগ করে, আর sum() ডাকলে সব যোগ করে দেয়। ওয়েবসাইটের hit counter বা metrics-এর জন্য আদর্শ; তবে প্রতি মুহূর্তে সঠিক মান পড়তে হলে AtomicInteger/AtomicLong.

ReentrantLock — যখন synchronized যথেষ্ট নয়

java.util.concurrent.locks-এর ReentrantLock একই কাজ করে — mutual exclusion আর দৃশ্যমানতা — কিন্তু আরও নিয়ন্ত্রণ দেয়। সবচেয়ে কাজের বৈশিষ্ট্য: অপেক্ষার একটি সীমা দেওয়া।

private final ReentrantLock lock = new ReentrantLock();

boolean bookSeat(String user) throws InterruptedException {
    if (!lock.tryLock(2, TimeUnit.SECONDS)) {   // ২ সেকেন্ডে না পেলে হাল ছাড়ো
        return false;                           // "সার্ভার ব্যস্ত, আবার চেষ্টা করুন"
    }
    try {
        if (seatsLeft == 0) return false;
        seatsLeft--;
        return true;
    } finally {
        lock.unlock();                          // সবসময় finally-তে!
    }
}

synchronized থেকে বেরোলে তালা নিজে থেকে ছাড়ে; ReentrantLock ছাড়ে না — unlock() ভুললে বা exception-এ বাদ পড়লে তালা চিরকাল আটকে থাকে। তাই lock()/tryLock()-এর পরেই try, আর unlock() সবসময় finally-তে। বাড়তি সুবিধা — tryLock, lockInterruptibly(), fair ক্রম, একাধিক Condition — না লাগলে synchronized-ই সহজ আর কম ভুলপ্রবণ।

৭ · deadlock — দুজনই অপেক্ষায়, চিরকাল

তালা race সারায়, কিন্তু নতুন একটি বিপদ আনে। দুটি হিসাবের মধ্যে টাকা পাঠানো — দুই হিসাবই একসাথে আটকাতে হবে, যাতে মাঝপথে কেউ অর্ধেক অবস্থা না দেখে:

void transfer(Account from, Account to, long amt) {
    synchronized (from) {
        synchronized (to) {
            from.withdraw(amt);
            to.deposit(amt);
        }
    }
}
// Thread A: transfer(x, y, 100)      Thread B: transfer(y, x, 50)

রহিম করিমকে টাকা পাঠাচ্ছেন, আর ঠিক একই মুহূর্তে করিম রহিমকে। দেখুন কী ঘটে:

1synchronized (from) {          // প্রথম তালা2    synchronized (to) {        // দ্বিতীয় তালা3        from.withdraw(amt); to.deposit(amt);4// সমাধান: সবসময় ছোট id-র হিসাব আগে

কোডে সমাধান:

void transfer(Account from, Account to, long amt) {
    Account first  = from.id() < to.id() ? from : to;   // সবসময় ছোট id আগে
    Account second = from.id() < to.id() ? to : from;
    synchronized (first) {
        synchronized (second) {
            from.withdraw(amt);
            to.deposit(amt);
        }
    }
}

আরেকটি কৌশল: অংশ ৬-এর tryLock(সময়সীমা) — দ্বিতীয় তালা নির্দিষ্ট সময়ে না পেলে প্রথমটিও ছেড়ে দিন, একটু অপেক্ষা করে আবার চেষ্টা করুন। আর deadlock হয়ে গেলে খোঁজার উপায়: JDK-র jstack <pid> কমান্ড সব thread-এর অবস্থা ছাপে, আর deadlock পেলে নিচে স্পষ্ট লেখে “Found one Java-level deadlock”, কোন thread কোন তালা ধরে কোনটার অপেক্ষায় — সবসহ। আর তালা ধরে থাকা অবস্থায় অজানা কোড (callback, নেটওয়ার্ক কল) ডাকবেন না — সেটা ভেতরে কোন তালা চাইবে, আপনি জানেন না।

wait/notify — পুরোনো যন্ত্র, আধুনিক বিকল্প

কখনো একটি thread-কে অন্যের সংকেতের অপেক্ষা করতে হয়: “সারিতে কাজ এলে জাগাও”। Java 1.0 থেকে প্রতিটি object-এ এর জন্য wait() আর notify() আছে। wait() তালা ছেড়ে ঘুমায়, notifyAll() অপেক্ষারতদের জাগায়। নিয়মগুলো কঠিন: এদের ডাকতে হয় সেই object-এর তালা ধরে থাকা অবস্থায়, নইলে —

Exception in thread "main" java.lang.IllegalMonitorStateException: current thread is not owner
	at java.base/java.lang.Object.wait0(Native Method)
	at java.base/java.lang.Object.wait(Object.java:366)
	at java.base/java.lang.Object.wait(Object.java:339)
	at Main.main(Main.java:4)

আর শর্ত যাচাই করতে হয় if দিয়ে নয়, while দিয়ে — কারণ thread কোনো কারণ ছাড়াই জেগে উঠতে পারে (spurious wakeup), বা জাগার পর অন্য কেউ আগে জিনিসটা নিয়ে যেতে পারে:

synchronized (queue) {
    while (queue.isEmpty()) queue.wait();     // পুরোনো ধাঁচ: if নয়, while
    order = queue.remove();
}
// আধুনিক বিকল্প — একই কাজ, এক লাইনে, ভুলের সুযোগ নেই:
order = blockingQueue.take();

আজকের কোডে wait/notify নিজে লেখার দরকার প্রায় পড়ে না। পর্ব ৩২-এ দেখা BlockingQueue producer-consumer-এর পুরো ব্যবস্থা তৈরি দেয়, আর “তিনটি কাজ শেষ হলে এগোও” ধরনের অপেক্ষার জন্য আছে CountDownLatch — এগুলো আর executor পর্ব ৪১-এ। wait/notify চিনে রাখুন পুরোনো কোড পড়তে আর ইন্টারভিউর জন্য।

৮ · thread-safe collection আর immutability

পর্ব ৩০–৩১-এর ArrayList আর HashMap thread-safe নয়। একাধিক thread একসাথে put বা add করলে উপাদান হারাতে পারে, আকার ভুল হতে পারে, এমনকি ভেতরের কাঠামো নষ্ট হয়ে exception আসতে পারে। নিজে প্রতিটি কাজে তালা না বসিয়ে তৈরি সমাধান ব্যবহার করুন:

এবার সব মিলিয়ে একটি শব্দ-গণনা: একটি বইয়ের চারটি পাতা চারটি thread-এ ভাগ করে দেওয়া হলো; প্রতিটি thread নিজের পাতার শব্দ একটি ভাগাভাগি করা ConcurrentHashMap-এ গোনে, আর একটি AtomicInteger গোনে কয়টি পাতা শেষ:

import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
class Main {
    public static void main(String[] args) throws InterruptedException {
        List<String> pages = List.of("আমি ভাত খাই", "আমি চা খাই", "সে চা খায়", "আমি বই পড়ি");
        Map<String, Integer> freq = new ConcurrentHashMap<>();
        AtomicInteger done = new AtomicInteger();          // কয়টি পাতা শেষ
        List<Thread> workers = new ArrayList<>();
        for (String page : pages) {
            Thread t = new Thread(() -> {
                for (String w : page.split(" ")) freq.merge(w, 1, Integer::sum);
                done.incrementAndGet();
            });
            workers.add(t);
            t.start();
        }
        for (Thread t : workers) t.join();                 // সবার শেষ হওয়ার অপেক্ষা
        System.out.println("শেষ হয়েছে: " + done.get() + "/" + pages.size() + " পাতা");
        System.out.println("শব্দ গণনা: " + new TreeMap<>(freq));
    }
}

সবচেয়ে সহজ thread safety — কিছু বদলাতেই না দেওয়া

Race-এর তিনটি শর্ত: ডেটা ভাগাভাগি করা, ডেটা বদলানো যায়, আর সমন্বয় নেই। যেকোনো একটি সরালেই সমস্যা শেষ। তালা তৃতীয়টি সারায়; কিন্তু দ্বিতীয়টি সরানো আরও সহজ — immutable object কখনো বদলায় না, তাই একে যত thread খুশি একসাথে পড়ুক, কোনো তালা লাগে না। পর্ব ০৮-এর String, পর্ব ২৫-এর record (যদি তার field-গুলো নিজেও immutable হয়), List.of, LocalDate — সবই এমন। পর্ব ১৮-এ দেখা final field-এর একটি বাড়তি নিশ্চয়তা JMM দেয়: constructor শেষ হওয়ার পর যে thread-ই object-টি পায়, সে final field-গুলোর সঠিক মান দেখবে।

নকশার কৌশল: অবস্থা বদলাতে হলে পুরোনো object বদলাবেন না, নতুন একটি বানান, আর একটি volatile reference (বা AtomicReference) দিয়ে নতুনটির দিকে ঘুরিয়ে দিন। যেমন একটি অ্যাপের কনফিগ: private volatile Config current; — reload হলে current = new Config(...). পাঠক thread-রা হয় পুরো পুরোনোটা দেখে, নয় পুরো নতুনটা, কখনো অর্ধেক-বদলানো নয়। আর পর্ব ১৮-এ যে global state নিয়ে সতর্ক করা হয়েছিল, thread-এর জগতে সেটাই বিপদের প্রধান উৎস — বদলানো যায় এমন static field মানে সব thread-এর ভাগাভাগি করা ক্যাশবাক্স।

৯ · AI-এর যুগে — যে bug টেস্টে ধরা পড়ে না

Concurrency-র bug AI-এর জন্য সবচেয়ে কঠিন জায়গাগুলোর একটি — আর আপনার জন্যও, কারণ AI-এর কোড চালিয়ে দেখলে প্রায় সবসময় ঠিক ফল আসে। AI-এর লেখা Java concurrency কোডে বারবার যা দেখা যায়:

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

• প্রতিটি thread চালু হচ্ছে start() দিয়ে; কোথাও ভুল করে run() নেই
• প্রতিটি ভাগাভাগি করা, বদলানো যায় এমন field চিহ্নিত করেছি, আর প্রত্যেকটি একটি নির্দিষ্ট তালা, atomic বা thread-safe collection-এ সুরক্ষিত
• সব synchronized একই ডেটার জন্য একই object-এ; তালার field private final
• কোনো check-then-act (if (containsKey) put, if (seats > 0) seats--) তালার বাইরে নেই
• stop flag volatile; counter atomic, শুধু volatile নয়
• nested তালা থাকলে সব জায়গায় একই ক্রম; তালা ধরে কোনো অজানা method বা নেটওয়ার্ক কল নেই
• ReentrantLock-এর unlock() সবসময় finally-তে; InterruptedException গিলে ফেলা হয়নি