スレッドセーフ？

スレッドセーフとは

http://e-words.jp/w/E382B9E383ACE38383E38389E382BBE383BCE38395.html

スレッドセーフができていないというのは

同じインスタンスにある同じ変数を
複数のスレッドが参照・更新できる場合や、
共有ファイルを複数人で参照・更新できる場合
のこと。

例えば

下記コードがあった場合、

 private int num;

 public int getNum(){
 　　return num;
 }

 public void setNum(int なむ){
 　　num = なむ;
 }

 public void update(){
 　　System.out.println(num); //-----(1)
 　　int i;                   
 　　for(i=0; i < num; i++);  //-----(2)
 　　System.out.println(i);
 }

• 正常
  

1. スレッドA　が　Hoge.setNum(10000);実行
2. スレッドA　が　Hoge.update();実行

　　　　　コンソールに表示される結果は下記となる。
　　　　　　10000
　　　　　　10000

• 異常

1. スレッドA　が　Hoge.setNum(10000);実行
2. スレッドA　が　Hoge.update();実行
3. 「２．」実行中にスレッドBがHoge.setNum(500);実行

　　　　　コンソールに表示される結果はだれにも予想できないが、
　　　　　おそらく下記のような結果となる。

　　　　　(1)の直前で「３．」が実行された場合の結果は
　　　　　　500
　　　　　　500

　　　　　(2)の直前で「３．」が実行された場合の結果は
　　　　　　10000
　　　　　　500

　　　　　(2)を実行中に「３．」が実行された場合の結果は
　　　　　　10000
　　　　　　"500～10000のいずれか"

対処方法

各メソッドにsynchonized装飾子をつけてあげればとりあえずは防げる。

詳しくは下記

http://d.hatena.ne.jp/amachang/20100324/1269425706
http://www.ibm.com/developerworks/jp/java/library/j-threadsafe/

対応内容は資料化してみる

webサイトの保守を行う以上、
何かしらの改修・追加開発依頼が発生します。

そんなとき、
依頼者と対応者の間で対応内容の認識にズレがあると
対応中または対応完了後に面倒事になる。

ので、ズレを起こさないように
予め色々資料化して確認しておこうよという話。

web開発？を例に下記に並べてみました。

１．対応箇所の確認

• 対応画面のURL
• 具体的に修正箇所がどこなのか画面をキャプチャして示す

２．対応内容の確認

• 何をしたら、どんな動きをするのか例を挙げて示す
• DBの場合、どのパラメタを、どう変更したら、何がおきるのか
• APIも同様

３．対応範囲の確認(マルチベンダの場合とか特に)

• 対応範囲の切り分けを明確にしておく

４．対応スケジュールの確認(マルチベンダの場合とか特に)

• スケジュール(全社分)を引く
• (厳しそうならご指摘くださいと伝えること)
• (Aが終わらないと、Bができない場合だとしても、Bが遅れたらBの対応者が責められるかも)
• (全社分確認を取れたら依頼者に報告)

５．対応結果の確認

• 具体的にこう操作したら、こうなります的な一覧を作る
• 対応内容の確認に近い
• 要はテスト項目書

つぎに資料化することのメリット・デメリットをそれぞれ挙げてみます。

メリット

• 依頼者との認識違いを減らすことができる
• 予め依頼者と具体的な対応内容を確認しておくことで仕様を握ることができる
• 対応内容を自分自身で整理できる
• 整理ついでにメンバーに対応内容が共有できる
• 時間が経っても(後から参加した人でも)対応内容を確認できる

デメリット

• ちょっと手間

当然対応内容の規模によっては、
すべてを行う必要はないと思います。
けーすばいけーす。

みなさんはどですか。