Webアプリの性能やメモリ関連の問題を、コーディング時に回避：Java Review（1/2 ページ）

アプリケーションの“作り”が悪いと、Webシステムの運用時に性能やメモリ関連の問題が発生する原因となる。今回は、Javaアプリケーション作成時に留意しておくべき基本的なポイントについて紹介する。

[友成文隆（日立製作所），ITmedia]

　性能やメモリ関連で問題が発生した場合に、原因を判別するのは非常に骨が折れる作業だ。これらの問題を回避するためにも、基本的なことであるが、Javaアプリケーション開発時に次の2点は必ず配慮しておこう。

1. 適切なAPIを使用しているか？
2. 不要なオブジェクトを生成していないか？

　また、アプリケーションの処理がシステムに対して間接的に影響を及ぼすこともある。今回はこういった事例についても紹介する。

適切なAPIを使用しているか？

　コーディング上で性能問題の要因を発生させないようにするには、適切なAPIを使用する必要がある。ここでは、コレクション関連と文字列連結の処理を例に、コーディング時の注意点について説明する。

　まず、コレクション関連の処理の見直しだ。基本的なことだが、コレクションがマルチスレッドからアクセスされるかどうかを考え、非同期用のコレクションと同期用のコレクションを使い分けよう。同期処理が不要な個所で同期化の処理をすると、そのコストが積み重なって性能劣化につながることがある。

　また、同期化の処理をコーディングする際には、適切なAPIが使用されているかを確認しよう。例えば、同期されるハッシュテーブルの機能のAPIとして、JDK 1.0で提供されたjava.util.Hashtableがあるが、JDK 1.2でjava.util.HashMapやjava.util.Collectionsパッケージが提供されている。HashMapクラスに対してアプリケーション側で同期を取るか、Collections.synchronizedMapメソッドの利用によって、同様の機能を実現できる。

　さらにJDK 5.0では、java.util.concurrentパッケージが提供されている。このパッケージで提供されているConcurrentHashMapクラスなどは、従来より性能面で改善されているため、JDK 1.2のクラスを使用するよりも処理が速くなる。ただし、ConcurrentHashMapクラスなどに変更する場合は、変更前のAPIと仕様差がないかを確認する必要がある。例えば、コネクションからイテレータを作成したあとにデータが更新された場合の挙動がCollections.synchronizedMapメソッドの場合とConcurrentHashMapクラスの場合で異なるなど、細かいレベルで仕様差がある（Collections.synchronizedMapの場合は例外を返し、ConcurrentHashMapの場合は例外は返さない）。このため、安易にクラスを置き換えないよう注意しよう。

　より新しいAPIへの変更はリスクもあるが、性能改善やコーディングの利便性などの向上が見込まれるケースもあるので、APIの変更を検討すると良いだろう。

　次に、文字列連結の処理の見直しについて説明する。文字列連結で使用するクラスには、StringBufferクラスと、JDK 5.0で追加されたStringBuilderクラスがある。これらのクラスは同じ振る舞いをするが、次の表に示すような特徴がある。

クラス名	特徴
StringBuilderクラス	非同期で文字列連結処理をするクラス。非同期で処理するため、処理速度が上がる。
StringBufferクラス	同期化して文字列連結処理をするクラス。同期を取れるが、同期化処理の分だけコストが掛かる。

　例として、ログ出力時の処理でStringBufferクラスを使用して多数の文字列連結をしている場合について説明しよう。この処理の場合、同期化が必要か、という観点で見直す。StringBufferクラスは同期化のクラスであるため、もし、ログ出力処理で文字列オブジェクトをスレッド間で共有しないのなら、同期化処理のコストは不要だ。このような場合は、StringBufferクラスではなくStringBuilderクラスを使用してみよう。

　また、文字列連結時に、単純に“+”演算子で頻繁に文字列を連結する操作をしていると、一時オブジェクトとしてStringBuilderクラスのオブジェクトが大量に発生されることがある。これは、GC多発の原因となり、Webシステムのレスポンス低下につながる。適切なAPIを使用することが、メモリ使用量の改善という意味でもWebシステムの安定につながることも覚えておこう。