Rafael Leme Costa’s Post

Most Java devs know Tomcat caps at ~200 threads. What Project Loom did about it. The issue: every Java thread maps to an OS thread. ~1MB RAM each. Under heavy I/O, 90% of those threads are just blocked (waiting on a DB, an API, a file). Sitting idle. Burning memory. Request 201? It waits. Or drops. That's been Java's reality for 20 years. Not a bug. A design constraint. Project Loom flips the model: Virtual thread hits a blocking call -> unmounts from OS thread -> OS thread immediately picks up next task -> millions of concurrent tasks, same machine. You write the exact same blocking code. The JVM does the scheduling. What changes: 1. Not execution speed 2. How many requests your server handles before it says "wait" 3. No reactive rewrite (WebFlux, RxJava) 4. Lower cloud bill. Same codebase. One thing interviewers love to ask: "what's the catch?" Two real ones: 1. Synchronized blocks pin virtual threads. Can silently kill your scaling gains. Check JVM pinning logs. 2. ThreadLocal breaks at scale. Use ScopedValue. Same code. Way cheaper server. #Java #ProjectLoom #SystemDesign #Backend #JavaDeveloper

Java Streams are killing your performance Java Streams look clean… but they can silently destroy your performance. I saw this in a production audit last week. A simple loop processing 1M records was replaced with streams “for readability”. // ❌ Stream version list.stream() .filter(x -> x.isActive()) .map(x -> transform(x)) .collect(Collectors.toList()); // ✅ Optimized loop List<Result> result = new ArrayList<>(); for (Item x : list) { if (x.isActive()) { result.add(transform(x)); } } 🚨 What happened in production: • CPU usage increased by 35% • GC pressure exploded • Latency x2 under load ❗ Why? Streams: • Create more objects • Add hidden overhead • Are NOT always optimized by JVM ✅ Fix: • Use streams for readability (small datasets) • Use loops for performance-critical paths • Benchmark before choosing https://www.joptimize.io/ Clean code ≠ fast code. Are you using streams in performance-sensitive code? #JavaDev #SpringBoot #JavaPerformance #Backend #SoftwareEngineering

Most Java developers can't trace a request from Tomcat through to the database. Yet, understanding this flow is the difference between guessing in production and knowing exactly where to look when issues arise. Here’s how a Spring Boot request really works: Entry & Filters: The request hits Tomcat, passing through the Filter Chain for security and CORS handling. Routing: DispatcherServlet uses Handler Mapping to locate the correct @Controller. Logic: The Controller validates input and delegates business logic to the Service Layer. Data: Repository Layer translates method calls into SQL via Spring Data JPA. Response: Jackson serializes the resulting Java object to JSON, sending it back through the filters. This lifecycle isn’t magic. Understanding it turns a coder into an architect, able to diagnose problems and optimize performance with precision. Tracing tools like Micrometer provide unified APIs for recording traces and spans, essential in microservices and complex apps. Enabling tracing in Spring Boot 3 involves integrating appropriate exporters and addressing challenges like context propagation with utilities such as ContextPropagatingTaskDecorator. Setting up embedded Tomcat logs—including internal and access logs—is critical for monitoring performance and request handling. Custom filters leveraging ContentCaching wrappers offer strategies to log requests and responses to databases, though payload size and storage considerations must be balanced. Grasping the request lifecycle removes guesswork. It elevates how we build, troubleshoot, and scale applications. Which layer in this breakdown challenges you most? #Java #Programming #CleanCode #SoftwareEngineering #CodingTips #Tech #RESTAPI

I’ve seen this discussion many times — and the answer is more nuanced than “Streams vs loops”. Yes, streams can introduce overhead in certain scenarios. But the real issue isn’t the syntax. It’s using abstractions without understanding their cost. In performance-sensitive paths, what matters is: allocation patterns GC pressure data size and access patterns Streams can be perfectly fine. Or a bottleneck — depending on context. The dangerous part is optimizing based on assumptions instead of measurements. Clean code vs performance isn’t a trade-off. Blind abstraction vs informed decisions is.

Although streams might use more cpu , they’re incredibly useful when you want to transform from a collection to an array or if you simply want to map a dto from a model

🚀 Solving a Critical Memory Retention Issue After Java 21 Migration Recently, I worked on resolving a critical memory retention issue in a high-throughput document processing microservice following a Java 21 & Spring Boot 3 migration. This service handles large document uploads, multipart files, and link-based document ingestion under heavy concurrent load. Post-migration, we observed abnormally high heap memory retention, increasing GC pressure and impacting runtime stability. 🔍 The Challenge • Extremely high retained heap memory under load • Increased GC pressure and latency • Memory growth proportional to concurrent requests • Heap dump analysis showed request-level observation objects as dominant GC roots 🧠 Root Cause Identified Spring Boot 3 introduced implicit Micrometer Observability instrumentation: • Security filter chain wrapped with observations • Entire HTTP request lifecycle instrumented • ~90+ objects allocated per request • No metrics backend configured — leading to memory overhead without observability benefit Under heavy traffic, these allocations accumulated and caused significant heap retention. 🛠️ Resolution Implemented • Disabled observation wrapping in Spring Security filter chain • Disabled servlet-level HTTP observation • Injected 'ObservationRegistry.NOOP' • Restored lightweight request-processing behavior 📈 Outcome ✅ Eliminated per-request observation allocations ✅ Significantly reduced heap usage & GC pressure ✅ Improved runtime stability and throughput ✅ Zero functional impact 💡 Key Takeaway Major framework upgrades can introduce implicit behavioral changes that only surface under load. This experience reinforced the importance of: • Load testing • Heap profiling • Deep root cause analysis • Performance-focused engineering Solving problems at scale like these is always rewarding — especially when they improve system stability, performance, and reliability. #Java21 #SpringBoot3 #Microservices #PerformanceEngineering #MemoryOptimization #SoftwareEngineering #BackendEngineering #Scalability #Java #SystemDesign #TechLeadership

⚡ Java Performance Tuning: 9 years of lessons in one post. "The code works, so it's fine." This sentence has caused more production outages than bad code. Performance issues I've seen again and again: 🐌 N+1 query problems in JPA/Hibernate → Always check your SQL logs. Always. Use @EntityGraph or JOIN FETCH. 🐌 String concatenation in loops → StringBuilder exists for a reason. Use it. 🐌 Lazy loading triggering outside the session → Understand your fetch strategies before you deploy. 🐌 Synchronized methods on high-throughput paths → Profile first, synchronize only what needs it. 🐌 Object creation inside tight loops → Every `new` inside a loop is a GC candidate. Profile your allocations. My performance workflow: 1️⃣ Measure first — don't guess, profile with JProfiler/VisualVM/async-profiler 2️⃣ Find the hotspot — 80% of issues come from 20% of the code 3️⃣ Fix the bottleneck — not everything around it 4️⃣ Measure again — confirm the improvement "Premature optimization is the root of all evil" — but so is ignoring production metrics. What's the biggest Java performance win you've achieved? 👇 #Java #Performance #SpringBoot #JVM #BackendDevelopment

Most Java performance issues don’t show up in code reviews They show up in object lifetimes. Two pieces of code can look identical: same logic same complexity same output But behave completely differently in production. Why? Because of how long objects live. Example patterns: creating objects inside tight loops → short-lived → frequent GC holding references longer than needed → objects move to old gen caching “just in case” → memory pressure builds silently Nothing looks wrong in the code. But at runtime: GC frequency increases pause times grow latency becomes unpredictable And the worst part? 👉 It doesn’t fail immediately. 👉 It degrades slowly. This is why some systems: pass load tests work fine initially then become unstable weeks later Takeaway: In Java, performance isn’t just about what you do. It’s about how long your data stays alive while doing it. #Java #JVM #Performance #Backend #SoftwareEngineering

Thread Pools to Virtual Threads. 🧵 OutOfMemoryError it is a nightmare that has always haunted Java developers. We're always been stuck with Platform Threads (heavyweight wrappers around OS threads). Since each one cost about 1MB of memory, handling 10,000 concurrent requests meant you either needed a massive, expensive server or had to write complex reactive code that nobody actually wants to debug. Enter Project Loom (Java 21+). I’ve been diving into Virtual Threads, and the "blocking" game has completely changed. Here’s why this matters for the modern backend: Cheap as Chips: Virtual threads are managed by the JVM, not the OS. They only cost a few hundred bytes. You can literally spawn one million threads on a standard laptop without breaking a sweat. The "Thread-per-Request" Revival: We can go back to writing simple, readable, synchronous code. No more "Callback Hell" or complex Mono/Flux chains just to keep the CPU busy while waiting for a database response. Massive Throughput: In I/O-heavy applications (which most Spring Boot apps are), Virtual Threads allow the CPU to switch to other tasks instantly while one thread waits for a slow API or SQL query. How to use it in Spring Boot 3.2+? It’s literally one line in your application.properties: spring.threads.virtual.enabled=true By flipping this switch, Tomcat/Undertow starts using Virtual Threads to handle web requests. It’s a complete paradigm shift that lets us build more scalable systems with less infrastructure cost. The takeaway for teams: We no longer have to choose between "easy-to-read code" and "high-performance code." With Java 21, we get both. #Java #SpringBoot #BackendDevelopment #ProjectLoom #SoftwareEngineering #Scalability #JVM

Most Spring Boot apps I've reviewed in production don't fail because of bad logic. They fail because of 𝗹𝗮𝘇𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻𝘀 that nobody questioned. Here's what I wish someone told me earlier. Stop returning entity objects directly from your controllers. It seems convenient until you accidentally expose sensitive fields or break your API contract when the schema changes. Always map to a dedicated response DTO. Your future self will thank you when a database column rename doesn't trigger a client-side outage. Use constructor injection instead of `@Autowired` on fields. It makes your dependencies explicit, simplifies testing, and lets the compiler catch missing beans before runtime does. Spring actually recommends this approach. Java @RestController public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } } Configure 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲 𝗽𝗿𝗼𝗳𝗶𝗹𝗲𝘀 for each environment from day one. Hardcoding values in `application.properties` and "fixing it later" is technical debt that compounds fast. Use `application-dev.yml`, `application-prod.yml`, and externalize secrets through environment variables or a vault. One more thing people overlook: 𝗮𝗹𝘄𝗮𝘆𝘀 𝘀𝗲𝘁 𝗲𝘅𝗽𝗹𝗶𝗰𝗶𝘁 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝗶𝗲𝘀 with `@Transactional` on your service layer, not your repository layer. It gives you control over rollback behavior when multiple repositories are involved. What's one Spring Boot default you learned the hard way should have been overridden? #SpringBoot #Java #BackendDevelopment #SoftwareEngineering #CleanCode