Brian Goetz

Every programming language needs to have a book like Java Concurrency in Practice. I usually do not like books about specific programming languages because they tend to become obsolete so quickly. They are so specific to a particular version of a particular language that any small change renders them useless.

That is not the case with Java Concurrency in Practice. This book mixes general concurrency background and advice with Java specific advice with advice applicable to only certain versions of Java. Even as new versions of Java come out, this book will still have value (although not as much as at initial publication). Even as other languages become primary, there are still many parts of the book that will be worth rereading (but not all, which is why I say every language needs its own equivalent of this book).

Java Concurrency in Practice reads well. I found myself looking forward to reading it, which is not always the case with technical books. The organization built up knowledge gradually, making sure that a concept or library call was introduced before using it. In fact, the few times something, like join(), was brought up without introduction it was abnormal enough to be memorable.

The book starts with an introduction to concurrency. It first motivates the importance of concurrency: from here on out, speed-up comes mostly from having more cores. It then moves on to defining basic concepts such as thread safety, atomicity, locking, liveness, visibility, and publication. I feel like I have a reasonable background with concurrency in theory (although not in practice). Even so, I learned a lot from these introductory chapters. I usually considered concurrency primitives mainly as a way of controlling data access. I had not thought about the their relation to memory visibility, especially in the face of optimizing compilers.

The bulk of the book talks about techniques for building thread safe, reasonably performant programs. These rules are meant to make your programs safe and comprehensible. They may not squeeze the last bit of efficiency out of your code, but the authors strongly make the case that such optimization usually is not necessary. Clever tricks may make code faster, but they make it more likely to be wrong and harder to maintain. Furthermore, in the face of program optimization, hand tuned code may end up being slower than more naive code that has been optimized.

Instead, the authors advice programmers to write easy to understand and safe programs first and then find and optimize the bottlenecks. These range from low level rules such as favoring immutable objects whenever possible to high level guidance on how to structure programs (e.g., how fine grained should your concurrency be? Threads and context switching, while relatively cheap, are not free.)

Part of what makes this book great, however, is that the authors do not treat you like you are stupid. After spending most of the book helping you to understand the complexities of concurrency, they spend the last part of the book giving you the tools to shoot yourself in the foot. They realize that, just as sometimes it really is worth it to write assembly, sometimes performance requirements force you to use higher risk concurrency techniques. In this vein, the last chapters discuss explicit locks, custom synchronizers, nonblocking synchronization, and the Java memory model.

I highly recommend Java Concurrency in Practice to any Java programmer. Even if you are not explicitly using concurrency in your code, it shows up implicitly in enough libraries that it is worth reading at least the first part of the book. If you primarily program in another language, I would recommend that you find the equivalent book for your language of choice. Understanding concurrency is quickly becoming required knowledge for programmers.… (meer)

This is a really crucial book for any Java developer. You may not realize you need it, but man oh man, you do!

The Java culture and language development contain a trap: whereas it once was a commonplace that concurrent programming was too hard for "ordinary" developers, Java made it easy to do, and even in the beginning reasonably easy to do successfully.

Times have changed. Java programs used to run on uniprocessor machines (where "concurrency" is more an aspiration than a reality), and the Java virtual machine used to be relatively simple. Nowadays, even an inexpensive laptop has at least two cores, and can achieve real concurrency among half a dozen Java threads. The JVM has evolved aggressively to use this power, taking liberal advantage of feature always contained in the Java language specifications, but until now not necessary embodied in the JVM implementation. As a result, more and more, your programs do not mean what they appear to mean, and less and less are you free to presume they do.Fortunately, the principal and supporting authors here are the powerful minds behind the growth of the JVM's concurrency capabilities. And, a bit miraculously, these great minds, deeply embedded in this complex code, can and do explain its surprises and mastery in a way that should be accessible to any competent programmer. This is not "for Dummies" stuff, but it's also "not rocket science" (quite). You can handle this.

And, you must.… (meer)