- - PR -
Vector/ArrayList と Hashtable/HashMap の使い分け
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2002-09-24 15:52
>仮に「MT上でのデータ保護が完全だが、ちょっと動作が重いクラス(データ構造)」
同期は,本質的に全てボトルネックです. #実用上問題のあるものとないものという違いはありますが. #問題のある同期を避けるのも,プログラマーの仕事の一部. >「どのオブジェクトをどのくらいロックしているか」をプログラマ(設計者)が >自覚していることが必要なのではないでしょうか。 ....... そんなの当たり前だと思ってたんですが. 同期を全て把握してないと,最低限の動作さえ保証されません. また,同期関係のバグは再現性が低いため,ためしに実行してみても 発見することさえ困難です.またデバッガを使うと発生しなくなる 場合もあります. >ロックを意識するのは手間ですが、それをあえて強いることによって >構造的に「変、無駄」なプログラムをレビュー段階で排除(/修正)出来る >という利点があるかと思います。 マルチスレッド環境では,ロックを意識してないようでは, プログラマー失格でしょう.そもそも同期というのはアルゴリズムの 一部,というより骨格部分であり,それを無視していてはアルゴリズム が設計できませんし,プログラムも作成できません. #「同期のことはよく解らないけれど,プログラムは完成した」なんて #言ってる人がいたら見てみたい. |
|
投稿日時: 2002-09-24 18:02
>#「同期のことはよく解らないけれど,プログラムは完成した」なんて
>#言ってる人がいたら見てみたい. 実際すごくたくさんいると思います。 これはコンピュータサイエンスの基本ではありますが、 入社していきなり研修でJavaをやって仕事についた場合、その辺の 理解がごっそり抜けているという場合は多々あるんじゃないでしょうか。 自分で学んでおくべきことだとは思いますが、 初心者向けをうたうJava教本でも、少なくともその辺の注意を 喚起すべきなんだと思います。 「初心者」がいきなり仕事でプログラムを書いてしまう という現状を鑑みるに。 自戒をこめて書いてみました。 |
|
投稿日時: 2002-09-24 23:12
あるテーブルから別のテーブルにデータを移すという処理を作っていたのですが、
コーディングとしては、1レコードをVectorに保存し、そのVectorをVectorに追加する、というようにしていたのですが、ある量までいくと必ずOut of Memoryで終わってしまいました。 初期サイズや増減値を変更しても同じで、結局、1レコードはVectorでそれを追加するのはArrayListに変更したら、Out of Memoryが発生しなくなりました。 その結果、ArrayListのほうがメモリ管理がうまいのかなとも思っていました。 スレッドの内容とズレてしまっていたら、申し訳ないです。 |
|
投稿日時: 2002-09-24 23:30
>>#「同期のことはよく解らないけれど,プログラムは完成した」なんて
>>#言ってる人がいたら見てみたい. > 実際すごくたくさんいると思います。 > これはコンピュータサイエンスの基本ではありますが、 > 入社していきなり研修でJavaをやって仕事についた場合、その辺の > 理解がごっそり抜けているという場合は多々あるんじゃないでしょうか。 > 「初心者」がいきなり仕事でプログラムを書いてしまう > という現状を鑑みるに。 私も自戒を込めて。 # まだ理解しきれてないのが痛いな…。修行しよう。 某大手にて、本番稼働中の JSP で static な int i をループ変数に使ってるのを 発見して愕然としたことがあります:( が、現実はそんなもんなのかもとも思ったり。 JSP だと Java であることさえ考えずに PHP みたいな気分でやられちゃうときがありますし…。 逆に「Java できます」の判定材料にできそうですね、これは。:) # は〜、できますなんて言えなくなっちゃうなぁ(わ --- しかし、といってはなんなのですが、たとえば一般的な Web / App / DB 構成のとき、App 部分の Vector / Hashtable (あるいは類するもの)の非並行性が主な原因がとなるような場合というのは、実は多くない気もします。 ふつうは、「受ける->計算->格納-|->DB-|->格納->出力」で、科学計算か画像処理系でもない限り格納/DBアクセスのオーダーはあまり変わらないでしょうから、実は DB のほうが早く逝っちゃうのではないですかね。 # だから Vector でもいいじゃん、と言っているのではありません。あしからず。 |
|
投稿日時: 2002-09-24 23:41
あ。面白そうですね。。。
(前後の脈絡をあまり読まずに割り込みました。すみません。) プログラムの動作環境を考慮に入れる必要があると思います。 スレッドの数、動作環境の能力(CPUやらメモリやらキャッシュやら)、DBなら排他制御の範囲、コネクションプール関連の設定などなど…。 チューニングの経験が無いと、 え゛!??…ウソでしょ!??? というコトがまま有ります。 VectorにせよHashtableにせよ、チューニング本の基本は押さえつつ、やはり負荷テストして欲しいなぁ、と思う今日この頃です。 (ツールによっては負荷がかからなかったりするのは、頭の痛い話ですが…使い方がイマイチなのかもしれません。) 負荷がかかっていない時はなーんとも無いプログラムが、負荷の増加に伴ってボトルネックと化すタイミングや、データ量の"境界"、同時に動作するプログラム(主に通信系ですが)との遣り取り上の限界、と言えるようなポイントが必ずあるはずです。 もちろんこれはいわゆるミッションクリティカル系のシステムの話なので、デスクトップでのテストの場合は、もう少し大目に見ても良いのかもしれません。 でも、テスト中に自分の開発したPGがどの程度持ち堪えれば良いの? という視点は、持っていたい!!持って欲しい!です。 |
