コードレビューの視点 003

マルチスレッドプログラミングに注意する

Javaが登場する前は、C/C++でマルチスレッドプログラミングをしようとすると、別途POSIX Threadなどのライブラリを使用しなければなりませんでした。Javaは言語仕様そのものにマルチスレッドプログラミングの機構を持っています。しかし、マルチスレッドプログラミングというのは、同期も含めて正しく設計・実装するのは難易度が高い領域です。

そのため、同期処理も含めてかなり真剣にレビューしないといけません。さらに残念ながらレビューだけでは不十分であり、ストレステストも必要になってきます。そのため、マルチスレッドプログラミングを行うソフトウェア開発では、次のことが必須となります。

• マルチスレッドプログラミングに関する基礎知識をすべてのソフトウェアエンジニアがきちんと習得していること
• 書かれたコードは、マルチスレッドプログラミングに関する豊富な知識と経験を持つ人がきちんとレビューをする
• 書かれたコードは、自動テストが実行できるようになっていて、様々なプラットフォーム（単一コアから複数コア、あるいは、マルチプロセッサー）で長時間ランニングテストを行う。さらに、同時にシステムに別の負荷（CPU、HDなどへの負荷）をかけたランニングテストも行う

多数のプロセスが協調し、個々のプロセス内では多数のスレッドが動作するという大規模なマルチスレッドプログラミングを行うプロジェクトに従事したことがあります。その時は、何十台という様々なPCで夜間にランニングテストを繰り返していました。そして、朝出社してテストが停止していると最優先でデバッグを行います。

ある朝、停止しているテストを私も含めて数名でデバッグしていたのですが、そのバグはコードレビューでは到底見つけられないような非常に複雑な状態の時に発生するというものでした。そして、その発生原因となったコードの修正がいつ入れられたのかを調査したら、3ヶ月前のことでした。つまり、そのバグは、3ヶ月間の膨大なランニングテストをすり抜けたことになります。

マルチスレッドプログラミングの難しさは、「1回動作したから正しいという保証もないし、100回動作したから正しいという保証もない」ことです。そのため上記の3条件がそろった開発が必須となります。上記の3条件が全くそろっていないソフトウェア開発では、品質が安定することはなく、最後にはプロジェクトがキャンセルさせられるか、あるいは、製品として無理にリリースしてもその後の障害対応に膨大な工数が必要となります。

マルチスレッドプログラミングに関する基礎知識を持たない人が書いたコードは、動作させなくても（私が）コードを見ただけで問題があるのが分かることがほとんどです。そして、基本知識もない人が書いて、かつ、まともにレビューもされていないことも分かってがっかりすることが多いです。