<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Non-Blocking on Devops Monk</title><link>https://devops-monk.com/tags/non-blocking/</link><description>Recent content in Non-Blocking on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 04 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://devops-monk.com/tags/non-blocking/index.xml" rel="self" type="application/rss+xml"/><item><title>CompletableFuture: Async Pipelines and Non-Blocking Composition</title><link>https://devops-monk.com/tutorials/java8/completablefuture/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/java8/completablefuture/</guid><description>The Problem with Future&amp;lt;T&amp;gt; Java 5 introduced Future&amp;lt;T&amp;gt; for async computation. The problem: you can only get the result by calling get(), which blocks:
// Java 7 ExecutorService pool = Executors.newFixedThreadPool(4); Future&amp;lt;User&amp;gt; future = pool.submit(() -&amp;gt; fetchUser(userId)); // ... User user = future.get(); // BLOCKS until done If you have multiple async operations that depend on each other, you end up with a chain of blocking get() calls — effectively synchronous execution with extra overhead.</description></item></channel></rss>