Java Memory Model (JMM) for Java Engineers

Stopping Threads Safely: Java does not allow killing a thread directly. Use interrupts as the “polite” way to request a thread to stop. Threads should check Thread.interrupted() or catch InterruptedException. Raw Threads vs Thread Pools With raw threads, you can interrupt them directly. With ThreadPool threads, you use ExecutorService.shutdown() or Future.cancel() to signal cancellation. Callable and Future: Wrapping tasks in Callable allows you to manage them with Future. Future.cancel(true) interrupts the task if it’s running. Useful for applying timeouts on long-running tasks. Volatile / AtomicBoolean Flags: Another approach is using a shared flag (volatile boolean stop = false;). The thread periodically checks this flag to decide whether to exit. AtomicBoolean provides thread-safe updates. Timeout Strategies: Use Thread.sleep() or scheduled tasks to enforce conditional timeouts. For blocking operations (DB calls, HTTP requests), combine interrupts with timeout-aware APIs. Example: future.get(timeout, TimeUnit.SECONDS). Practical Applications: Database Calls: Long stored procedures can be interrupted if they exceed SLA. HTTP Requests: Wrap in Future with timeout to avoid hanging threads. Schedulers: Cancel tasks after a fixed duration to maintain responsiveness. #Java #BackendDevelopment #SoftwareEngineering #MultiThreading #Concurrency #JavaPerformance #CodingTips #Programming #SystemDesign #Java

I’ve started documenting things I learn in a simple and structured way. The goal is to keep everything clear, connected, and easy to revisit—not just for others, but for myself as well. I just wrote one on what really happens when you run a Java program—from .java file to CPU execution. If you’re learning Java or revising fundamentals, this might help: Read here: https://lnkd.in/gQM8uH3F #Java #JVM #Programming #SoftwareEngineering

🚀 Are you already using Parallel Streams in Java? Parallel Streams can be a great tool for improving performance in collection operations by taking advantage of multiple CPU cores to process data in parallel. With a simple change: list.stream() to: list.parallelStream() or: list.stream().parallel() it’s possible to execute operations like filter, map, and reduce simultaneously. But be careful: parallelizing doesn’t always mean speeding things up. ⚠️ Some important points before using it: ✅ It’s worth it when: * There is a large amount of data; * Operations are CPU-intensive; * Tasks are independent and side-effect free. ❌ It may make things worse when: * The collection is small; * There are I/O operations (database, API calls, files); * There is synchronization or shared state; * Processing order matters. Also, Parallel Streams use ForkJoinPool.commonPool() by default, which may cause contention with other tasks in the application. 💡 Rule of thumb: measure before you optimize. Benchmarking with tools like JMH can help avoid decisions based on guesswork. When used correctly, Parallel Streams can be a powerful way to gain performance with minimal code changes. #Java #Performance #Backend #SoftwareDevelopment #Programming

Most Java applications don’t slow down because of bad code. They slow down because of Garbage Collection. Yes — the thing that’s supposed to help you. 👇 Java memory is split into: Young Generation (short-lived objects) Old Generation (long-lived objects) Sounds efficient, right? Here’s the problem: When too many objects move to Old Gen → 👉 Full GC kicks in And Full GC means: ❌ Stop-the-world pauses ❌ Latency spikes ❌ Users start feeling it So what do good engineers do differently? ✔ Use modern collectors like G1GC (default) ✔ For low latency → ZGC / Shenandoah ✔ Set proper heap size (-Xms = -Xmx) ✔ Monitor GC logs before guessing 💡 Truth most people ignore: You can’t eliminate GC. But you can make it predictable. Great engineers don’t just write code. They understand what happens after deployment. #Java #JVM #Performance #BackendEngineering #GarbageCollection

Go has no threads. Yet it handles 10x more concurrent requests than Java. Here is why that should change how you think about concurrency. When thousands of requests hit a server simultaneously, the biggest bottleneck is always the thread. Traditional languages like Java create one OS thread per request. Threads are heavy, kernel managed, and expensive to context switch. Go solved this differently with Goroutines. → A Goroutine's stack is dynamic. It only grows when it actually needs to, not upfront → Creating a Goroutine involves zero system calls. The kernel has no idea it exists → Context switching happens entirely in user space. No kernel involvement whatsoever → The Go scheduler handles everything. OS threads only see what Go exposes to them This is powered by the GMP model: → G: Goroutines, can run in the millions → M: Machine, the actual OS threads, just a handful → P: Processor, the logical CPU that schedules G onto M Millions of Goroutines multiplex across just a few OS threads. When a Goroutine blocks, Go detaches that thread, spins up work elsewhere, and keeps everything moving. The program never stalls. A Goroutine starts at just 2KB because Go's runtime manages memory dynamically instead of fixed provisioning like the OS does. This is not a language feature. It is an architectural decision. Minimize kernel involvement. Maximize work in user space. Let the runtime do what the OS was doing badly. That is the real reason Go scales the way it does. What architecture decision in your stack has had the biggest impact on performance? #GoLang #SystemDesign #BackendEngineering #Concurrency #BuildingInPublic #TechFounders #SoftwareArchitecture #Engineering #Programming #DevOps

Garbage Collection in Java – How JVM Cleans Memory 🧹 In C/C++, memory must be freed manually. In Java? The JVM handles it automatically using Garbage Collection. How it works: ▸ GC runs automatically inside the JVM ▸ Identifies objects with NO active references ▸ Removes them from Heap memory ▸ Frees space for new object allocation JVM Heap Structure: 1️⃣ Young Generation → New objects are created here → Minor GC runs frequently (fast cleanup) 2️⃣ Old Generation → Long-living objects move here → Major/Full GC runs here (slower & expensive) 3️⃣ Metaspace (Java 8+) → Stores class metadata → Replaced PermGen Can we force GC? ▸ "System.gc()" only suggests the JVM to run GC ▸ Execution is NOT guaranteed Behind the scenes: → JVM uses different GC algorithms like: ▸ Serial GC ▸ G1 GC (default in modern JVMs) ▸ ZGC / Shenandoah (low-latency collectors) Best Practices: → Avoid creating unnecessary objects → Don’t rely on "System.gc()" → Close resources using try-with-resources → Nullify references only when necessary (e.g., large unused objects) #Java #SpringBoot #GarbageCollection #JVM #JavaDeveloper #BackendDeveloper

The Java Exception Hierarchy: Know your tools. 🛠️ In Java, not all errors are created equal. Understanding the difference between Checked, Unchecked, and Errors is the "Aha!" moment for many developers. Checked Exceptions: Your "Expect the unexpected" scenarios (e.g., IOException). The compiler forces you to handle these. Unchecked Exceptions (Runtime): These are usually "Programmer Oopsies" (e.g., NullPointerException). They represent bugs that should be fixed, not just caught. Errors: The "System is on fire" scenario (e.g., OutOfMemoryError). Don't try to catch these; just let the ship sink gracefully. Mastering this hierarchy is the difference between writing "working" code and "production-ready" code. #JavaDevelopment #Coding #TechEducation #JVM #SoftwareArchitecture

🧠 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

**Memory Leaks in Production: how to detect and prevent them(Spring Boot)** - In Java, we often say "Garbage Collector handles memory so we don’t worry about leaks." But that’s only half true. Java doesn’t leak memory like C/C++, but it can leak references and that’s enough to crash our production system. * What Is a Memory Leak? --A memory leak is a scenario that happens when objects are no longer needed but are still referenced, so the Garbage Collector cannot reclaim them. The JVM is working correctly  but our code is holding references longer than it should. * Common Causes in Spring Boot Applications *   -Unbounded caches   -Static collections that keep growing   -ThreadLocal not cleared in thread pools -Large objects stored in HTTP session   -Event listeners not deregistered   -Reactive streams that never terminate These issues don’t fail the system immediately, they grow silently. *How to Detect a Memory Leak * 1️.  Monitor JVM Memory Use: -Spring Boot Actuator (jvm.memory.used) -Prometheus + Grafana -JMC / VisualVM  Red flag: Memory keeps increasing even after Full GC. 2️.  Check GC Behavior If you see: -Frequent Full GC -Increasing GC pause time -Old Gen not shrinking It indicates memory pressure or possible leak. 3️. Take a Heap Dump > jmap -dump:live,format=b,file=heap.hprof <PID> Then analyze using: -Eclipse MAT -Java Mission Control -VisualVM Focus on: -Dominator Tree -Retained Size -Reference chains from GC roots This shows what is preventing memory from being reclaimed. * How to Prevent Memory Leaks *  Prevention is architectural, not accidental.   -Use bounded caches (set max size & TTL)    -Always remove ThreadLocal values   - Avoid large objects in HTTP session    -Close resources using try-with-resources    -Avoid unnecessary static collections   -Monitor memory in production (don’t wait for OOM) #MemoryLeak #Java #SpringBoot #JVM #BackendDevelopment #Microservices #PerformanceEngineering