[jfriends-ml 10099] Re: Java 言語で学 ぶデザインパターン入門第 6 回議事録

[Murayama Toshikiyo <murayama@xxxxxxxxxxxxx>]

村山です．

> 3.既にロックを取得している場合は、ロック獲得処理を行なわない。
> という処理の仕方はないのでしょうか?
多分これは，
「3，モニタを一回だけ取得するのは稀だから，一回だけの時が
   若干遅くなっても二回以上の時に最適化してモニタを実装する．」
になると思います．

実際には，どうあがいてもsynchronizedを使った方が使わないより
遅くなりますし，最悪デッドロックを起こすのはご存知のとおり．
しかも二回以上呼び出さないでプログラムをくむのは，さして難しく
ありません．だから「モニタは二回以上取得するのは稀なように
実装すべき」で，その結果「二回以上取得するのは稀である」と
いうことになります．そうすると，ますます「モニタは二回以上
取得するのは稀なように実装すべき」となり，以下同文となるわけ
です．

よって，３の選択肢を取る可能性は低いと思います．
＃「ひねくれた最適化」ってのはこういう意味です．

＃例のページでは他にも結構ひねくれた『最適化』が出ていますが，
＃ひねくれた『最適化』によって本当に高速化するためには，JavaVM
＃作成者の方も同じようにひねくれている必要があります．よほどの
＃場合を除いて，普通に書いた方が良いでしょう．


あ，ちなみに単にロックと言うとOSを使った基本的な排他制御機構
のことを指すと思いますが，グリーンスレッドを使ったJavaVMの
場合は必ずしもロックは使っていないと思います．なんせスレッド
自体がJavaVMレベルで制御されているので，排他制御にOSを呼び出す
必要はないでしょうから．
＃この辺まで来るとかなり推測が入る．仕様書にも載ってないし．

差がほとんど出なかったのもこのためかもしれません．synchronizedが
重いとは言っても，それはあくまでそうでないメソッドに比較しての
話であって，実際にはシングルスレッドで使う限りはそれほど重い
わけではないようです．ただし，マルチスレッドでは細心の注意を払う
必要があるのはご存知の通り．