読書会(JAVA CONCURRENCY IN PRACTICE)第5回議事録
[ 戻る ]
Java Concurrency In Practice 第5回議事録
日時:
11月11日 10:00-17:00
場所:
高津市 高津市民館 第４会議室
出席者(敬称略):
高橋智宏 7.1〜7.1.1
小松 正利 7.4 JVM shutdown
村山敏清 7.1.2〜7.1.4
門脇 太郎(欠席) 8.1
遠藤康裕 7.1.5〜7.1.7
吉本 博之 7.2〜7.2.2
高橋徹 7.2.3〜7.2.5
大石将邦 7.3
岡澤裕二 書記
岩室 元典
岩永 昌寛
鈴木和佳子
根本和郎
中島
宿題:
Thread.sleep() や Thread.stop() が deprecated になったのはいつからか?
Socket.read() が 0 を返すことはあるのか?
訳語について:
cancellation
-> キャンセル
problem space
-> 問題空間
gracefull shutdown
-> 日本語になってない?
protocol
-> 規約，手順
sticky
-> 貼り付く，まとわりつく
cancellation point
-> キャンセルポイント
7 Cancellation and Shutdown
7.1 Task Cancellation
7.1.1 Interruption (pp. 135):
List 7.2:
SECONDS って何？
-> サンプルコードを参照
http://www.javaconcurrencyinpractice.com/listings/PrimeGenerator.java
>> import static java.util.concurrent.TimeUnit.SECONDS;
List 7.3:
キューがブロックしてしまって先に進めなくなる例
タネンバウム本にも「リソース枯渇」として出ていたかもしれない
-> 参考文献 「」
ブロックされてないときに割り込まれたらどうなる?:
-> 割り込まれたことは記録される
-> Thread.isInterrupted() でポーリングする
queue.put() が重いとは思えないので，先に進めなくなることは無いのではないか?:
-> p.nextProbablePrime() が重いから
-> p.nextProbablePrime() がブロッキングメソッドだとクールだ
AOP で全部のメソッドが InterruptedException を投げるようにできないか?:
今の AOP ではできない
-> コンテキストが分からないから
-> パフォーマンス的にも問題があるのでは
Java の volatile は重すぎる:
軽い volatile とは?:
-> メモリバリアがない volatile
-> Linux とかでは使い分けてる
Java 6 ではコード最適化によって，volatile の必要性を判断するようになる
List 7.5:
サーバ VM でうまく動かなかった:
-> [jfriends-ml 12430] Re: SharedCounter の実験 (1) - 再送
-> ベンチマークが単純なせいで，コード最適化されてる可能性もある
7.1.2 Interruption policies (pp. 141):
JDBC でトランザクションをコミットしてる間に割り込まれたらどうなる?:
-> ドライバ依存ではある
-> 普通は中途半端な状態で InterruptedException をスローすることはない
CPU の割り込みとは違うから，何もしなければ何も起きないのではないか?:
-> 仕様化されていない (実際上は問題ないはず)
-> 割り込まれてもコミットが完了することを保証してほしい
7.1.3 Responding to interruption (pp. 142):
List 7.7:
java.util.concurrent の実装に同じようなコードがあった (ReentrantRock ??)
「途中で記録した割り込みステータスを finally で復元する」メソッド
7.1.4 Examplle: timed run (pp. 144):
List 7.8:
非チェック例外を扱えないことを問題にしている
いちおう問題は解決している
キャンセルポリシー上はルール違反，というのが新たな問題
List 7.9:
List 7.8 のルール違反は解決している
taskThread.join() が成功したかどうか分からないというのは問題では?:
taskThread が終了したのか，タイムアウトしたのか分からない
Thread.join() の返り値:
void より boolean のほうが使いやすいのではないか?:
-> シグネチャが変わるからバイナリ互換性がなくなってしまう
-> メソッドを新設するのは可能
例外の追加は?:
-> ソース互換性がなくなってしまう
64 bit 対応の JVM:
SUN JVM 1.3 系，1.4 系は対応してない
IBM Java は対応している
Solaris 10 とか
ヒープサイズ，ファイルサイズにしかメリットがない?
計算機リソースの中心は 64 bit になってきている
1 つのプロセスでスレッドがんがん作れる
-> うれしい?
7.1.5 Cancellation via Future (pp.145):
List 7.10:
finally で task.cancel() している:
-> タスクが終わった後ならキャンセルしても無視されるから
7.1.6 Dealing with non-interruptible blocking (pp. 147):
本文中 (pp. 148) に errata あり
>> java.nio.channels), wakeup causes it to return permaturely by throwing a ...
^^^^^^
close
List 7.11:
オーバーライドして，ソケットをクローズするようにしてる
-> Thread.interrupt() は final じゃない
7.1.7 Encapsulating nonstandard cancellation with newTaskFor (pp. 148):
List 7.12:
なぜ SocketUsingTask.this.cancel() ?:
-> ただの this だと無名クラス自身になってしまうから，エンクロージングクラス名を付けている
CancellableTask には cancel() と newTask() があるが冗長なのでは?:
SocketUsingTask.this.cancel
を
(CancellableTask
にすれば取り除ける
List 7.11 との違いは?:
-> 新しい標準に従った方法
-> Thread.interrupt() をオーバーロードするといったトリックを使わなくてもよい
-> JDBCUsingTask とかも欲しい
ジェネリックメソッドの書き方:
-> 印刷ミス
-> スコープ指定と
× protected
○ protected
java.io.Closable:
J2SE 1.5 で追加されたインターフェース
close を提供してる
ほとんどのストリームが実装している
java.io.DatagraSocket は実装してない
-> 忘れてる?
JDBC も実装してない
アノテーションあれこれ:
GurardedBy アノテーションで自動的に synchronized とかしてくれるとうれしい?:
-> 今後はツールでできるようになるかも？
Nullable も欲しい:
null を返すかどうか
参考:
IntelliJ IDEA には用意されているようです
Findbugs も対応していたようです (jcip.annotations にも対応とか)
.NET Framework の Nullable
Ready for Vista:
現在対応してるのは Java 6 だけ
Vista が出荷されたらそれ以前は捨てられることに
7.2 Stopping a thread-based service
7.2.1 Example: a logging service (pp. 150):
インターリーブ:
PrintWriter.println() に渡した文字列は，そのとおりに出力される (はず)
7.2.2 ExecutorService shutdown (pp. 153):
7.2.3 Poison pills (pp. 155):
毒薬条項パターン:
番兵のようなもの?:
-> 少し違う
List 7.18:
実質 2 行しかないのにコード量が多すぎ
通常リターンでも例外リターンでも，割り込みを考えて try catch している:
-> ポイズンを必ず入れるため
IndexerThread だけが死んだらどうなる?:
-> IndexerThread がいなくなっても CrawlerThread はひたすら動き続ける:
- キューが満杯になると queue.put() でブロックすっる
-> IndexerThread が CrawlerThread を止めないといけない
-> CrawlerThread.run() は割り込みされれば finaly に移行する:
- IndexerThread.run() の finally で CrawlerThread に interrupt をかければよいか
-> CrawlerThread.run() は POISON を put できたら終了する
- IndexerThread.run() の finally でキューが空になるまで take し続ければよいか
密結合すぎるのではないか??:
-> ひとつ上のレベルの IndexingService が管理すべき
キューの問題:
-> 完全な正解はない
-> ケースバイケース，トレードオフ
複数の生産者がいるとき，生産者と同じ数のポイズンが入れられるという保証はできるか?:
-> そういう決まりごとがあるだけで保証はしてない
N 生産者，N 消費者問題:
-> 生産者が死ぬとき，消費者と同じ数のポイズンを投入する
-> 消費者が死ぬとき，1 つのポイズンを取得する
-> ポイズンを確実に消費者に渡せる仕組があればよい
7.2.4 Example: a one-shot execution service (pp. 156)
List 7.20:
exec.shutdown() の意味は?:
-> これ以上タスクを投入できないようにする
7.2.5 Limitations of shutdownNow (pp. 158)
List 7.21:
isShutdown() の定義は?:
-> サンプルコードを参照
http://www.javaconcurrencyinpractice.com/listings/TrackingExecutor.java
>> public boolean isShutdown() {
>> return exec.isShutdown();
>> }
7.3 Handling abnormal thread termination (pp. 161):
List 7.23:
なぜ Throwable を使うのか?:
-> Throwable は例外クラスの一番上位にあるので Error も Exeception も拾えるから
7.3.1 Uncaught exception handlers (pp. 162):
UncaughtExceptionHandler インタフェース:
-> 元々 ThreadGroup に同名のメソッドがあった
-> J2SE 1.5 からインターフェースとして切り出されたので，カスタマイズできるようになった
-> 以前の ThreadGroup.uncaughtException() をオーバーライドしたコードはそのまま使える
ThreadGroup は何に使うのか?:
-> ミドルウェアの実装には必要
-> プロファイリングツーなどで分かりやすいように独自の名前体系を付ける，など
7.4 JVM shutdown (pp. 164)
7.4.1 Shutdown hooks (pp. 164)
シャットダウンフックが呼ばれるためにはどうすれば?:
-> System.exit() を呼ぶ
-> SIGINT を送る
-> [jfriends-ml 12540] java のプログラムを Ctrl+C で止める
7.4.2 Daemon threads (pp. 165)
7.4.3 Finalizers (pp. 165)
Boehm, 2005 の資料:
参考文献に載っています
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3281.pdf
[ 戻る ]