HashMapからConcurrentHashMapへの移行

Size: px

Start display at page:

Download "HashMapからConcurrentHashMapへの移行"

たみじろうみやまる
5 years ago
Views:

1 HashMap から ConcurrentHashMap への移行レガシーアプリケーションにおける注意点 2012 年 1 月 4 日橋口雅史 1. はじめにアプリケーションではキーと値のマッピングが多用されます例えばユーザー名というキーにユーザーの情報をマッピングするといった用途で java.util.map インタフェースは広く使われています特にハッシュテーブルに基づいて高速にマップを検索更新できる java.util.hashmap クラスは様々なアプリケーションでよく使われています HashMap クラスの同期化はプログラマーが考慮する必要があります残念ながら正しく HashMap クラスが使われていないアプリケーションは数多く存在しますそして同期処理の誤りが原因で発生するトラブルは原因究明が難しくシステム運用者を悩ませてきました本書では HashMap を java.util.concurrent.concurrenthashmap に置き換えてシステムを安定稼働させるアイデアを紹介します後述しますが ConcurrentHashMap は安全に使える高速なハッシュテーブル実装です 2. HashMapが引き起こすトラブル API 仕様に明記されているように HashMap クラスは同期化されません複数のスレッドが並行して HashMap にアクセスしそれらのスレッドの少なくともひとつが構造的にマップを変更する場合には外部で同期をとる必要があります適切な同期処理を実装しない場合ハッシュテーブルの破壊や無限ループメモリリークといった深刻な問題を引き起こすことがあります例えばある企業の情報システムでは原因不明のメモリリークによるスローダウンが発生していましたまたメモリがリークしつづけた結果最終的には OutOfMemoryError によるシステムダウンを引き起こしていました事象はある日突然発生するため確実に再現させられず原因を特定するのが非常に困難でした 5 ヶ月間の調査の結果システムを構成するアプリケーションが使用する HashMap のデータ構造が破壊されていたことが分かりました破壊の理由は HashMap の同期処理の誤りでしたデータ構造が破壊されたことによりテーブルを正しく更新できずメモリリーク発生に繋がっていたことが分かりましたたった 1 行の同期処理の誤りが何ヶ月も続くトラブルを引き起こしていたのですまた原因が判明するまでのあいだ担当者は常にシステムを監視する必要があり多大なコストを払う結果となりました 3. 安全な Hashtableと使い方が難しい HashMap ハッシュテーブルを実装するクラスとしては Java の誕生当初から java.util.hashtable が存在します 1

2 Hashtable のほとんどのメソッドには synchronized 修飾子が指定されているため外部で同期を取らなくとも複数のスレッドによる並行アクセスが理由でハッシュテーブルが破壊されることはありませんただメソッドに synchronized 修飾子が指定されているためハッシュテーブルにアクセスするたびに同期処理が走ります同期処理は実行コストが高いため性能に影響しますそこで性能を重視する多くのプログラマーは Hashtable ではなく HashMap を使ってきましたそして同期処理の工夫によって性能上の利点とアプリケーションの安全な動作を両立させようとしてきましたしかし冒頭で述べたように実際には少なくないバグが混入し思いがけない動作を引き起こしてシステム管理者を悩ませ続けていますこのように安全な Hashtable と使い方が難しい HashMap のどちらを使うべきか多くのプログラマーが選択を迫られてきたのです 4. 新しい HashMap の登場 J2SE 5.0 で導入された ConcurrentHashMap クラスは安全性に関する Hashtable の特長と性能に関する HashMap の利点を兼ね備えています図 1は Hashtableにアクセスするアプリケーションスレッドの挙動を模式化したものです Hashtable にアクセスできるスレッドは常に 1 個でありそれ以外のスレッドはそのアクセスが終わるまで待たされます図 1 Hashtable へのアクセスアプリケーションスレッド同じテーブルへのアクセス要求テーブルに同時にアクセスできるスレッドは 1 個だけですそのスレッドがアクセスしているあいだほかのスレッドは待たされます動作中アクセス中待ち状態図 2は HashMapにアクセスするアプリケーションスレッドを表したものですどのスレッドも自由に HashMapにアクセスできますそのため HashMapへのアクセスを適切に同期化していないアプリケーションはテーブルを破壊する恐れがあります 2

3 図 2 HashMap へのアクセスアプリケーションスレッド同じテーブルへのアクセス要求あるスレッドがテーブルにアクセスしているあいだもほかのスレッドはテーブルにアクセスできますそのため適切に同期化していないアプリケーションではテーブルが破壊されることがあります動作中アクセス中待ち状態 ConcurrentHashMap クラスは機能仕様は Hashtable と同じでありながらアクセスのたびにロックするようなことがありません通常は複数のスレッドが同時にアクセスできます同時にアクセスするとテーブルが破壊されるような場合には自動的に同期化しますそのときの待ち時間は非常に短くなるよう実装されています図 3 ConcurrentHashMap へのアクセスアプリケーションスレッド同じテーブルへのアクセス要求多くの場合は複数のスレッドが同時にアクセスできますその際テーブルが壊れることはありませんアクセスを待たされることもありますがその時間は非常に短くなっています動作中アクセス中待ち状態そこで ConcurrentHashMap の性能をプログラムで検証してみます使用したプログラムは 100,000 個の Integer オブジェクトからランダムに選んだものをキーとして get メソッドでマップに問い合わせますマップにエントリーが存在しない場合は put メソッドを呼び出してそのキーに対する値を登録します各スレッドがこれを 1,000,000 回繰り返し各スレッドの実行時間を合計して比較します Linux 64bit (Intel64) の環境で Java SE 6 を使って調べました表 1 から分かるようにスレッド数が多くなるにつれて実行時間の差が大きくなっていきます 3

4 ConcurrentHashMapを使う場合同じマップにアクセスするスレッド数が増えても大幅な性能低下を示すことはありません今回使用したテストプログラムは get と put の両方を呼び出すため HashMap との単純な比較はできませんでしたしかし HashMap にアクセスするときに同期処理を実行するようなプログラムでは Hashtable と同様の結果を示すものと考えられます表 1 性能比較 ( 単位はミリ秒 ) スレッド数 Hashtable ConcurrentHashMap 図 4 性能比較のグラフ処理時間 [ 秒 ] スレッド数 Hashtable ConcurrentHashMap このように ConcurrentHashMap は性能上の利点を持っていますまた機能仕様は Hashtable と同じなので Hashtable と相互に置き換え可能ですすなわちレガシーなコードを含む Java アプリケーションは Java ランタイムをバージョンアップする機会に Hashtable から ConcurrentHashMap への置き換えを検討する価値がありますしかし Concurrent"HashMap" という名前のクラスでありながら HashMap から ConcurrentHashMap への置き換えは慎重に行う必要があります 5. HashMapからConcurrentHashMapへの置き換え HashMap を ConcurrentHashMap に置き換える場合はふたつの点について考慮する必要があります同期処理の見直し HashMap を使用するプログラムにはすでに同期処理が実装されているかもしれませんその場合実装されている同期処理を修正しなければ ConcurrentHashMap の性能上の利点が活かされません 4

5 java.util.collections.synchronizedmap() で HashMap に対応する同期マップを生成して使用している場合は Collections.synchronizedMap() の生成処理を ConcurrentHashMap に置き換えるだけで十分です (HashMap へのアクセス時に明示的な同期処理を実装していないだろうからです ) Collections.synchronizedMap() を使わず独自に同期処理を実装している場合は HashMap に関するすべての同期処理を見直す必要があります ( 不要な同期処理を削除する必要があります ) ただし仮に不要な同期処理が残っていたとしても万が一の場合にハッシュテーブルの破壊を防げるという点から ConcurrentHashMap を使う価値はあります nullの扱い HashMap はエントリーのキーや値に null を使用できますが ConcurrentHashMap では使用できません例えばキーに対する値が存在しないことを示すためその値を null で表現したいプログラムがあるとします HashMap は値が null のエントリーを扱えますしかし ConcurrentHashMap に対して値が null のエントリーを登録しようとすると NullPointerException が発生しますつまり既存のプログラムで使っている HashMap を単純に ConcurrentHashMap に置き換えると新たな問題 ( 例外の発生 ) を引き起こす恐れがあるということです ConcurrentHashMap クラスの次のメソッドはキーや値が null の場合に NullPointerException をスローしますつまり HashMap を ConcurrentHashMap に置き換える前にこれらのメソッドの使用箇所を調べ上げキーや値に null が使われることがないかどうか確認する必要があります get() containskey() containsvalue() contains() put() putifabsent() remove() replace() しかし数多く存在する HashMap すべてについて確認するとなると膨大な労力を必要としますそこで ConcurrentHashMap のラッパーとなるクラスを作成してその労力を軽減するアイデアを紹介します例えば次のように get() や put() などの NullPointerException をスローするメソッドをラップし ConcurrentHashMap のメソッドの引数に直接 null を与えないようにします図 5 ConcurrentHashMap をラップする例 5

6 public class WrappedConcurrentHashMap implements Map { private static final Object NullObject = new Object(); private ConcurrentHashMap m = new ConcurrentHashMap(); public Object get(object key) { if (key == null) { key = NullObject; Object o = m.get(key); if (o == NullObject) { o = null; return o; そのようなラッパークラスを HashMap の代わりに使うことで NullPointerException を発生することなく HashMap を ConcurrentHashMap に置き換えられます 6. まとめこれから作る新しいプログラムは ConcurrentHashMap の使用を検討するべきです複数のスレッドでハッシュテーブルを操作するアプリケーションにおいて最適なパフォーマンスを得ることができるでしょうしかしもっと重要なことは古くから存在するレガシーアプリケーションへの適用を検討することです HashMap の同期処理を誤ったためにシステム稼動後何年も経って問題が表面化する事例が発生していますこれはハードウェアが高性能化 ( マルチプロセッサ化マルチコア化 ) するにしたがってアプリケーションのスレッドが並列に処理されることが増えてきていることが一因です ( アプリケーションを変更せずミドルウェア OS やハードウェアだけを更新する場合に顕著です ) レガシーなアプリケーションを新しいシステムに移行する際は HashMap の使用箇所を点検して ConcurrentHashMap への置き換えを検討してくださいスレッドセーフの実現と性能向上を果たせる可能性があります HashMap を ConcurrentHashMap で置き換えるには既存の同期処理を確認して不要なものを削除し NullPointerException に対処することが必要ですソースコードの修正が必要ですがスレッドセーフな挙動とスケーラビリティを得られるため ConcurrentHashMap に置き換える価値は十分あります 6

7 参考文献 Java 2 Platform Standard Edition 5.0 API Specification Java Platform, Standard Edition 6 API Specification Java Platform, Standard Edition 7 API Specification 7

Java の ConcurrentHashMap における同期化バッドケースとその対処法 2013 年 9 月湊隆行 1. はじめに表 1.1 に示すように Java の Collections Framework には 3 つの世代がありますバージョン 1.0 から存在するレガシー API バ

Java の ConcurrentHashMap における同期化バッドケースとその対処法 2013 年 9 月湊隆行 1. はじめに表 1.1 に示すように Java の Collections Framework には 3 つの世代がありますバージョン 1.0 から存在するレガシー API バージョン 1.2 で追加されたロック機構を使わない API およびバージョン 5.0 で追加された同期化コストが低い