[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 10833] マルチスレッド での「チューニング」 (Re: DecimalFormat とかもスレッ ドセーフではない?)



村山@NETGENEです.

> フォーマット系のクラスをFactoryかユーティリティにしといて、
> あとで、パフォーマンスのボトルネックになったときに、
> 他に影響なく直せるようにしておくくらいでしょうか。

少し外れますが,マルチスレッドの同期周りでは「パフォーマンス
チューニング」の意味が少し違ってるような気がしています.

パフォーマンスチューニングにおいては,
1,まず設計上綺麗な/良い設計の方法で実装する.
2,それで性能が出なければチューニング作業に入る.
ですよね.

マルチスレッドでも,この点は同じはずなんですが,
時として次のようなやり方をしてる人がいるんじゃないでしょうか.
#恐ろしいことに.
1,まず正しく動作するように(同期を取りながら)実装する.
2,それで性能がでなければ,(同期を取り除く形で)チューニング作業に入る.

もしこういうやり方をしている人がいるとすれば,多分,それは間違いだと
思います.同期というのは,追加することはできても取り除くことは一般には
できないものです.

どちらかというと,次のような感じにすべきです.

1,まず,設計上綺麗な/良い設計の方法で,
(即ち可能な限り,或いは一切同期を使わずに)実装する.
#例えば不変オブジェクトなんてのは,典型的なこのパターンです.

2,それで性能が出なければ,チューニング作業に入る.
その仮定で,もし必要とあればオブジェクトの共有やvolatile宣言,
synchronized宣言などを追加する場合もある.
#例えばStringで実装してた所をStringBufferに変えるのがこのパターン.

マルチスレッドでも,綺麗な設計であれば同期はほとんど必要ありません.
#というより,同期が必要ないことが綺麗な設計の指標というべきか.

「synchronizedメソッドは遅い」という偏見があったために,パフォーマンス
チューニングといえば「同期を外す」というイメージがあるかも知れませんが,
(気のせいなら良いのですがね,)どちらかというとチューニングは
「同期を追加するものだ」と考えるべきだと思います.

> いやー、実はうちはデュアルなんですよー。
> なわけはない。
#Cerelon300Aのデュアルマシンが生き残ってたら....(^^;

-- 
村山敏清 株式会社ネットジーン 〒164-0001 
東京都中野区中野3-33-3 インツ中野ビル 5F
E-mail:murayama@xxxxxxxxxxxxx 
TEL:(03)5328-3670 FAX:(03)5328-3673
http://www.netgene.co.jp/