JVM মেমরি আর garbage collection — heap, GC root, G1, ZGC ও memory leak

১ · new আছে, free নেই — তাহলে মেমরি ফেরত দেয় কে?

পর্ব ০৫-এ আপনি একটি মানসিক ছবি পেয়েছিলেন: local ভ্যারিয়েবল থাকে stack-এ, new দিয়ে তৈরি object থাকে heap-এ, আর কোনো reference দিয়ে পৌঁছানো যায় না এমন object একসময় মুছে যায়। এই পর্বে সেই “একসময়” আর “মুছে যায়”-এর ভেতরে ঢুকব।

প্রশ্নটা সহজ শোনায়, কিন্তু উত্তর গভীর। একটি অনলাইন শপের সার্ভার দিনে কয়েক কোটি object তৈরি করতে পারে — প্রতিটি অনুরোধে request object, JSON-এর String, অস্থায়ী list. প্রোগ্রামার একটিও মোছেন না, তবু মেমরি ফুরোয় না — JVM-এর ভেতরে একটি পরিচ্ছন্নতা-কর্মী অবিরাম কাজ করে। তাকে বুঝলে তিনটি বাস্তব সমস্যা সামলাতে পারবেন: memory leak, OutOfMemoryError, আর হঠাৎ লম্বা pause.

২ · JVM-এর মেমরির মানচিত্র — runtime data area

একটি Java প্রোগ্রাম চালালে অপারেটিং সিস্টেম দেখে একটিমাত্র process. কিন্তু সেই process-এর ভেতরে JVM মেমরিকে কয়েকটি আলাদা কাজে ভাগ করে নেয়। কোনটি কোথায়, জানা থাকলে কোনো error দেখেই বুঝবেন কোন ঘর ভরেছে।

পর্ব ১৮-এ বলা হয়েছিল, static field “class-এর সাথে একটিই কপি”। ভেতরের সত্যটা এই: class-এর কাঠামো (কোন কোন field, কোন method) থাকে metaspace-এ, কিন্তু static field-এর মান JDK 7 থেকে থাকে heap-এ। তাই একটি static list-এ ঢোকানো object সাধারণ heap object — আর সেই list একটি GC root থেকে পৌঁছানো যায়, যতদিন class লোড করা আছে। Leak-এর আলোচনায় এই তথ্যটি ফিরে আসবে।

৩ · একটি object আসলে কত বড়?

“একটি Integer কত বাইট?” — int ৪ বাইট, তাই অনেকে বলেন ৪. আসলে সাধারণ ৬৪-bit HotSpot-এ এটি প্রায় ১৬ বাইট। বাকি ১২ বাইট কোথায় যায়? প্রতিটি heap object-এর তিনটি অংশ থাকে:

“সাধারণত ৪ বাইটের reference” এসেছে compressed oops থেকে: heap ৩২ GB-এর কম হলে HotSpot ৬৪-bit ঠিকানাকে ৩২ bit-এ চেপে রাখে, যা ডিফল্টভাবে চালু থাকে। নিচের হিসাবগুলো এই সাধারণ অবস্থার জন্য; JVM, version আর flag বদলালে সংখ্যা বদলায়।

শেষ দুই সারি তুলনা করুন — একই ১,০০০টি সংখ্যা, প্রায় পাঁচ গুণ মেমরি। আর শুধু আকার নয়: int[]-এর সংখ্যাগুলো পাশাপাশি থাকে, CPU এক টানে cache-এ তোলে। Integer[]-এ থাকে শুধু reference, আসল object ছড়িয়ে থাকে heap-এর নানা জায়গায় — প্রতিটি পড়তে আলাদা লাফ। List<Integer>-এ দশ লাখ সংখ্যা রাখা তাই int[]-এর চেয়ে অনেক ভারী, আর GC-কে দশ লাখ বাড়তি object গুনতে হয়। পর্ব ০৬-এর autoboxing নিঃশব্দে এই খরচ তৈরি করে (−১২৮ থেকে ১২৭-এর Integer cache ছাড়া)। এজন্যই Stream API-তে IntStream আছে, আর OpenJDK-র Project Valhalla header-হীন “value” object আনার চেষ্টা করছে।

যে object heap-এ যায়ই না — escape analysis

JIT-এর C2 compiler (পর্ব ০৫) একটি বিশ্লেষণ করে, যার নাম escape analysis: method-এর ভেতরে তৈরি object কি বাইরে “পালায়” — field-এ রাখা হয়, ফেরত দেওয়া হয়, অন্য method-এ যায়? না পালালে C2 object বানানোই বাদ দিতে পারে, তার field-গুলোকে সাধারণ local মানের মতো register-এ রেখে — scalar replacement. ফলে লুপের ভেতরের new Point(x, y) গরম কোডে হয়তো একটিও heap allocation করে না। এটি JIT-এর সিদ্ধান্ত, নিশ্চয়তা নয় — তবে এজন্যই “ছোট object এড়াতে কোড জটিল করুন” পরামর্শ আধুনিক Java-তে প্রায়ই অপ্রয়োজনীয়।

৪ · কে জীবিত? — GC root থেকে mark

প্রতিটি tracing collector-এর প্রথম কাজ একই: জীবিত object খুঁজে চিহ্ন দেওয়া। শুরু হয় GC root থেকে — যেসব reference নিশ্চিতভাবে প্রোগ্রামের হাতে আছে:

• চলমান প্রতিটি thread-এর stack-এর local ভ্যারিয়েবল আর parameter — এই মুহূর্তে চলা প্রতিটি method যা ধরে আছে।
• লোড করা class-এর static field — class বেঁচে থাকলে তারাও।
• জীবিত thread object নিজেই, আর synchronized দিয়ে lock করা object.
• JNI reference — native (C/C++) কোড যে Java object ধরে রেখেছে, আর JVM-এর নিজের কিছু ভেতরের reference.

এই root থেকে reference ধরে ধরে যতদূর যাওয়া যায়, সবাই reachable. বাকিরা garbage — একে অপরকে দেখালেও। নিচের stepper-এ একটি ছোট heap-এ mark phase চালিয়ে দেখুন। লাল বর্ডার মানে “চিহ্নিত, জীবিত”:

জায়গা ফেরত নেওয়ার তিন কৌশল

Copying-এর একটি চমৎকার পার্শ্বফল আছে: কপির পর খালি জায়গা একটানা। তাই নতুন object দিতে JVM-কে শুধু একটি pointer সামনে ঠেলতে হয় — “bump the pointer”. আরও দ্রুত করতে প্রতিটি thread পায় eden-এর একটি নিজস্ব টুকরো, যার নাম TLAB (thread-local allocation buffer); সেখানে lock ছাড়াই object তৈরি হয়। এজন্য Java-তে new সাধারণত C-র malloc-এর চেয়েও সস্তা। দামটা দিতে হয় পরে, GC-র সময়।

৫ · বেশিরভাগ object অল্প বয়সে মরে — generational GC

Copying সস্তা যখন জীবিত কম। আর বাস্তব প্রোগ্রামে ঠিক তাই ঘটে। একটি HTTP অনুরোধের জন্য তৈরি String, list, DTO — অনুরোধ শেষ হতেই সব garbage. অন্যদিকে cache, connection pool, Spring-এর bean বেঁচে থাকে ঘণ্টার পর ঘণ্টা। এই পর্যবেক্ষণের নাম generational hypothesis: বেশিরভাগ object খুব অল্প বয়সেই মারা যায়; যারা বেঁচে যায়, তারা প্রায়ই অনেকদিন বাঁচে।

তাই HotSpot heap-কে দুই প্রজন্মে ভাগ করে। Young অংশে আবার তিনটি ঘর: eden (যেখানে নতুন object জন্মায়) আর দুটি ছোট survivor space, S0 ও S1. Young অংশ ঘন ঘন, দ্রুত পরিষ্কার হয় copying দিয়ে — একে বলে minor GC. Old অংশ পরিষ্কার হয় কদাচিৎ। প্রতিবার বেঁচে গেলে object-এর বয়স এক বাড়ে (mark word-এ লেখা থাকে); বয়স একটি সীমা পেরোলে সে old অংশে উঠে যায় — promotion. ধাপে ধাপে দেখুন:

একটি সূক্ষ্ম প্রশ্ন: minor GC শুধু young অংশ দেখে, কিন্তু কোনো old object যদি একটি young object দেখায়? সেজন্য JVM old থেকে young-এ যাওয়া reference-এর হিসাব রাখে (card table, G1-এ remembered set) — প্রতিটি reference লেখার সময় একটি ছোট “write barrier” কোড চলে। এটাই generational GC-র লুকানো খরচ।

Stop-the-world — কেন সব thread থামাতে হয়

GC যখন object সরায়, প্রোগ্রামের thread যদি একই সময়ে পুরোনো ঠিকানায় লেখে — বিপর্যয়। সবচেয়ে সহজ সমাধান: সব Java thread একটি নিরাপদ বিন্দুতে (safepoint) থামিয়ে কাজ সেরে নেওয়া। এই বিরতিই stop-the-world pause. Young অংশ ছোট হলে minor GC-র pause সাধারণত কয়েক মিলিসেকেন্ড। কিন্তু কয়েক GB-এর old অংশ থামিয়ে compact করলে pause এক সেকেন্ড ছাড়াতে পারে। আধুনিক collector-গুলোর পুরো গল্প হলো এই কাজের যতটা সম্ভব প্রোগ্রামের পাশাপাশি (concurrent) করে ফেলা।

৬ · HotSpot-এর collector-গুলো — কোনটি কখন

প্রতিটি collector তিনটি জিনিসের মধ্যে একটি ভারসাম্য বেছে নেয়: throughput (মোট CPU সময়ের কত ভাগ আপনার কাজে গেল), latency (একটি pause সর্বোচ্চ কত লম্বা), আর footprint (কত বাড়তি মেমরি লাগে)। তিনটিই একসাথে সেরা পাওয়া যায় না।

কয়েকটি তথ্য সাবধানে মনে রাখুন। G1 Java 9 থেকে ডিফল্ট (JEP 248) — তবে JVM যদি দেখে মেশিনটি খুব ছোট (যেমন ১টি মাত্র CPU, বা প্রায় ১.৭৫ GB-এর কম মেমরি), তাহলে নিজে থেকে Serial বেছে নেয়; ছোট container-এ এটা প্রায়ই ঘটে। ZGC Java 11-এ পরীক্ষামূলক হিসেবে আসে, Java 15-এ production-এ ব্যবহারের উপযোগী ঘোষিত হয় (JEP 377). Java 21-এ generational ZGC এসেছে (JEP 439), কিন্তু Java 21-এ সেটি চালু করতে দুটি flag লাগে: -XX:+UseZGC -XX:+ZGenerational. Java 23-এ generational মোডই ডিফল্ট হয় (JEP 474), আর Java 24-এ পুরোনো non-generational মোড সরিয়ে দেওয়া হয় (JEP 490) — তখন -XX:+ZGenerational flag-টিরও আর দরকার নেই। Shenandoah Red Hat-এর তৈরি, Java 15-এ production-ready (JEP 379); বেশিরভাগ OpenJDK build-এ (যেমন Temurin, Corretto) থাকে, কিন্তু Oracle-এর নিজস্ব JDK build-এ রাখা হয়নি।

G1 ভেতরে — অঞ্চল আর “আগে garbage”

G1 heap-কে একটানা young আর old-এ ভাগ করে না। পুরো heap সমান আকারের অনেক region-এ ভাগ করা (heap-এর আকার অনুযায়ী সাধারণত ১ থেকে ৩২ MB), আর প্রতিটি region যেকোনো সময় eden, survivor বা old-এর ভূমিকা নিতে পারে। অর্ধেক region-এর চেয়ে বড় object (যেমন বিশাল array) পায় এক বা একাধিক একটানা “humongous” region. নিচের নকশায় E = eden, S = survivor, O = old, H = humongous, · = খালি:

বাস্তব সিদ্ধান্ত — একটি payment API-র জন্য G1 না ZGC?

ধরুন আপনার দল একটি payment API চালায়: মোবাইল ওয়ালেট থেকে টাকা পাঠানোর অনুরোধ আসে, চুক্তি অনুযায়ী ৯৯% উত্তর ১০০ ms-এর মধ্যে দিতে হবে (p99 latency). Heap ৮ GB. কেউ বলল, “ZGC দিলেই pause শেষ।” সিদ্ধান্তের পথটা এমন হওয়া উচিত:

1. আগে মাপুন: ডিফল্ট G1-এ বাস্তবের মতো লোড দিয়ে -Xlog:gc চালান। সবচেয়ে লম্বা pause ৩০ ms আর বাজেট ১০০ ms হলে G1-ই যথেষ্ট।
2. দোষী GC কি না মেলান: ধীর অনুরোধের সময়ের সাথে GC pause-এর সময় মেলান — কারণটা ডেটাবেস বা অন্য সার্ভিসও হতে পারে।
3. দরকার হলে ZGC পরীক্ষা: একই লোডে -XX:+UseZGC -XX:+ZGenerational (Java 21) চালান; pause প্রায় মুছে যাবে, তবে CPU আর মেমরি একটু বাড়তে পারে।
4. কারণসহ লিখে রাখুন কোন flag, কোন পরিমাপের ভিত্তিতে — যাতে ছয় মাস পরে কেউ “এই flag কেন?” প্রশ্নের উত্তর পায়।

প্রাথমিক flag আর GC log

# heap-এর শুরু ও সর্বোচ্চ আকার (সার্ভারে প্রায়ই দুটো সমান রাখা হয়)
java -Xms2g -Xmx2g -jar shop.jar

# container-এ: নির্দিষ্ট সংখ্যার বদলে container-এর মেমরির শতাংশ
java -XX:MaxRAMPercentage=75 -jar shop.jar

# collector বাছাই আর G1-এর pause লক্ষ্য
java -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -jar shop.jar
java -XX:+UseZGC -XX:+ZGenerational -jar shop.jar      # Java 21

# GC log (unified logging, Java 9 থেকে) — ফাইলে
java -Xlog:gc*:file=gc.log -jar shop.jar

# OutOfMemoryError হলে স্বয়ংক্রিয় heap dump
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/dumps -jar shop.jar

ফ্ল্যাগ না দিলে JVM নিজেই হিসাব করে: সর্বোচ্চ heap সাধারণত মেশিনের (বা container-এর) মেমরির এক-চতুর্থাংশ। Container awareness JDK 10 থেকে ডিফল্টভাবে চালু (পরে Java 8u191-এও আনা হয়েছে) — অর্থাৎ JVM Docker বা Kubernetes-এর CPU ও মেমরি সীমা পড়ে, পুরো host মেশিনের নয়। আগের JVM পুরো host-এর মেমরি দেখে বিশাল heap ঠিক করত, আর ছোট container-এ OS তাকে মেরে ফেলত।

-Xlog:gc হলো Java 9-এ আসা unified logging-এর অংশ, যা পুরোনো -XX:+PrintGCDetails ধরনের flag-এর জায়গা নিয়েছে। একটি ছোট প্রোগ্রাম -Xmx64m -Xlog:gc দিয়ে চালালে এমন লাইন আসে:

একটি নমুনা — সংখ্যা আপনার মেশিনে আলাদা হবে

[0.008s][info][gc] Using G1
[0.069s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 7M->1M(34M) 2.720ms
[0.084s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 18M->2M(34M) 1.425ms
[0.091s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 19M->2M(34M) 1.900ms
[0.097s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) 19M->3M(34M) 2.994ms
[0.104s][info][gc] GC(4) Pause Young (Normal) (G1 Evacuation Pause) 20M->4M(34M) 1.801ms
[0.111s][info][gc] GC(5) Pause Young (Normal) (G1 Evacuation Pause) 21M->5M(43M) 2.019ms

পড়তে শিখুন: বন্ধনীর প্রথম অংশ JVM চালুর পর কত সেকেন্ড; GC(0) হলো প্রথম GC; Pause Young (Normal) মানে young GC; (G1 Evacuation Pause) কারণ — eden ভরেছে; তীরচিহ্নের দুই পাশে GC-র আগে আর পরে heap-এ ব্যবহৃত মেমরি, বন্ধনীতে মোট heap; শেষে pause কত মিলিসেকেন্ড। খেয়াল করুন, GC-র পরের সংখ্যাটি ১M থেকে ৫M-এ উঠছে — কারণ এই নমুনা-প্রোগ্রাম ইচ্ছা করে কিছু array একটি list-এ রেখে দেয়। বাস্তব অ্যাপে GC-র পরের সংখ্যা যদি ঘণ্টার পর ঘণ্টা এভাবে বাড়তেই থাকে, কখনো আগের জায়গায় না ফেরে — সেটি leak-এর প্রথম লক্ষণ। আর heap-এর মোট আকার (৩৪M থেকে ৪৩M) বদলেছে, কারণ -Xms আর -Xmx সমান না দিলে JVM প্রয়োজন মতো heap বাড়ায়।

৭ · OutOfMemoryError আর StackOverflowError — কোন ঘর ভরেছে?

OutOfMemoryError একটি Error, Exception নয় (পর্ব ২৯) — সাধারণ কোডে এটি ধরে চালিয়ে যাওয়ার চেষ্টা করা উচিত নয়, কারণ তখন JVM-এর অবস্থা অনিশ্চিত। কিন্তু বার্তার শেষ অংশটি খুব কাজের: কোন ঘর ভরেছে, তা বলে দেয়।

নিচে একটি আসল trace. প্রোগ্রামটির loadAllImages() method একটি list-এ একের পর এক ১ MB-র byte[] রাখে, কখনো থামে না — যেন “সব ছবি একবারে মেমরিতে লোড করো” ধরনের বাগ। চালানো হয়েছে -Xmx32m দিয়ে, অনলাইন রানারে, যেখানে ফাইলের নাম prog.java:

একটি নমুনা — সংখ্যা আপনার মেশিনে আলাদা হবে

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at Main.loadAllImages(prog.java:6)
	at Main.main(prog.java:9)

Trace-এর শেষ লাইনটি দেখায় কোথায় শেষ allocation ব্যর্থ হলো — কিন্তু সেটি দোষী না-ও হতে পারে! যে লাইন শেষ খড়টি রাখল, উট তার জন্য ভাঙেনি; ভেঙেছে আগের হাজার খড়ে। আসল দোষী খুঁজতে দেখতে হয় heap-এ কী জমেছে — সেজন্য heap dump (অংশ ৯)।

Stack ভরলে — StackOverflowError

প্রতিটি thread-এর stack-এর আকার নির্দিষ্ট (-Xss, ৬৪-bit Linux-এ ডিফল্ট সাধারণত ১ MB). প্রতিটি method কল একটি frame যোগ করে; শেষ না হওয়া বা খুব গভীর recursion stack ভরিয়ে দেয়, আর আসে StackOverflowError. কত গভীরে গিয়ে ভরবে, তা frame-এর আকার, JIT আর -Xss-এর ওপর নির্ভর করে — তাই নিচের কোড গভীরতার সংখ্যা ছাপে না, শুধু নিশ্চিত তথ্যগুলো ছাপে:

class Main {
    static int depth = 0;
    static long sumTo(long n) {                 // প্রতিটি কলে stack-এ নতুন frame
        depth++;
        return n == 0 ? 0 : n + sumTo(n - 1);
    }
    static long sumLoop(long n) {               // একটিই frame, যত বড় n হোক
        long s = 0;
        for (long i = 1; i <= n; i++) s += i;
        return s;
    }
    public static void main(String[] args) {
        System.out.println("sumTo(1000) = " + sumTo(1_000));
        depth = 0;
        try {
            sumTo(10_000_000);
            System.out.println("শেষ হয়েছে");
        } catch (StackOverflowError e) {
            System.out.println("ধরা পড়ল: " + e.getClass().getName());
            System.out.println("১ কোটি frame-এর আগেই থেমেছে? " + (depth < 10_000_000));
        }
        System.out.println("লুপ দিয়ে sum(1..1 কোটি) = " + sumLoop(10_000_000));
    }
}

৮ · GC থাকলেও memory leak — চেনা পাঁচটি রূপ

C-তে leak মানে free ভুলে যাওয়া। Java-তে leak মানে reference ভুলে যাওয়া: object আর দরকার নেই, কিন্তু কোনো GC root থেকে এখনো পৌঁছানো যায়। GC নিয়ম মেনেই তাকে রেখে দেয়। একটি বাস্তব গল্প দিয়ে দেখি — একটি ই-কমার্স সার্ভার, যার মেমরি প্রতিদিন একটু একটু বাড়ে, আর প্রতি সপ্তাহে একবার রিস্টার্ট লাগে:

1static Map<String, Session> SESSIONS = new HashMap<>();2void login(User u)  { SESSIONS.put(newId(), new Session(u)); }3void logout(String id) { /* remove করতে ভুলে গেছি */ }4// ... এক সপ্তাহ: ১০ লাখ login, ১০ লাখ logout5// minor GC, mixed GC ... চলছে6SESSIONS.remove(id);  // + মেয়াদ ও সীমা

পাঁচটি চেনা রূপ

1. বাড়তেই থাকা static collection — উপরের session map, বা “পরে কাজে লাগবে” ভেবে সব ইভেন্ট জমানো একটি static List.
2. সরানো হয়নি এমন listener — একটি দীর্ঘজীবী object-এ (যেমন একটি event bus) listener নিবন্ধন করলেন, কিন্তু কাজ শেষে সরালেন না। Event bus listener-কে ধরে রাখে, আর listener ধরে রাখে তার পুরো object.
3. Eviction ছাড়া cache — HashMap-কে cache বানালে সেটি শুধু বাড়ে। সমাধান সীমা (পর্ব ৩১-এর LRU cache) বা মেয়াদ।
4. Thread pool-এ ThreadLocal — প্রতিটি thread-এর নিজস্ব একটি মান রাখার ব্যবস্থা। Thread pool-এর thread কখনো মরে না (পর্ব ৪১), তাই remove() না করলে মান থেকে যায় — আর পরের অনুরোধে অন্য ব্যবহারকারীর ডেটা ফাঁসও হতে পারে। finally-তে remove() ডাকুন।
5. Inner class-এর লুকানো reference — পর্ব ২৭-এ দেখেছেন, non-static inner class বা anonymous class-এর object বাইরের object-এর একটি লুকানো reference (enclosing instance) রাখে। একটি ছোট callback দীর্ঘদিন বেঁচে থাকলে পুরো বড় বাইরের object-ও বাঁচে। দরকার না হলে static nested class ব্যবহার করুন।

এবার থাম্বনেইল cache-এর একটি ছোট মডেল চালিয়ে দেখুন। একটি অনলাইন শপে এক লাখ আলাদা পণ্যের ছবি চাওয়া হলো। একটি cache সীমাহীন HashMap, অন্যটি LinkedHashMap দিয়ে ১০০টির সীমা দেওয়া LRU. মেমরির সংখ্যা নয় — শুধু entry গোনা হচ্ছে, যা সবসময় একই আসে:

import java.util.*;
class Main {
    // ভুল: কখনো কিছু সরায় না — প্রতিটি thumbnail চিরকাল থেকে যায়
    static final Map<Integer, String> leaky = new HashMap<>();
    // ঠিক: সর্বোচ্চ ১০০টি, সবচেয়ে পুরোনো ব্যবহারেরটি বাদ (LRU)
    static final Map<Integer, String> lru = new LinkedHashMap<>(16, 0.75f, true) {
        @Override
        protected boolean removeEldestEntry(Map.Entry<Integer, String> eldest) {
            return size() > 100;
        }
    };
    public static void main(String[] args) {
        for (int id = 1; id <= 100_000; id++) {      // ১ লাখ আলাদা পণ্যের ছবি চাওয়া হলো
            String thumb = "thumb-" + id;
            leaky.put(id, thumb);
            lru.put(id, thumb);
            if (id == 1_000 || id == 10_000 || id == 100_000)
                System.out.println(id + " অনুরোধ পর: leaky=" + leaky.size() + ", lru=" + lru.size());
        }
        System.out.println("lru-তে সাম্প্রতিক 99999? " + lru.containsKey(99_999));
        System.out.println("lru-তে পুরোনো 5? " + lru.containsKey(5));
    }
}

চার রকম reference — strong, soft, weak, phantom

সাধারণ ভ্যারিয়েবল একটি strong reference: যতক্ষণ আছে, object বাঁচবে। java.lang.ref প্যাকেজ আরও তিন রকম দুর্বল reference দেয়, যা GC-কে বলে “এই object-এর জন্য আমাকে গোনার দরকার নেই”:

WeakHashMap-এর key-র বাইরের সব strong reference হারালে entry একসময় নিজে থেকে মুছে যায়। কিন্তু “একসময়” মানে GC যখন চালাবে — তাই এই পাতায় এর চালানো উদাহরণ নেই, আউটপুট প্রতিবার আলাদা হতে পারত। String literal বা ছোট Integer-কে key বানালে সেগুলো pool/cache থেকে strong-ভাবে ধরা থাকে, entry কখনো মোছে না। বেশিরভাগ cache-এর জন্য স্পষ্ট সীমা বা মেয়াদ বেশি নির্ভরযোগ্য।

৯ · অনুমান নয়, মাপুন — jcmd, jstat, heap dump, JFR

মেমরির সমস্যায় সবচেয়ে বড় ভুল হলো না মেপে flag বদলানো। JDK-র সাথেই চমৎকার টুল আসে; চলমান JVM-এর process id (pid) দিয়ে এগুলো চালানো যায়, অ্যাপ বন্ধ না করেই:

# চলমান সব JVM আর তাদের pid
jcmd

# heap-এর এখনকার অবস্থা, আর কোন class-এর কতগুলো object
jcmd 4321 GC.heap_info
jcmd 4321 GC.class_histogram

# প্রতি ১ সেকেন্ডে eden / survivor / old কত ভরা, কতবার GC
jstat -gcutil 4321 1000

# পুরো heap-এর ছবি ফাইলে (heap dump) — বড় heap-এ সময় নেয়, pause হয়
jcmd 4321 GC.heap_dump /tmp/shop.hprof

# Java Flight Recorder: ৬০ সেকেন্ডের রেকর্ডিং, খুব কম খরচে
jcmd 4321 JFR.start duration=60s filename=/tmp/shop.jfr

Leak খোঁজার পরীক্ষিত পদ্ধতি: কিছুক্ষণ ব্যবধানে দুটি heap dump বা class histogram নিন, তুলনা করুন কোন class-এর object সংখ্যা শুধু বাড়ছে। তারপর MAT-এ সেই object-এর “path to GC roots” দেখুন — উপরের উদাহরণে পথটি সরাসরি দেখাবে SESSIONS নামের static field. JFR আগে আলাদা বাণিজ্যিক বৈশিষ্ট্য ছিল; JDK 11-এ OpenJDK-তে উন্মুক্ত হয়েছে (JEP 328), আর এর খরচ এত কম যে অনেক দল production-এ সবসময় চালু রাখে।

১০ · AI-এর যুগে — JVM flag আর “GC-র দোষ” যাচাই

মেমরি বা গতির সমস্যায় AI-কে জিজ্ঞেস করলে সে প্রায়ই একগাদা JVM flag দেয় — দেখতে পেশাদার, কিন্তু অনেকগুলো পুরোনো, কিছু পরস্পরবিরোধী, আর প্রায় কোনোটাই আপনার অ্যাপ মেপে দেওয়া নয়। AI আপনার GC log দেখেনি; সে দেখেছে ইন্টারনেটের হাজারো পুরোনো টিউনিং ব্লগ।

AI-এর মেমরি-পরামর্শ হাতে পেলে — চেকলিস্ট

• প্রতিটি flag আমার JDK-তে আছে কি না দেখেছি (java -XX:+PrintFlagsFinal -version), আর সেটি কী করে জেনেছি
• কোডে System.gc(), finalize() বা সীমাহীন static collection আছে কি না খুঁজেছি
• প্রতিটি cache-এর সর্বোচ্চ আকার বা মেয়াদ আছে কি না যাচাই করেছি
• ThreadLocal ব্যবহার হলে finally-তে remove() আছে কি না দেখেছি
• পরিবর্তনের আগে ও পরে GC log বা JFR দিয়ে একই লোডে মেপে তুলনা করেছি