Java Concurrency in Practice

What Hacker News says

1. hibikirMay 2026
   When we go back to early Java, the death of books just came from better IDEs, not even stack overflow (which wasn't there) or Google search (which had little to find). Something like IntelliJ made the very large reference section irrelevant, as you got to see source and Javadocs right there. Intellisense also found most of what you needed blindly. That was 90% of those 6 java books. You'd still see a need for specifics good explanations like, say, Java concurrency in practice for all the original low level primitives. Maybe some madman that could explain the initial implementation of the Calendar classes.

   Either way, one needed far smaller books the moment all of that came in, especially because in Java, library code is very readable. Compare that to looking inside a C++ standard library: It's not impossible, but it's of a completely different nature of normal C++ we might write for a business.

   Show morethread
2. PoogeNov 2025
   Java Concurrency in Practice[1] has always been recommended by my colleagues. I'm about halfway through it and I think it makes the concepts pretty clear. Even if you move away from Java one day, I think the investment is not lost at all. Then you could ask your favorite LLM to create concurrency exercises once in a while to practice.

   [1]: ISBN 978-0321349606

   thread
3. vips7LSep 2025
   Fun read! Makes me realize I should probably go reread Java Concurrency in Practice.
   thread
4. pjmlpAug 2025
   Although a bit outdated, Java Concurrency in Practice is also a very good one, written by Brian Goetz, before he became one of the leading architects on Java.
   thread
5. cogman10Oct 2024
   There seems to be a lot of voodoo beliefs around concurrent programming that lead to really bad things.

   One of the best books I've read on it is Java concurrency in practice [1]. It does an excellent job of dispelling these occultic beliefs and letting the reader know exactly when and how concurrency should be implemented. It is applicable to more languages than just java, especially since many have adopted large parts of the java memory model.

   The worst things I usually find when reviewing concurrent code is people either not using locks when they should, using locks when they shouldn't, and having inconsistent data guards. I've seen people throw in random locks to guard local non-shared state which is just crazy town but "Multiple threads are running this code, so I'm adding a lock".

   I certainly prefer message passing over shared state. However, it's a little baffling to me why it's so hard for devs to grasp how to properly maintain shared state. Instead of just learning the basic rules, it gets couched in "It's just too hard to understand so keep adding things until it works".

   [1] https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz...

   Show morethread
6. cogman10Oct 2024
   > Not too sure what the basic rules are and I'm not able to find any list of such rules.

   I'd suggest the book in my original comment, Java concurrency in practice.

   > If I use very fine grained mutexes then I end up with faster code that has very hard to find bugs that happen on very rare occasion.

   I agree this is a real risk if you are doing fine grained mutexes. But the rules are the same whether or not you want to follow them. If you have shared state (A, B, C) and you want to do a calculation based on the values of (A, B, C) then you need a mutex which locks (A, B, C). Certainly, that become a problem if you have calculations that just require (A, C) and you might want to avoid locking for B. In that case, you need a more complicated mechanism for locking than just simple mutexes which is certainly easy to get wrong. When the (A, B, C) actions happen you have to ensure that the (A, C) actions can't happen at the same time.

   This isn't a complicated rule, but it is one that can be hard to follow if you are trying to do super fine grained locking. It's even trickier if you are going to abuse the platform to get correct results.

   But fine v coarse isn't the problem I'm referring to when I say people get the simple rules wrong. Rather, than worrying about fine vs coarse grained locking, I very frequently see code where mutexes and concurrency primitives are just peppered everywhere and haphazardly. We might call that super coarse grained.

   Show morethread