Java Performance: The Definitive Guide: Getting the Most Out of Your Code

Ever hear of the Baader-Meinhof Phenomenon? It's the name given for that weird feeling you have when you learn a new word you've never seen before, and then all of a sudden you're seeing it absolutely everywhere. It seems like every e-mail and every TV show is using this word, and you wonder to yourself how you managed to never notice it before, since it's all over the place now? Or maybe you start looking at a new car and researching it, and all of a sudden it seems like everyone on the road is driving that same car?

I had a very similar effect with this book. I've been a Java programmer for over a decade, but never really been terribly concerned with performance, or the internals of the JVM. I try to write good code in terms of using hashmaps and whatnot to do lookups in constant time rather than O(n) time, but microoptimizations were never my thing. I never really felt like it was something I needed to care about, I never really noticed any performance ISSUES in the products I've worked on during my career. But then whenever I'd finish a chapter in this book, I'd notice that the error messages the chapter mentioned, or the kind of things you might notice when performance is degraded started popping up. Within days of finishing the chapter on the Java Heap, we started experiencing Out of Memory errors on some nodes in our production cluster. I recognized the error messages from the book, and knew what tools to reach for because of it as well. After reading the sections on Threading and Java SE Optimizations, I immediately noticed us doing some goofy, ill-advised things in our code. But the out of memory errors had been happening for months I think, and the code I was noticing had been in place for over a year. This stuff had been all around me, and I just wasn't seeing it. The Baader-Meinhof Phenomenon in action.

Truth be told, this book was a bit of a slog to get through. I started it over a year ago, and the material is just so insanely dry that it was a battle. I'd rate myself maybe a 7 out of 10 in terms of interest level in stuff like JVM internals, flags, garbage collection algorithms, and so forth. I like systems stuff, I usually attend low-level system JVM type talks at conferences, but I still found the book, especially the first half, so incredibly dry that I could barely push my way through it. While talking to some buddies about this book, I estimated each chapter's length around 60-80 pages, and then when I checked it turned out most were only around 30 pages or so. Like a 1.5-hour movie that feels like 4, this book is almost punishing.

Don't get me wrong, it's full of useful information - in fact the degree to which it is densely, densely packed with information almost contributes to how dry it feels, since you can't read any part of it quickly due to how information-dense the pages are. I learned an absolute ton from this book and highlighted pages and pages worth of notes, but if you wouldn't give yourself a 6 or 7 out of 10 (or higher) on the scale of general-interest-in-JVM-internals, I think you probably stand no chance at making it all the way through the book.

If this kind of stuff is your cup of tea, definitely give this book a shot. I think it's the most up-to-date (it talks a lot about Java 7 and 8) of all of the books with the words "Java" and "Performance" in the title (I know of at least 3) and I think it's meant to effectively deprecate the others. If you're experiencing performance problems, or hell even if you're not but you want to be the person on your team who can fix them when they inevitably do arise, it's worth reading for sure. Just, be aware that you'll really have to like this kind of stuff to get through the whole thing.