将来きっと、今よりもマルチスレッドのプログラミングについて理解しているだろう。そうありたい。だから、勉強を始めたばかりの頃の考察をあえて残す。内容については一切保証しない。キーワードは安全性、生存性、再利用性、パフォーマンスだ。

• 問題12-1 （評価基準の適用）

  本章で述べた評価基準を考慮し、次の発言について自由に考察してください。

  1. メソッドには機械的にsynchronizedをつけておけば「よい」だろう。

     機械的にsynchronizedを付けた場合、安全性は向上すると思われる。しかし、生存性は必ずしも保証できない。また、一つのインスタンスで利用できるメソッドを一つに限定した場合、応答性が低下することが考えられる。また、キャパシティも大幅に低下すると考えられる。

  2. synchronizedメソッドの中で無限ループになっているじゃないか。これは「悪い」プログラムだな。

     無限ループになっていても、ループの離脱条件がきちんと記述されていれば問題はない。されていなかったとしても、安全性や生存性に直接影響する事柄ではないと思われる。だいたい、ゲームのメインスレッドは無限ループがよいのではないだろうか。

  3. プログラムのミスで、無限ループに入るだけのスレッドを100個も起動してしまった。でも、スレッドはただループしているだけだから、まあ「よい」だろう。

     パフォーマンスの大幅な低下が考えられる。意味がないのであれば、処理は最小限にとどめるのが理想だろう。

  4. このサーバには同時に1つのクライアントしか接続できないんですか。もっと「よい」サーバにしてください。

     厳密な安全性と生存性を求めるのならば最良の方法だ。堅牢なサーバを運営するのならばよい方法ではないだろうか。しかし、パフォーマンスはよくない。多少の停止を許容するサーバであればパフォーマンスを優先するのもいいだろう。例えばラグナロクオンラインのサーバは、ときどきダウンしたとしても、顧客は調教済みだから問題ない。それよりも普段のパフォーマンスを向上させて、少しでも日常の不満を解消するのがよいだろう。

  5. なんて「悪い」検索プログラムだ。いったん開始したら全部検索し終わるまでキャンセルできないじゃないか。

     応答性は悪いが、安全性と生存性を安易に確保できる方法だ。再利用性は高くないだろう。

  6. このままだと、クラスAとクラスBの両方が、スレッドの排他制御を意識していることになって「よくない」かな。

     再利用を考えるのが面倒だろう。しかし、安全性と生存性を確保するためにやむを得ないのならば避けるべきではない。

ちょっと検証にかけてみたのだが、どうやらエンコード方式が問題らしい。サーバからエンコード方式はx-euc-jpだと送られているようだ。これでは仕方がないか…。