読書会(JAVA CONCURRENCY IN PRACTICE)第1回議事録

[ 戻る ]

「Java Concurrency in Practice」を読む会　第1回議事録

日時：2006年7月15日（土）　10:00〜17:00
場所：高津市民館第4会議室

参加者（敬称略）：高橋(徹)、高橋(智)、根本、遠藤、小松、岩室、村山、門脇、吉本
読み手(訳者)（敬称略）：根本(1.1、1.2)、遠藤(1.3)、高橋(智)(1.4、2.4、2.5)、小松(2.1)、
　　　　　　　　　　　　岩室(2.2)、高橋(徹)(2.3)、村山(3.1)
書記：吉本


■はじめに

　○これからのCPUはマルチコアばかりなので、マルチスレッドを考慮しないといけないのでは？
　　→クロック数ではもう性能が上がらないので、マルチスレッドは必須。

■1.1　A (Very) brief history of concurrency

■1.2　Benefits of threads

　○リナックスなどはN:Nスレッドだが、サンはSolaris9から1:1スレッド。
　　→Windowsは1:1スレッド？
　　　→1:1スレッドの方がオーバーヘッドが少なく効率的。
　　　　→CPUの数によっても違うので、一概にどちらがよいとは言えない。

■1.3　Risks of threads

　○Integerのアトミック演算子は、言語的には保証されていない。

　○リスト1.1の事象は、シングルCPUでもマルチスレッドで動作させると発生する。
　　→volatileでも防げない。
　　　→synchronizeを使うしかない。

　○ソフトウェア解析ツールとはどのようなものか？
　　→jTestやFindBugsのようなものか？
　　　→アノテーションを利用して、スレッドセーフでないコードを見つけてくれるようなもの？
　　　　→そのようなツールは今は無い。
　　　　　→アプリケーション単位では可能かもしれないが、クラス単位ではスレッドセーフかどうかを見つけるのは困難。

■1.4　Threads are everywhere

　○Javaは起動時からマルチスレッドで動作する（JVMが勝手にスレッドを作る）が、.NETはシングルスレッドで動作する。
　　→ユーザーのスレッドとライブラリのスレッドが擬似的に切り替わるのでは？
　　　→CPUが増えても変わらない？
　　　　→Windows環境下なので、並列処理を必要としていない？

　　→mustangでは、Maxスレッド数で制限される？

　○EJBではスレッド禁止令が出ている？
　　→どちらにしてもスレッドは注意しなくてはならないもの。

　○サーブレットにはシングルスレッドで動作するようにするパラメータがある。
　　→実際に使われることはない。
　　　→JavaEE5からは使用禁止になる？

　○RMIで、同じリモートオブジェクトの同じメソッドが複数のRMIのスレッドから同時に呼び出されることは、SUNは保証していない。

　○Timerは他に比べてやっかいなもの。
　　→Timer（java.util.timer）は、アプリとは別のスレッド上で動いているため、使うならスレッドセーフである必要がある。
　　　→SwingにもTimerがあるが、この章では言及されていない。

　○今後はスレッドを使わない方向も・・。
　　→Tiger以降では、executorを使用する？

■2.1　What is thread safety?

　○アトミックを理解しているJava開発者はどのくらいいるのか？
　　→エンタープライズ系の開発者はトランザクションがあるので、知っているはず。
　　　→実際にはあまりいないだろう。

　○マルチスレッドは、テストすることは出来ない。

　○何故、スレッドセーフというと、まず「状態」なのか？
　　→状態がスレッドで共有されるものだから。
　　　→状態がよりアクセスさせるものだから。

　　→スレッドセーフでいう「状態」とは？

■2.2　Atomicity

　○「state」と出てくれば、概ね保護されるべき状態やフィールドを指す。

　○アンチパターンでは、他の状態にアクセスするメソッドがある場合はアトミックでなくてもいいとある。

　○AtomicLongの実装は、JavaSE6から。

　○AtomicLongは、CPUのネイティブメソッドでどのように対応しているのか？　→【宿題】


■2.3　Locking

　○AtomicDoubleが存在しない。
　　→CPUのレジスタが整数しか扱えないから？

　○カウントがオーバーフローした場合はどうなるのか？　→【宿題】
　　→スタックが先にオーバーフローするのでは？
　　　→C++でPOSIXスレッドを使うと発生する？
　　　　→回避するにはロック取得回数を減らすか、スコープを変更するしかない？

■2.4　Guarding state with locks

　○FindBugsが見つけるsynchronizeのバグとは？
　　→常にsynchronizeされているわけではないもの。

　　（例）時計を表示する
　　　　・時計を進めるスレッドは１つ
　　　　・時計を見るスレッドは全て

　　　　　→この場合、synchronizeである必要はないのでは？

　○同期化されないvectorは？
　　→ArrayList

■2.5　Liveness and performance

　○Livenessの訳は？
　　→developerWorksでは「活性」と訳しているが、ダグ・リー本の訳は「活動性」
　　　→「活動性」とする。

■3.1　Visibility

　○volatile変数は、書き込み時に最初にキャッシュを無効化して書き込みをするために
　　非volatile変数に比べてそれほど早いものではない。

　○synchronize変数よりvolatile変数が早いとは必ずしも言えないが、遅くなる要素はない。


次回、8月19日は、3.2　Publication and escapeより開始。



■訳に注意する単語

　１．Liveness：　　developerWorksでは「活性」と訳しているが、ダグ・リー本の訳は「活動性」
　　　　　　　　　　→「活動性」とする。

　２．interleave：　差し込む、交互に重ねる、割り込み・・
　　　　　　　　　　→うまい訳が見つからないので、そのまま「インターリーブ」とする。

[ 戻る ]