マルチスレッドによるリソース競合

Java言語の特長は、プログラム内で簡単にマルチスレッドを利用できる点にあります。しかしこれは、いわば諸刃の剣です。なぜなら、マルチスレッド・プログラミングに習熟していないプログラマがスレッドをむやみに利用すると、問題を生じることが多々あるからです。

図1：Glance/gpmによるJavaスレッドのモニタリング

図1は、HP-UXに付属するツールGlance/gpmを利用して、実行中のJVMプロセス内で動作する全てのスレッドを表示した例です。ここでは、JVMが内部的に使用する11のスレッドに加えて、Javaアプリケーションの実行にともない生成された複数のスレッドが表示されています。こうしたスレッドを多用するJavaアプリケーションのプログラミングでは、スレッドを無制限に生成しないよう配慮する必要があります。また、以下の2つのポイントに気をつけなくてはなりません。

【OSの上限数を越えるスレッドを作成しない】
大半のJVMでは、OSのスレッドを利用してJavaスレッドを実装しています。よって、Javaスレッドをあまりに大量に生成すると、OSが定める1プロセスあたりのスレッド数の制限を超えてしまうのです。こうした場合、Javaプログラムの実行中にOutOfMemoryエラーが発生したり、「スレッドが多すぎる」と指摘するメッセージが表示されたりします。

もっとも、この問題への対処は比較的簡単です。HP-UXの場合、HPが提供するツール「HPjconfig」を利用することで、カーネル・パラメータ「max_thread_prod」に設定すべき推奨値を算出できます。この値をもとに、管理ツール「SAM」を利用して同パラメータの変更を行います。HPjconfigは、以下のWebサイトからダウンロードできます。

【ロックを長時間保持しない】
複数のスレッド間でリソースを共有するアプリケーションでは、あるスレッドがリソースのロックを長い間保持してしまうと、他のスレッドの処理が停止してしまいます。この状態をロック競合といいます。ロック競合の起こりやすさは、ロックを獲得しようとするスレッドの数と、獲得の頻度によって決まります。ロック競合が過大に発生すると、スレッドは有意義な作業を進めることができず、ロックの解放待ちに大半の時間を費やしてしまいます。

この2つのうち、Javaのパフォーマンス・チューニングでは、ロック競合の軽減が重要なポイントになります。ロック競合はアプリケーションの設計のまずさに起因して発生するため、設計変更によってその大半は解消できます。そこで以下、このロック競合問題の検出と解決の方法について説明します。

ロック競合問題に対処するための最初の手掛かりは、Glance/gpm の出力より得られます。

図2：CPU時間の割合が示すロック競合の兆候

図2は、Javaアプリケーションによるロック競合が発生している状態でGlance/gpmによる計測を行った例です。これを見れば、ほとんどのCPU時間が青色の「System」（OSコード）によって消費され、紫色の「User」（アプリケーション・コード）の割合が低くなっていることがわかります。しかし本来、Javaアプリケーションの動作が正常であれば、CPU時間の大半をUserが占めていなくてはなりません。これは、ロック競合の多発を示すひとつの指標となります。

ここで再びGlance/gpmを利用し、JVMプロセスによって呼ばれているシステム・コールを観察してみます。

図3：ロック競合を示すシステム・コールの呼び出し回数

ここでは、「Cumulative system call count」の項目に注目します。すると、「sched_yield」や「ksleep」、「kwakeup」などの特定のシステム・コールがかなりの頻度で呼び出されていることが分かります。また、これらに比較して、図3の矢印で示される「send」と「recv」の呼び出し回数はかなり低くなっています。この2つのシステム・コールは、Javaアプリケーションのネットワーク処理を司るため、本来であればもっと高い頻度で呼び出されなくてはなりません。つまり、アプリケーション設計の不具合によるロック競合の影響で、呼び出される回数が低く抑えられているのです。

ちなみに、ネットワーク機能を利用するJavaアプリケーションでは、図3のような状況がしばしば発生します。その原因は、ネットワーク・コネクションのオープンにともなうスレッドの大量生成にあります。つまり、数百や数千といった多数のTCPソケットをオープンすると、同じ数だけスレッドが生成されてしまい、オーバーヘッドがきわめて高くなってしまうのです。この問題は、JDK 1.4で導入された非同期I/Oの利用により、スレッド数を減らすことで解決できます。ただし、本連載の範囲を超えるため、その詳細については省略します。

まずは、以下のコマンドを実行し、JVMプロセスのプロセスIDを特定します。

つづいて、以下のコマンドを実行し、JVMプロセス対してSIGQUITシグナルを送ります（コマンドの実行にはスーパーユーザー権限が必要な場合もあります）。

これにより、標準出力に以下のようなスタックトレースが出力されます。場合によっては大量のスタックトレースが表示されるため、そのときはJVMの起動時に標準出力からファイルへのリダイレクトを指定しておけばよいでしょう。

この例では、あるスレッドがスリープ状態にあり、オブジェクトのロックの解放を待ち続けている様子が示されています。こうしたスタックトレースを調べていくことで、ロックを長時間保持しているスレッドを見つけ出し、JVM全体のスローダウンの原因を突き止めることができます。

HP JVMにおけるこうしたスタックトレース解析の欠点は、多数のスレッドを含むJavaアプリケーションにおいて大量のスタックトレースが生成されてしまうことです。その出力を綿密にチェックしていくのは非常な労力を要します。そこで、こうした作業を簡素化するために、次に紹介するHPjmeterを合わせて利用します。

内容に関するご意見・ご質問・お問い合わせ