Mikhail Backend’s Post

🧵 Mastering Thread Lifecycle & State Transitions in Java 🚀 Understanding thread states is crucial for writing efficient, bug-free concurrent applications. Here's a quick breakdown: 6 Thread States in Java: 1️⃣ NEW – Thread created but not started 2️⃣ RUNNABLE – Executing or ready to execute 3️⃣ BLOCKED – Waiting for monitor lock 4️⃣ WAITING – Waiting indefinitely for another thread 5️⃣ TIMED_WAITING – Waiting for a specified time 6️⃣ TERMINATED – Execution completed Key Transitions: • start() → NEW → RUNNABLE • sleep()/wait(timeout) → RUNNABLE → TIMED_WAITING • wait() → RUNNABLE → WAITING • I/O or lock acquisition → RUNNABLE → BLOCKED • notify()/notifyAll() → WAITING → RUNNABLE Q1: What's the difference between BLOCKED and WAITING states? A: BLOCKED occurs when a thread is waiting to acquire a monitor lock. WAITING happens when a thread waits indefinitely for another thread to perform a specific action (like notify() or join()). BLOCKED is lock-specific, WAITING is action-specific. Q2: Can a thread transition directly from WAITING to RUNNABLE without entering BLOCKED? A: Yes! When notify()/notifyAll() is called, the waiting thread moves directly to RUNNABLE state. It only enters BLOCKED if it needs to reacquire a lock that's held by another thread. Q3: How does yield() affect thread state? A: yield() is a hint to the scheduler that current thread is willing to pause its execution. The thread remains in RUNNABLE state and may immediately resume running—no state change occurs. It's just a suggestion, not guaranteed behavior. 💡 Pro Tip: Use jstack or visualvm to monitor thread states in production applications—invaluable for debugging deadlocks and performance issues! What threading challenges have you faced recently? 👇 #Java #Multithreading #Concurrency #Programming #SoftwareEngineering

Something weird happened while I was debugging a Java program today. I had a simple program running with multiple threads, and I printed the thread names just to see what was happening. The output looked something like this: main http-nio-8080-exec-1 http-nio-8080-exec-2 ForkJoinPool.commonPool-worker-3 At first I ignored it. But then I started wondering… Where are all these threads actually coming from? I didn’t create them. After digging a bit deeper, I realized something interesting. Modern Java applications are constantly using different thread pools behind the scenes. For example: • The web server creates request threads • "CompletableFuture" uses the ForkJoinPool • Some frameworks create background worker threads • The JVM itself runs internal service threads Which means even a “simple” backend service may actually be running dozens of threads at the same time. It made me realize something: A lot of complexity in backend systems isn’t in the code we write — it’s in the systems running around our code. Now I’m a lot more curious about what’s actually happening inside the JVM when our apps run. #Java #BackendEngineering #SpringBoot #SoftwareEngineering #LearningInPublic

Java has evolved significantly over the years. The image below shows a clear comparison: Java 7 on the left vs Java 25 on the right. What used to require a lot of boilerplate code can now be written in a much cleaner and more expressive way. Modern Java introduced powerful features such as: • Records to reduce boilerplate for data classes • Stream API for functional-style operations like map, filter, and reduce • Lambda expressions for concise anonymous functions • Pattern matching for more readable conditional logic • Local variable type inference (var) • Improved immutability patterns • Virtual threads (Project Loom) for lightweight concurrency • Built-in HTTP Client API for modern networking These improvements make Java far more expressive, maintainable, and efficient while still maintaining its strong backward compatibility. As someone working with Java and Spring Boot for backend development, it’s exciting to see how the language continues to modernize while staying reliable for building scalable systems. A great time to be building on the JVM. #Java #BackendDevelopment #SpringBoot #JVM #SoftwareEngineering

Java 26 is coming this March with several interesting updates and features. Loïc Mathieu breaks down what's landing in this release, including: • Stable releases of Vector API and Scoped Values • Preview features like Module Import Declarations • Incubator updates for Primitive Types in Patterns and Code Reflection API • Performance improvements and bug fixes Whether you're planning to upgrade or just want to stay current with Java's evolution, this article covers the key changes you need to know. Read the full breakdown here: https://lnkd.in/euurYNBv #Java #Java26 #OpenJDK #Programming

Many JVM developers don’t know what SingleFlight is, while Go developers do. It’s a simple idea: 👉 If multiple requests trigger the same expensive operation, run it once. 👉 Let the others wait for the result. In Java/Kotlin, we usually reinvent it with ConcurrentHashMap. But in Kubernetes, that’s not enough. I wrote a short guide on: • Implementing SingleFlight in Java/Kotlin • Why it breaks in multi-instance setups • Cache vs consistent hash routing • When duplication is cheaper than coordination https://lnkd.in/dYwQstxc #Java #Kotlin #DistributedSystems #Microservices #Kubernetes

☕ Java 26 is almost here The next release of Java is expected on March 17, and even though Java 26 is not an LTS, it still brings several interesting evolutions to the platform. One thing I’ve come to appreciate about Java is its predictable six-month release cadence. Instead of waiting years for innovation, the platform now introduces ideas earlier through preview and incubator features, letting the community experiment and shape them before they become permanent. Some things that caught my attention in Java 26 so far: 🔹 HTTP/3 support in the HttpClient API – bringing the built-in client closer to the modern web stack. 🔹 Structured Concurrency (Preview) – another step from Project Loom toward making concurrent code easier to reason about and maintain. 🔹 Primitive types in pattern matching (Preview) – continuing the steady expansion of pattern matching across the language. 🔹 Vector API (Incubator) – ongoing work to unlock high-performance computations that leverage modern CPU instructions. 🔹 Performance and JVM improvements, including updates in HotSpot and garbage collection. What I like about these releases is that they show how Java evolves: incrementally, but very deliberately. Features mature over several iterations before becoming standard, which often leads to very stable language improvements. Personally, I’m particularly curious to see how structured concurrency continues to evolve. It feels like one of the most promising changes for simplifying concurrent programming on the JVM. Are you planning to try Java 26 when it comes out? Are you planning to upgrade or experiment with Java 26 next week? 👇 #Java #OpenJDK #Java26 #BackendDevelopment #JVM #SoftwareEngineering #ProjectLoom #WebDev

I put together a small repo comparing how different JVM languages handle the same simple task: validating a Person with a few business rules and accumulating all errors at once. Nothing fancy — just the same logic in Java, Kotlin, Scala 3, Clojure, and Jank (https://lnkd.in/e7W7UCDm a new Clojure dialect that compiles natively via LLVM). What surprised me: the "traditional" Java version needed the most complex setup — three libraries and a multi-phase Gradle build — to do what Kotlin/Scala/Clojure express in a few lines out of the box. The JVM has a lot more to offer beyond Java. https://lnkd.in/ejcX-MPb

Recently worked on an interesting open-source contribution involving a nullability mismatch between Kotlin and Java components in a backend messaging/search pipeline. The issue occurred because a Kotlin method getCurrent() was declared as returning a nullable ThreadRecord?, while the Java code consuming it assumed the value was always non null. Since Java does not enforce Kotlin’s nullability at compile time, this mismatch could propagate into the search pipeline and potentially cause NullPointerExceptions when building MessageSearchResult objects. 🔎 What I did • Analyzed the interaction between the Kotlin data layer and the Java search repository • Traced how ThreadRecord objects were constructed and propagated through the pipeline • Identified where the nullability contract diverged from the original Java implementation • Adjusted the implementation to align with the intended non-null behavior • Ensured downstream components (ThreadSearchResult, MessageSearchResult) receive consistent data 💡 Key takeaway Working on existing codebases often means understanding architectural assumptions made years earlier. The challenge isn’t just fixing the code, but ensuring the fix aligns with the original design and doesn’t introduce regressions. This kind of debugging across Kotlin , Java boundaries is a great reminder of how subtle language interoperability issues can impact system stability. Open source continues to be one of the best ways to practice working with real production-style codebases. #opensource #java #kotlin #backend #softwareengineering #github

Recently, I revised some core Java concepts, and honestly, things started making more sense when I connected them practically. Polymorphism was one of the interesting parts. Method overloading happens at compile time, where the compiler already knows which method to call. But method overriding is different — the JVM decides at runtime, which makes it more dynamic. That’s where I understood the idea of early binding and late binding. Early binding is fixed during compilation, while late binding happens when the program is actually running. Dynamic method dispatch is just this in action — the JVM figuring out which method to execute based on the object. I also revised relationships in OOP. Inheritance follows an “is-a” relationship, like a cargo plane is a plane. Association is more of a “has-a” relationship, and it can be either strong (composition) or loose (aggregation). And one thing that helped me connect everything — Java code first becomes bytecode, and then JVM runs it. That’s where all the runtime decisions happen. Revisiting basics really helps in understanding how things actually work behind the scenes. #Java #OOP #Learning #CodingJourney