■はじめに○これからのCPUはマルチコアばかりなので、マルチスレッドを考慮しないといけないのでは?→クロック数ではもう性能が上がらないので、マルチスレッドは必須。threads○リナックスなどはN:Nスレッドだが、サンはSolaris9から1:1スレッド。→Windowsは1:1スレッド?→1:1スレッドの方がオーバーヘッドが少なく効率的。→CPUの数によっても違うので、一概にどちらがよいとは言えない。threads○Integerのアトミック演算子は、言語的には保証されていない。○リスト1.1の事象は、シングルCPUでもマルチスレッドで動作させると発生する。→volatileでも防げない。→synchronizeを使うしかない。○ソフトウェア解析ツールとはどのようなものか?→jTestやFindBugsのようなものか?→アノテーションを利用して、スレッドセーフでないコードを見つけてくれるようなもの?→そのようなツールは今は無い。→アプリケーション単位では可能かもしれないが、クラス単位ではスレッドセーフかどうかを見つけるのは困難。everywhere○Javaは起動時からマルチスレッドで動作する(JVMが勝手にスレッドを作る)が、.NETはシングルスレッドで動作する。→ユーザーのスレッドとライブラリのスレッドが擬似的に切り替わるのでは?→CPUが増えても変わらない?→Windows環境下なので、並列処理を必要としていない?→mustangでは、Maxスレッド数で制限される?○EJBではスレッド禁止令が出ている?→どちらにしてもスレッドは注意しなくてはならないもの。○サーブレットにはシングルスレッドで動作するようにするパラメータがある。→実際に使われることはない。→JavaEE5からは使用禁止になる?○RMIで、同じリモートオブジェクトの同じメソッドが複数のRMIのスレッドから同時に呼び出されることは、SUNは保証していない。○Timerは他に比べてやっかいなもの。→Timer(java.util.timer)は、アプリとは別のスレッド上で動いているため、使うならスレッドセーフである必要がある。→SwingにもTimerがあるが、この章では言及されていない。○今後はスレッドを使わない方向も・・。safety?○アトミックを理解しているJava開発者はどのくらいいるのか?→エンタープライズ系の開発者はトランザクションがあるので、知っているはず。→実際にはあまりいないだろう。○マルチスレッドは、テストすることは出来ない。○何故、スレッドセーフというと、まず「状態」なのか?→状態がスレッドで共有されるものだから。→状態がよりアクセスさせるものだから。Atomicity○「state」と出てくれば、概ね保護されるべき状態やフィールドを指す。○アンチパターンでは、他の状態にアクセスするメソッドがある場合はアトミックでなくてもいいとある。○AtomicLongの実装は、JavaSE6から。Locking○AtomicDoubleが存在しない。locks○FindBugsが見つけるsynchronizeのバグとは?→常にsynchronizeされているわけではないもの。Visibility○volatile変数は、書き込み時に最初にキャッシュを無効化して書き込みをするために非volatile変数に比べてそれほど早いものではない。○synchronize変数よりvolatile変数が早いとは必ずしも言えないが、遅くなる要素はない。escapeより開始。→うまい訳が見つからないので、そのまま「インターリーブ」とする。