Himanshu Mandal’s Post

Learn what Java variables are, how to declare and use them, and understand types, scope, and best practices with clear code examples

⚠️ Why Java Killed PermGen (And What Replaced It) Before Java 8, JVM had PermGen (Permanent Generation) A special memory region inside the heap used for: Class metadata Method metadata String intern pool (pre-Java 7) Static variables The Problem was with PermGen as it had a fixed size: -XX:MaxPermSize=256m Sounds fine until: Applications dynamically load classes Frameworks create proxies (Spring, Hibernate) ClassLoaders don’t get garbage collected 👉 Boom: OutOfMemoryError: PermGen space Very common in: App servers Long-running systems Hot-deploy environments 🧠 Enter Metaspace (Java 8+) PermGen was removed and replaced with Metaspace Key change: Moved class metadata OUT of heap → into native memory ⚡ What Changed? Memory Location Native memory Size Dynamic (auto grows) Tuning Minimal OOM Errors Frequent Much rarer 🧠 Why This Was a Big Deal Metaspace: Grows dynamically (no fixed ceiling by default) Reduces OOM crashes Simplifies JVM tuning Handles dynamic class loading better But It’s Not “Unlimited" If not controlled It can still cause: OutOfMemoryError: Metaspace So you can still set limits: -XX:MaxMetaspaceSize=512m 🧠 What Actually Lives in Metaspace? Class metadata Method metadata Runtime constant pool NOT: Objects (Heap) Stack frames (Stack) PermGen failed because it was fixed. Metaspace works because it adapts. #Java #JVM #MemoryManagement #Metaspace #PerformanceEngineering #BackendDevelopment #JavaInternals #LearnInPublic

🧠 Soft vs Weak vs Strong References in Java (and why it matters) Most Java developers don’t think about how the GC sees objects. But reference types directly affect memory behavior and performance. Let’s break it down 👇 ⸻ 🔗 Strong Reference (default) Objects are not garbage collected as long as a strong reference exists. 💡 Risk: Unnecessary references (e.g., in static collections) → memory leaks. ⸻ 🟡 Soft Reference Objects are collected only when JVM needs memory. 💡 Use cases: • caches • memory-sensitive data 📌 JVM tries to keep them as long as possible. ⸻ ⚪ Weak Reference Objects are collected as soon as they become weakly reachable. 💡 Use cases: • auto-cleanup structures • WeakHashMap • listeners / metadata ⸻ 🔥 Key difference • Strong → lives as long as referenced • Soft → removed under memory pressure • Weak → removed on next GC ⸻ ⚠️ Common mistake Using strong references for caches → memory leaks. ⸻ 💡 Key insight Reference types are about controlling memory behavior, not syntax. If you understand them, you can: ✔ avoid leaks ✔ build smarter caches ✔ reduce GC pressure ⸻ Have you ever debugged a memory issue caused by wrong reference types? 🤔 #Java #JVM #GarbageCollection #Backend #Performance

Topic of the day Java Memory Management? 💡 Java Memory Management Understanding JVM memory becomes easy when you connect it with real code 🔹 1. Heap Memory (Objects Storage) This is where all objects are created and stored. 👉 Example: Student s = new Student(); ✔ new Student() → object is created in Heap ✔ s (reference) → stored in Stack 📌 Real-time: Like storing data in a database, Heap holds actual objects. 🔹 2. Stack Memory (Method Execution) Each thread has its own stack which stores method calls and local variables. 👉 Example: public void display() { int x = 10; } ✔ display() method → pushed into Stack ✔ x → stored in Stack ✔ After method ends → removed automatically 📌 Real-time: Like a call stack in your mobile – recent calls come and go. 🔹 3. Method Area / Metaspace (Class-Level Data) Stores class metadata, static variables, and constant pool. 👉 Example: class Test { static int count = 100; } ✔ count → stored in Method Area ✔ Class structure → also stored here 📌 Real-time: Like a blueprint shared across the entire application. 🔹 4. PC Register (Program Counter) Keeps track of the current instruction of a thread. 👉 Example: System.out.println("Hello"); System.out.println("Java"); ✔ PC Register tracks which line is currently executing 📌 Real-time: Like a cursor pointing to the current line in your code editor. 🔹 5. Native Method Stack (JNI Execution) Used when Java interacts with native (C/C++) code. 👉 Example: System.loadLibrary("nativeLib"); ✔ Native methods execution handled here 📌 Real-time: Like calling an external system/service from your application. 🧠 Quick Revision Trick: Objects → Heap Variables & Methods → Stack Static & Class Info → Method Area Execution Line → PC Register External Code → Native Stack #Java #JVM #MemoryManagement #JavaDeveloper #Backend #Coding #Programming #SpringBoot #Coding

💡 JVM Memory in 1 Minute – Where Your Java Code Actually Lives As Java developers, we often hear about Heap, Stack, and Metaspace—but what do they actually do at runtime? 🤔 Here’s a simple breakdown 👇 When your Java program runs, the JVM divides memory into different areas, each with a specific responsibility. ➡️ Heap • Stores all objects and runtime data • Shared across all threads • Managed by Garbage Collector How it works: • New objects are created in Young Generation (Eden) • Surviving objects move to Survivor spaces • Long-lived objects move to Old Generation GC behavior: • Minor GC → cleans Young Generation (fast) • Major/Full GC → cleans Old Generation (slower) ➡️ Metaspace (Java 8+) • Stores class metadata (class structure, methods, constants) • Uses native memory (outside heap) • Grows dynamically Important: • Does NOT store objects or actual data • Cleaned when classloaders are removed ➡️ Stack • Each thread has its own stack • Used for method execution Stores: • Local variables • Primitive values • Object references (not actual objects) Working: • Method call → push frame • Method ends → pop frame ➡️ PC Register • Tracks current instruction being executed • Each thread has its own Purpose: • Helps JVM know what to execute next • Important for multi-threading ➡️ Native Method Stack • Used for native (C/C++) calls • Accessed via JNI Class → Metaspace Object → Heap Execution → Stack Next step → PC Register Native calls → Native Stack #Java #JVM #MemoryManagement #SoftwareEngineering #BackendDevelopment

One Java concept that many developers use every day… but rarely understand deeply is Thread Safety It works fine in development… It passes tests… And then suddenly strange bugs start appearing in production What is Thread Safety? A piece of code is thread-safe if it behaves correctly when multiple threads access it at the same time. Real-World Example Imagine a simple counter: Two threads try to increment it simultaneously. You expect: "count = count + 2" But sometimes you get: "count + 1" Why? Because operations like increment are not atomic. Common Culprits • Shared mutable variables • Improper use of collections • Race conditions • Lack of synchronization How to handle it ✔ Use "synchronized" blocks carefully ✔ Prefer immutable objects ✔ Use concurrent collections like "ConcurrentHashMap" ✔ Explore utilities from "java.util.concurrent" Bottlenecks & Trade-offs • Overusing synchronization → performance issues • Underusing it → data inconsistency • Debugging concurrency bugs is extremely hard Why it’s ignored Because concurrency issues are not always visible immediately. They appear under load… when it’s already too late. Thread Safety isn’t just an advanced topic it’s a necessity for building reliable and scalable Java applications #Java #ThreadSafety #Concurrency #Multithreading #BackendDevelopment #SoftwareEngineering #JavaDeveloper #CodingBestPractices #TechLearning #ConcurrentProgramming #SystemDesign #Developers #Performance #Engineering #InterviewPrep

Most Java developers still write 15+ lines of boilerplate for a simple data class. Java Records changed everything. 🚀 Before Records (Java < 14): class Person { private final String name; private final int age; // constructor, getters, equals(), hashCode(), toString()... 😩 } After Records (Java 14+): record Person(String name, int age) {} That's it. Done. ✅ Key Takeaway 💡: Java Records auto-generate constructor, getters, equals(), hashCode(), and toString() — all immutable by default. Perfect for DTOs and data carriers! ⚠️ Remember: Records are immutable — you can't add setters. Use them when your data shouldn't change after creation. What's your go-to way to reduce boilerplate in Java — Records, Lombok, or something else? Drop it below! 👇 #Java #JavaDeveloper #CleanCode #JavaRecords #CodingTips #TodayILearned

30 Days - 30 Questions Journey Completed! 💻🔥 💡 Question: What is the difference between volatile and Atomic variables in Java? 🔹 volatile volatile ensures visibility of changes across threads. It guarantees that a variable is always read from main memory, not from thread cache. Example: ```java id="p8k3l2" volatile int count = 0; ``` --- 🔹 Problem with volatile volatile does NOT guarantee atomicity. Example: ```java id="x7m2q1" count++; // Not thread-safe ``` Because this operation is: Read → Modify → Write Multiple threads can interfere here. --- 🔹 Atomic Variables Atomic variables provide both: • Visibility • Atomicity Example: ```java id="d3k9s1" AtomicInteger count = new AtomicInteger(0); count.incrementAndGet(); ``` --- 🔹 Key Differences volatile • Ensures visibility • Not thread-safe for operations • Lightweight Atomic • Ensures visibility + atomicity • Thread-safe operations • Uses CAS (Compare-And-Swap) --- ⚡ Quick Facts • volatile is good for flags (true/false) • Atomic is used for counters and updates • Atomic classes are part of java.util.concurrent --- 📌 Interview Tip Use volatile for simple state visibility Use Atomic when performing read-modify-write operations --- Follow this series for 30 Days of Java Interview Questions. #java #javadeveloper #codinginterview #backenddeveloper #softwareengineer #programming #developers #tech

🤯 Every Java developer uses HashMap… But do you really know what happens when you call map.put("key", "value")? Let’s break it down 👇 ⚙️ Step 1 — Hashing Java calls hashCode() on the key, converting it into an integer. ⚙️ Step 2 — Bucket Calculation That hash is used to determine the index of the bucket (array slot): index = hashCode % array.length ⚙️ Step 3 — Storage The key-value pair is stored in that bucket as a Node. 🚨 What about collisions? When multiple keys map to the same bucket, a collision occurs. 👉 Before Java 8: Entries are stored using a LinkedList 👉 Java 8 and later: If entries exceed 8, it converts into a Red-Black Tree 🌳 for better performance 💡 Why this matters: ✔️ Average time complexity for get() and put() is O(1) ✔️ Not thread-safe (use ConcurrentHashMap in multi-threaded scenarios) ✔️ Always override hashCode() and equals() for custom key objects 🔑 Key Rule: If two objects are equal, they must have the same hashCode(). But the same hashCode() does not guarantee equality. This is one of the most commonly asked Java interview questions—and a fundamental concept every backend developer should truly understand. Have you faced this question in an interview? 👇 #Java #JavaDeveloper #BackendDevelopment #SpringBoot #JavaInterview #Programming #Coding #SoftwareEngineering

🚀 Day 18 – Java Streams: Writing Cleaner & Smarter Code Today I started exploring Java 8 Streams—a powerful way to process collections. Instead of writing traditional loops: List<Integer> nums = Arrays.asList(1, 2, 3, 4, 5); for (int n : nums) { if (n % 2 == 0) { System.out.println(n); } } 👉 With Streams: nums.stream() .filter(n -> n % 2 == 0) .forEach(System.out::println); --- 💡 What I liked about Streams: ✔ More readable and expressive ✔ Encourages functional style programming ✔ Easy to chain operations (filter, map, reduce) --- ⚠️ Important insight: Streams don’t store data—they process data pipelines 👉 Also: Streams are lazy → operations execute only when a terminal operation (like "forEach") is called --- 💡 Real takeaway: Streams are not just about shorter code—they help write clean, maintainable logic when working with collections. #Java #BackendDevelopment #Java8 #Streams #LearningInPublic