12 Garbage Collection - Be an Idealistic Realist
Ehcacheマニュアルの12章では、ガーベージコレクションについて扱っています。特に巨大なヒープを用いる場合のGCの問題にフォーカスしています。このネタは、JDK1.5を対象としているらしい。 12.1 Detecting Garbage Collection Problems Full GC 中は、すべてのスレッドが停止します。Full GC の動作時間は、jstat で FGCT の値を見れば把握できます。 書式：jstat -gcutil 例 ：jstat -gcutil 10000 1000000 これは、フル・ガーベージコレクション・タイムなので、システムが完全に停止している時間を表してます。数秒ごとにこの数値が上がるようであれば、通常のアプリであれば問題です。 ちなみに、jpsコマンドで vmid の確認が可能です。（Windowsでコレ系のコマンドを使うにはJSE6以上が必
SelfPopulatingCache - Be an Idealistic Realist
自前でキャッシュを行う場合、データを取得する際のお決まりのパターンってありますよね。キャッシュミスした場合の処理って、大体こんな感じじゃないでしょうか。 キャッシュからgetを試みるが、nullが返る。 データソースからデータを取得。 キャッシュにput。 データを返す。 毎回こんなコード書くのは時間の無駄です。そこで登場するのが SelfPopulatingCacheです。 特徴は３つあります。 BlockingCacheの特徴を継承。（実際に継承してるので） キャッシュを使う側は、キャッシュの対象データの置き場所について一切知る必要がない。（CacheEntryFactoryで対応） refresh()メソッドが用意されており、このメソッドが呼び出されると、キャッシュ内の全要素を最新のものにアップデートします。その際、refresh中にほかのスレッドがキャッシュを読みにきた場合は、re
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Avoiding multiple repopulations of the same cache region (due to concurrency)
http://ehcache.org/documentation/constructs-0_5.html
キャッシュ機構設計 - ユーザーガイド - ehcache 日本語翻訳
http://ehcache.nadai.jp/ehcache-constructs/documentation/