結論：
すべてのJavaプログラマはただちに本書を読むべきだ。読む時間がないのなら、あなたにはコードを書く資格がない。
理由：
・安い
Javaの並行処理を知るために、私は莫大な授業料を支払った。「synchronizedやvolatileを使ってはいけない」くらいの分別は最初からあったが、それ以上のことはなにも知らなかった。
並行処理には試行錯誤は役に立たない。テストは無力だ。正しいコードを書くか、それとも爆弾を作るか、どちらかだ。爆弾を作れば高くつく。
本書には、私が莫大な授業料を支払って知ったことがすべて書いてある。
・薄い
458ページは厚いと思えるかもしれないが、それは人間の頭が破壊的代入にしがみついているせいだ。破壊的代入と並行処理を両立させたいと人間が願う以上、この程度のページ数は避けられない。
・役に立つ
本書は実戦の勘所を押さえている。著者たちは、自分の足を撃つ方法がどれだけあるかを知っており、どの方法がよく使われるかも知っている。
本書で紹介される概念もきわめて有益だ。「スレッド束縛」という概念は、漠然と知ってはいたが（「synchronizedやvolatileを使ってはいけない」の理由の半分）、いままで名前を知らなかった。
・必要になったときにはもう遅い
常にマルチスレッドを避け続けるのは、それほど易しいことではない。どうしても簡単なワーカスレッドが欲しくなり、ごくごく簡単なものだからと思ってsynchronizedと書き――そして爆弾を作る。
いまのうちに備えておくべきだ。その日は来る。
とはいえ不満な点はゼロではない。
自分の足を撃つ方法をたくさん知っているからといって、自分の足を撃たずに過ごせるかというと、そうではない。自分の足を撃つ方法と、危険を遠ざけて暮らす方法は別のものだ。しかし本書は、危険そのものに注目し、結果として、危険のそばで暮らす方法に偏っている。
危険を遠ざけて暮らす方法を、私なりにまとめると、以下のとおり。
・スレッド束縛か、それともimmutableかの二者択一にする
スレッド束縛というのは、あるオブジェクト等を使える（参照できる）スレッドを、一度に一つに限定するということだ。スレッド間でオブジェクトを渡してもいいが、そのときは元のスレッドは、渡したオブジェクトへの参照を持っていてはいけない。
immutableなオブジェクトは完璧に安全だ。ただしJavaはろくに不変性をサポートしていないので、本当にimmuatbleなオブジェクトを作るには、よほど気をつける必要がある。
この二者択一ルールを守っているかぎり、synchronizedやvolatileはいらない。
・mutableなオブジェクトを共有するときには、java.util.concurrentを使う
java.util.concurrentには、必要なはずのものが一通り揃っている。synchronizedやvolatileは最後の手段だ。
・スレッドを直接には操作せず、Executorフレームワークを使う
自分でスレッドを生成するのは、synchronizedやvolatileと同じくらい危険な行為だ。Executorフレームワークを知り、これを前提にして設計すべきだ。
理想をいえば、Javaをやめて破壊的代入のない言語を使うべきだ。しかし残念ながら人類はまだその段階にたどりついていない。HaskellやCleanで突っ張るよりも、本書を読むほうが安くあがる。7andy