Java Integer Cache Gotcha: == vs equals()

🛑 Stop Saying the Garbage Collector Cleans the Stack A misconception that still appears in backend discussions is the belief that “GC handles all memory in Java.” This is not true, and understanding the distinction is crucial for performance. Stack vs Heap: Two Very Different Worlds 1. Stack (Execution Memory) - Every method call creates a stack frame; when the method returns, the frame is discarded. - No GC involvement. - No tracing or sweeping. - Lifecycle is deterministic (tied to method execution). - The JVM may internally allocate frames differently, but their lifecycle is strictly bound to execution—not garbage collection. 2. Heap (Managed Memory) - Objects reside here, and this is where the Garbage Collector operates. - Utilizes algorithms like generational collection, marking, and compaction. - Trades memory efficiency for runtime overhead. - Can introduce pauses or CPU overhead depending on allocation patterns. 💡 The Important Insight The stack doesn’t free memory; it determines reachability. When a method returns: - Its stack frame disappears. - References held in that frame disappear. - Objects become eligible for GC. 📚 JVM Spec (§2.5.2): Frames are created and destroyed with method execution—not managed by the garbage collector. #Java #JVM #Backend #Performance #SystemDesign

InterruptedException is not an error. It’s how threads are asked to stop. And ignoring it can make your application impossible to shut down. --- In Java’s threading model, interruption was never designed as a failure mechanism. It’s a signal. A coordination event between threads. --- Calling interrupt() is the intended way to ask a thread to stop. But it doesn’t stop it. It sets a flag. And if the thread is blocked, it may react by throwing InterruptedException. Here is the trap: when that exception is thrown, the flag is cleared. If you ignore it, you erase the signal. If you care about it, you must restore it: Thread.currentThread().interrupt(); --- This is the model. And most code ignores it. Consider this: try {     queue.take();   } catch (InterruptedException e) {     // ignore   } Looks harmless. It’s not. From that point on, your thread behaves as if no interruption ever happened. The JVM asked it to stop. Your code said: no. This is how systems become impossible to shut down cleanly. Threads keep running. Executors don’t terminate. Shutdown hooks hang. And eventually: kill -9 This is not a rare edge case. It’s the direct consequence of coding against the model. --- There is a contract: If you catch InterruptedException, you must either: - propagate it - or restore the flag Interruption is not about failure. It’s about control. It’s how the JVM coordinates lifecycle across threads. When you ignore it, you’re not just hiding a problem. You’re breaking the control plane of your application. Final thought Most systems don’t fail because something crashed. They fail because something refused to stop. A thread that ignores interruption is not resilient. It’s uncontrollable. And in production, uncontrollable systems don’t degrade. They hang. Then they get killed. 💬 How do you handle interruption in your production code? #Java #JVM #Multithreading #Backend #SoftwareEngineering

🚀 Java Memory Mastery: The String Constant Pool Ever wondered how Java handles millions of strings without crashing your memory? Meet the String Constant Pool (SCP)—the JVM's secret "unique-only" library. In this breakdown, I deconstruct the "Two-Object Trap": Literals ("Hello"): Check the pool. If it’s there, reuse it. Efficient and fast. The new Keyword: Forces a brand new object into the Heap, even if the text already exists. The Pro-Tip: Use .intern() to manually move Heap strings into the pool and keep your memory footprint lean. Stop duplicating data. Start optimizing your architecture. 🛠️ #Java #BackendEngineering #SystemDesign #JVM #SoftwareDevelopment #TheBytecodePhantom

Day 83 - Path Sum Checked whether a binary tree has a root-to-leaf path equal to a given target sum. Approach: • Subtract current node value from targetSum • Recursively check left and right subtrees • At leaf node, verify if remaining sum equals node value Time Complexity: O(n) Space Complexity: O(h) #Day83 #LeetCode #BinaryTree #Recursion #DSA #Java #CodingJourney

Most concurrency bugs are not because of threads… they’re because of shared mutable state. 🚨 One thing that has saved me multiple times in Java: Immutability. In multi-threaded applications, multiple threads accessing the same object can easily lead to: → Race conditions → Inconsistent data → Hard-to-debug production issues The simplest way to avoid this? Don’t allow the data to change. What I follow 👇 ✔ Use immutable objects wherever possible ✔ Make fields final ✔ Avoid setters for shared data ✔ Prefer returning new objects instead of modifying existing ones Why this works: Immutable objects are inherently thread-safe. No locks. No synchronization. No surprises. In real systems, this reduces a huge class of bugs without adding complexity. Sometimes the best concurrency solution… is not writing concurrent code at all. Do you actively use immutability in your designs? 👇 #Java #Multithreading #Concurrency #BackendDevelopment #SoftwareEngineering #CleanCode

Linked list problems often test how well you can manipulate pointers without losing track. 🚀 Day 114/365 — DSA Challenge Solved: Swap Nodes in Pairs Problem idea: We need to swap every two adjacent nodes in a linked list without changing values, only pointers. Efficient approach: Use a dummy node and carefully adjust pointers in pairs. Steps: 1. Use a dummy node pointing to head 2. Maintain a pointer prev before the current pair 3. Identify two nodes: first and second 4. Swap them by updating pointers 5. Move prev forward to the next pair This ensures all pairs are swapped correctly. ⏱ Time: O(n) 📦 Space: O(1) Day 114/365 complete. 💻 251 days to go. Code: https://lnkd.in/dad5sZfu #DSA #Java #LinkedList #LeetCode #LearningInPublic

The Java Virtual Machine (JVM) is a masterpiece of complex engineering. It’s not just an interpreter; it’s a runtime ecosystem managing execution, memory, and performance optimizations dynamically. If you want to debug advanced performance bottlenecks or optimize high-scale backend services, you must understand how the JVM processes your code. We break it down into four core pillars: 1️⃣ The ClassLoader: How .class files are verified and initialized into the system. 2️⃣ The Runtime Data Areas: The "Phantom Zones"—Stack (thread-safe operations), Heap (object storage), and the Metaspace. 3️⃣ The Execution Engine: Where the magic happens (Interpreter + JIT Compiler + Garbage Collector). 4️⃣ Native Interface: How Java communicates with the underlying Operating System. Master the machine. Control the code. [Log_Level: Deep_Dive] #TheBytecodePhantom #Java #JVM #SystemArchitecture #SoftwareEngineering #BackendDeveloper #TechDeepDive

Day 89 - Search in a Binary Search Tree Located a target node. Approach: • If value equals → return node • If target is smaller → move left • If target is greater → move right Time Complexity: O(h) Space Complexity: O(h) #Day89 #LeetCode #BST #BinaryTree #Recursion #Java #DSA

𝐇𝐞𝐚𝐩 𝐯𝐬 𝐒𝐭𝐚𝐜𝐤: 𝐓𝐡𝐞 𝐇𝐢𝐝𝐝𝐞𝐧 𝐁𝐚𝐭𝐭𝐥𝐞 𝐈𝐧𝐬𝐢𝐝𝐞 𝐘𝐨𝐮𝐫 𝐉𝐚𝐯𝐚 𝐀𝐩𝐩 Where does your data actually live in Java? 𝐒𝐓𝐀𝐂𝐊 ✔️ Very fast ✔️ Stores local variables & method calls ✔️ Thread-specific ✔️ Limited → StackOverflowError 𝐇𝐄𝐀𝐏 ✔️ Stores objects & arrays ✔️ Shared across threads ✔️ GC managed ✔️ Larger but slower Truth: 👉 Stack = speed (LIFO) 👉 Heap = flexibility (GC overhead) Focus on object creation & GC tuning for real performance gains 👉 Follow Madhu K. for simple & precise tech content #Java #Backend #Performance #JVM #Developers #Coding

Stop wasting memory on threads that do nothing. 🛑 If you’re building Java backends, you’ve probably seen this: More users → more threads → more RAM usage I recently explored Virtual Threads (Java 21 / Project Loom), and this concept finally clicked for me. 💡 The Problem In standard Java: 1 request = 1 Platform Thread During DB/API call → thread gets blocked It’s like a waiter standing idle while food is cooking 🍽️ 👉 Wasted resources + poor scalability 🔍 The Solution: Virtual Threads 👉 Lightweight threads managed by JVM (not OS) Cheap to create Can run thousands easily Perfect for I/O-heavy backend systems ⚙️ How it actually works (Mounting / Unmounting) 1️⃣ Mounting Virtual Thread runs on a Carrier Thread (Platform Thread) 2️⃣ I/O Call (DB/API) Your code looks blocking 3️⃣ Unmounting (Parking) Virtual Thread is paused & parked in heap memory 👉 It releases the Carrier Thread 4️⃣ Carrier Thread is free Handles another request immediately 5️⃣ Remounting (Resume) Once response comes → Virtual Thread continues 💻 The "magic" in code // Looks like blocking code Runnable task = () -> { System.out.println("Processing: " + Thread.currentThread()); String data = fetchDataFromDB(); // DB/API call System.out.println("Result: " + data); }; // Run using Virtual Thread Thread.ofVirtual().start(task); 🧩 What’s happening behind the scenes? 👉 Thread.ofVirtual() Creates a lightweight thread (stored in heap, not OS-level) 👉 During DB/API call Virtual Thread gets unmounted (parked) Carrier Thread becomes free 👉 While waiting Same thread handles other requests 👉 When response comes Scheduler remounts Virtual Thread Execution continues 📈 Result No idle threads Better resource usage Simple synchronous code High scalability without complex async code 🧠 Biggest takeaway 👉 “Code looks blocking… but system is not blocked.” That’s the mindset shift. Have you tried Virtual Threads in your services yet? Did you see any real performance improvement? 🤔 #Java #BackendEngineering #VirtualThreads #ProjectLoom #Java21 #Microservices #Performance