Java Concurrency from the Trenches: Lessons Learned in the Wild

"We are going to talk a little bit about Java concurrency from the trenches. You might ask, why from the trenches, why I picked this particular word. The reason being because this talk is based on my own learnings through a project that I did through the last year. Everything I'm going to be talking about here is based on a project that I worked through the last year until now at Netflix."

"One interesting fact is that even though I worked at all these companies in some platform engineering teams, search infrastructures, code reviews, things like that, most of the time I consider myself a product developer. I am not a performance engineer. I am not a JVM engineer. I don't have actually deep expertise on those topics. You are going to notice why this is important for this talk."

"Another interesting fact is that I didn't have to deal with the complexities of concurrency for most of the time. Most of the time I was just doing my application, and then my Spring framework was taking care of the threads for me, was taking care of all of that until it couldn't. In this project, I had that idea that I had actually to learn a little bit about concurrency myself and try to do some experiments and learn things the hard way."

A year-long Netflix project required hands-on learning of Java concurrency beyond framework defaults. The engineer had 15 years of software experience across major companies but lacked deep JVM and performance engineering expertise. Frameworks like Spring had handled threading until the project exposed their limits, prompting direct experiments, trials, and mistakes to understand concurrency behavior. The work produced concrete, experience-driven lessons and pragmatic guidance aimed at developers who write concurrent Java code and need practical strategies to diagnose, debug, and evolve concurrency in real production systems.

Read at InfoQ