最近、一部の人々が Java の成功ぶりに苦言を述べています。 「Java のハッカー（コーダー）にはろくな奴がいない」「J2EE は学術的（実用的でない）」などのコメントが飛び出しています。 そして java.net 編集者の Daniel Steinbeg は、あるアプリケーションが java で書かれていることを理由に観客がこれを愚弄しているのを見たと言います。 どうやらアワレナルス・マケイヌスと呼ばれる IT 種族は、われわれ Java 開発者の成功に嫉妬しているようです。
あるいは、分かり切っていたことなのかも知れません。 IT 業界では、新しい、あるいは成功しなかったスキマものだけがクールなのです。 Java はそれが出た当初はまだクールでしたが、今となっては主流であり、業界の２大成功者の片方ですから、もうどうあってもクールではいられないのです。 こういう意見をはねつける前に事実の裏付けを求める一部の方々向けに、いくつか事実を並べてみましょう。
ですのでこういう哀れな批判的意見を見かけることがあったら、適切に答えましょう。 ただほほえんで「そうですね」と言えばよいのです。 その後であなたの Java プロジェクトに取りかかりましょう。 そして勝ち組の立場を楽しみましょう。
ニュースレターでは、いつもの記事、ニュース、そして恒例のセクションをご用意しています。 Kirkの 今月のまとめ では、仮想メモリ、ベストプラクティスのコーディングに関する議論と、非常に少ない情報からパフォーマンス問題の原因を突き止める方法をお届けします。 Javva The Hutt は彼の最新の日記で、「委員会」の Java による実装を見せてくれます。 漫画家 "profiler" 氏による パフォーマンスチューニング漫画の新作 もあります。 今月のインタビューでは Veritas 社の Chuck Palczak 氏にお話を伺いました。 氏はアプリケーションの性能低下を避けるにはどこを調べればよいかを正確に見つけだす人物です。 今月の質問 では、ヒープが巨大になっても問題はないのかどうか検証します。 そして 多数の新しいパフォーマンス Tips を簡潔に抽出しています。
Java パフォーマンスチューニング関連ニュース
私が使っている２台のマシンで、スワップを無効化（あるいはできる限り小さく）しようと決めてから１ヶ月ほどが過ぎました。 最初は、W2Kのシステムだけを犠牲にする予定でした。 ばかばかしいことに、そのマシンは 576MB のメモリを積んでいたのに対して、XP のマシンは 1GB 積んでいたのでした。 しかしそこまでたくさんのメモリを使うことはほとんどありません。 そのまれな例を挙げると、私は WL admin サーバ、IDEA、完全版である Weblogic Server と縮小版である Weblogic Express を、メール、ブラウザ、チャット、ワードなどと同時に走らせていて、それでも全部で 600MB 以下に納まっています。 Weblogic のインスタンスを３つも動かし始めたのはつい最近なので、小さい方のマシンでは問題があるかも知れませんが、大きい方（そして開発に使いたい方）のマシンでは何の問題もありません。 先月も述べたように、最近はメモリはかなり安価になっていますから、本物のメモリが安く買えるときにわざわざパフォーマンスを犠牲にして空きメモリを確保する理由があるでしょうか。
私の blog 読者の中にも、これを読んで自分のパソコンでスワップを解除した、と いう方が少なからず見られました。 おもしろいことに、私が愛読している yahoo のメーリングリストでもこの改造が流行したらしく、勇敢かつ硬派な人々がスワップ解除に挑んだようでした。 さらにおもしろいことに、私が気に入っている恐いもの知らずのパフォーマンス狂の集団も、仮想メモリは生産的でないと判断したようなのです。 結果を総合すると、仮想メモリの時代は終わったのだと決意した Java ユーザによる小軍団が発生したのです。
奇妙なのは、この道に至るまでにはどのグループも異なる動機づけがあったということです。 ST-J の参加者の一人（yahoo group の私の友人）は、Windows がいつまでたってもお気に入りの IDE である Eclipse をスワップアウトし続けている、と愚痴っていました。 飲み物を取りに少し席を離れている間に、Windows が Eclipse をディスクにコミットしてしまっていた、というわけです。 そこでキーを一つたたくと、彼にできるのは Windoze（と呼ぶのが彼の好みらしい）がEclipse を昏睡状態からたたき起こすまで、ディスクのアクセスランプが点滅するのを眺めることだけでした。 ですので、ヒドラの頭をちぎるような不毛な行為のかわりに、彼は keepresident (http://suif.stanford.edu/pub/keepresident/keepresident-0.1.0.zip) という便利な小ユーティリティを探し出しました。 これの面白い点は、スワップを完全にオフにした場合との比較ができるようになったという点です。 今のところ、keepresident はだいたいの場合 Windows が Eclipse がスワップするのを抑止できています。
対してこちら側はというと、薔薇色の人生というわけには残念ながら行かない状態です。 スワップを完全に解除した、と言いたいところなのですが、実はやっていません。 実のところ Windows はうそをつきます。 スワップを解除しても、Windows は最小限のスワップスペースを確保しています。 その証拠に、OS が針の穴からアプリケーションを押しだそうとでもしているのか、時折ディスクのアクセスランプがめちゃくちゃに点滅するのです。 想像するに、Windows がスワップせざるを得ないようなオペレーションがあったのでしょう。 マイクロソフトの技術情報記事 - 293215 を読んで、この予想が裏付けられました。 この記事によると、トップレベルウィンドウが最小化されると、OSはそのプロセスの「ワーキングセットを切り捨てる」のです。 Crayの世界では、これは roll-out repack と roll-in と呼んでいましたた。
Cray UniCOSは仮想メモリを使用しませんでしたが、実際にはスワップ空間によって処理されるような、メモリ管理に関する諸問題を解決する必要がありました。 これらの問題のために、OS はメモリを再構成する必要が生じました。 これをどう実現したかというと、プロセスをまるごとディスクにスワップ（あるいはロール）したのです。 しかるのちに、このディスクイメージの隙間を詰めてからメモリへ再スワップ（あるいはロール）します。 Cray とスワップが使える機械の違いは、イメージは RAM に存在しなければ（つまりスワップアウトされているときは）実行できないという点にあります。 Cray においてアプリケーションを再パックするのは、厳に慎むべき操作でした。 一台 2000万米ドルを超える代物とあって、クロック一つにいたるまで無駄遣いしないことが経済的に重要だったのです。 仮想メモリのあるシステムでは、メモリイメージの再構成にかかるコストははるかに小さいのです（そしてそんな機械のほうがずっと安上がりというわけ）。
というわけで、Windows がプロセスのワーキングセットを削ろうとした場合、そのためにメモリをスワップ空間に押し出す必要があるということになります。 本来スワップを解除したらこれは発生しないはずなので、Windowsは強制的にこの処理を行っていると言えます。
MS の技術情報では、そのシグナルを捕捉して Windowsが アプリケーションをスワップアウトしないようにする方法について説明が続きます。"stay resident" の動作原理についての解説にもなっています。 また、アプリケーションを常時メモリに保存しておけない理由も説明しています。
ここまでの知識をふまえても、私はスワップを再度有効にするつもりはありません。 たしかにスワップは発生しますが、実際に起きるのはとてもまれです。 時折 OS がページを書き出すか、あるいは書き戻そうとして、ディスクが忙しくなることもありますが、それでもほとんどの場合、私のマシンの反応は以前よりずっと良くなったと感じています。 パフォーマンスの改善はもう感じなくなりましたが、この文章を書いていて確かに速くなったということを思い出しました。 もうワードを使っていても、突然動きが止まってディスクが回り始める現象にいらだつことはなくなりました。 もしあなたが、これが自動保存機能のせいだと考えているのであれば、確かに関係はあるかも知れません。 しかし私はこの機能を有効にしていますが、前述のような長い速度低下を感じることはなくなりました。
というわけでどうぞ、勇気を出して私とともに「プログラマーによるスワップ反対運動」に加わってください。 スワップを解除してから、今月のまとめの続きをご覧ください。 あなたの文章を読む速度を速くはできないかも知れませんが、レンダリングの速度は間違いなく速くなるでしょう。
www.javagaming.org からご紹介する最初の投稿が、最近のパソコンにおける仮想メモリが無意味に見えることについての議論であることに驚く方はいないでしょう。 この議論の中で出てきた興味深い論点は、128MB のヒープは、20Mb/秒で読み込めるディスクからたったの６秒で取り出せる、というものです。 ではなぜ実際に起きる遅延はこれよりも長く見えるのでしょうか？ ある返信では、プロセスがスワップアウトされるとそのワーキングセットが大幅に減少することが指摘されていました。 逆にプロセスがスワップインされると、プロセスは真っ先にメモリがもっと必要であることを認識します。 そこで一歩戻って OS と交渉し、必要なメモリを取得しなくてはいけません。 メモリを確保したら、これを RAM へとスワップしていきます。 この操作は多くの場合、データを数回にわたって実メモリに読み込み直す、という結果を招きます。 128MB の空間を埋めるために、事実上数百MB のデータを読み込まなくてはいけないということもありえるのです。 そして Linux ファンのみなさんの人生はさらに過酷です。Linux はアプリケーションが使用中であってもこれをスワップアウトしてしまいます。 せめてもの救いは、少なくとも Linux ではスワップを完全になくせるということです。 参考までに、Solaris の JVM には自分自身をメモリ内に固定するオプションがあります。 （ISM でドキュメントを探してみてください）（訳注：Big Heaps and Intimate Shared Memory (ISM) のことと思われる）
通常であれば、Java によるゲームプログラミングは愛の宴です。 実のところ、激しい議論を読んだことがあるかどうかさえ思い出せないくらいです。 そんな場所で「HotSpot は死んでいるコードを除去できるか？」のようなトピックがヒートアップすると誰が考えるでしょうか？ 始まりはそれなりに礼儀正しいものでした。 コンパイルされたメソッドのダンプを可能にする「新しい」未公開のオプションである -XX:+PrintCompilation の情報まで出てきました。 激論はこの意見がきっかけでした。「目標は自分の手で何か最適化をする必要があるか理解するために、コンパイラが何を最適化し、何を最適化しないのかを知ることです」 なんと、これは大した意見ですね！
いろいろな意味でこの発言はとても示唆的です。 Cray のコンピュータを例に取ってみましょう。 Cray で効率的なコードを書くためには、まずそのアーキテクチャを理解する必要があります。 それを理解したら、次のステップはコンパイラが出力したコードを理解することです。 これらの知識を得ると、ハードウェアを最高の効率で利用できるようコードを調整する方法がわかるようになるのです。 これは手動でコードを最適化するためにコンパイラが行う処理を理解する必要があるという明快な例です。 もちろん、プロファイラを使った方が良い結果が出るというおなじみの投稿も数多く見られました。 しかしコードがどのように最適化されるか知らずに、プロファイラの情報を活用することができるのでしょうか。 できると言えばできるでしょうが、コンパイラの行う最適化を理解していれば、推測をする必要が少なくなるのは間違いありません。
JavaRanch に目を向けると、今回最初に取り上げる投稿はパフォーマンステスト用ツールを探しているという方のものでした。 まず、Apache JMeter が出力する数値に関する興味深い講釈がありました。 その正確さについてあまり満足していない人々がいるかのようでした。 さらにおもしろいことに、これは Jack と私が Java Performance Tuning の講習で利用しているツールでもあり、私たちが得た出力結果には問題は見られませんでした。 その上で述べるとすれば、検証に使うツールそのものも含めて、あなたが使おうとしているものをすべて検証するために時間を費やすのは意義あることです。 別の興味深い話としては、記事の "著者" である J.B.Rainsberger 氏が性能目標の定め方についてコメントを述べた際、私たちの本から内容を剽窃したのではないかと疑っています。あの一文は誓って私自身が投稿の中で書いたものです。
パフォーマンスの話になると、コーディングのベストプラクティスについての質問がとにかく果てしなく続くものです。 本気で考えてみると、コーディングにおけるベストプラクティスを実践して得られる性能改善は、最良のケースであっても小さなものです。 そして今月の投稿でも見られたように、質問が「if よりも switch ステートメントを使った方がいいですか」みたいなものだった場合、答えはこうです。 そんなことはわかりません！！！！ いやまあ、今のは大げさすぎたかも知れませんが、多くの場合パフォーマンスチューニングというのは、とても具体的な問題に対するとても具体的な答えなのです。 もちろん設計／コーディングの上席の中には間違いなく性能を悪化させるものもあります。 これらは性能を改善する定石よりもずっと特定しやすいものです。 しかし if と switch ステートメントの違いといった文脈で、質問自体も抽象的であった場合、そこに正しい答えや間違った答えはありえないのです。 どんな回答をしたとしても、その答えが間違いであるような状況は無数にありえます。 もし常に正解にたどりつけるとしたら、私たちは最適な解を生み出せるわけで、パフォーマンスチューニングを実践する必要もなくなります。 そんなことは私たちにはできませんので、その日がくるまでプログラマ諸氏にはとても長い間頼っていくことになるでしょう。
サーバーサイドからは、JSP リクエストに関する遅延に悩んでいるが、静的なページはまったく問題がない、という誰かからの短いけれど興味深い投稿から始めましょう。 くだけた調子の質問からは、Sun Solaris の 4CPU マシンで、CPU 利用率は 50% にしかなってないとわかりました。 それほど多くの情報が提供されたわけではありませんが、それでもいくつか興味深い事実を集めることができました。 まず、そのアプリケーションはそもそも CPU を 50% 以上使うようには作られていませんでした。 だから、我々はそれが CPU の限界からくる問題ではないと知っていたのです。 それによって、続く投稿群で提供されたすべてのアドバイスを単に無視することができました。 第二の情報は、静的なコンテンツでは説明のつかないような遅延はまったく起こっていないということです。 これが意味するのは、クライアントとサーバ間のネットワーク (少なくとも静的コンテンツを提供する部分について) にはボトルネックが存在しないということです。 さらに加えて、静的コンテンツの提供が問題なく行われているということは、メモリやディスク IO にも性能のボトルネックが無いということです。 残る問題点は、アプリケーションのボトルネック、アプリケーションにおけるクリティカルセクションでの競合 (単一または制限されたスレッド) です。 Servlet エンジンやウェブサーバの場合、一番ありがちなのは Servlet を実行するためのスレッドプールか JSP ページが DB 呼び出しをするならその時に使われるコネクションプールのスレッド数の問題でしょう。 どちらの場合でも、スレッドダンプを見るのが簡単な診断法です。 このアプリケーションの性能問題の原因について、最も真実に近そうな回答をした者として、Cameron Purdy 氏の名前をここに記録しておきます。
最後に取り上げるサーバーサイドからの投稿は、プロセスが利用中のメモリ量はどの方法で測定すべきか、という質問でした。 具体的には、投稿者は java.lang.Runtime が返す値と (Unix ユーティリティの) top の値のどちらを使うべきか知りたがっていました。 答えは、Solaris においては ps -o を使うことです。
Eric Sink 氏による 「製品の価格の決め方」 という素晴らしい記事を見つけた。 記事はソフトウェア製品についてのものだが、俺はいろいろな分野に応用できるだろうと思ったね。 「価格への不満の声」の項で、彼が「どんな価格をつけても、誰かは文句を言うものだ」と指摘したところでは、大笑いさせてもらったよ。
もしも私が製品をタダで配ったら、 「製品をインストールするためにもっとディスクを買わせようとしてるんだ」 と文句を言う人がいることでしょう。
もし、 私の製品を使ってくれる全員に 100ドルプレゼントした上に、 ビキニを着た サルマ ハエック (リンクは訳者による) がお宅にお邪魔してインストールしますよ、と言えば、「自分は金髪のほうが好みなんだ」、と文句を言う人がいることでしょう。
俺にはこれは真実のように思えるな。 で、製品の正しい値段はどうやって決めるんだい？ 記事全体は、最適な価格を決めるための最上のアドバイスを与えているように思える２行に要約されている。
実際、もし誰も製品の価格について文句を言わないとしたら、たぶんそれは安すぎるのでしょう。 だから、文句の量が適当な量に増えるまで価格を吊り上げていく、という手が有効なのです。
6月16日
委員会！
ラクダは委員会によって設計された馬だという言葉があったな。
フン、実際はラクダは環境適応能力に優れた生き物なんだぜ。
俺の経験では、馬を設計しろと言われた委員会はオモチャの木馬すら作れっこないのさ。
動物のことはほっといてやれよな。
俺は委員会の Java 実装を作ってやった。
それは委員会の挙動を完全にモデル化してるんだ。
不必要な static を取り去ったら、そのクラスはタスクを完了できてしまうのさ。
public class 委員会
{
public static void main(String args[])
{
決断する();
}
//
public static int 委員会の規模;
public static void 決断する()
{
委員会の規模 = 2;
for (int i = 0; i < 委員会の規模 ; i++)
new 委員();
}
//
// 誰が投票してるか、何に投票してるかは関係ない、結局それは委員会なんだから。
// それは政治にすぎない。
public static int 投票数 = 0;
public synchronized static void 投票する() {投票数++;}
//
public static boolean 投票完了したか() {return 投票数 == 委員会の規模;}
}
//
class 委員 implements Runnable
{
public 委員()
{
(new Thread(this)).start();
}
//
public void run()
{
自分の立場に固執する();
System.out.println("ふむ、そいつは通常よりうまくいきそうだな。");
}
//
// static(活気が無い) と void (空虚)、二つのとてもぴったりなキーワードだ
public synchronized static void 自分の立場に固執する()
{
委員会.投票する();
while(!委員会.投票完了したか())
{
try{Thread.sleep(1000);}catch(InterruptedException e){}
}
}
}
またな
今月は、Java アプリケーションの性能監視の強力な製品を持つ Veritas 社のシニアテクノロジストである Chuck Palczak さんにインタビューしました。 Chuck は顧客が Java を使って良好な性能を実現できるように力を尽くして来た何年にも渡る経験を披露してくれました。
自己紹介をお願いします。
私は VERITAS ソフトウェアのシニア Java テクノロジストです。 私の役目は、この会社の Java 市場向けの製品 (たとえば VERITAS Indepth for J2EE) の機能定義に協力することです。 コロラド州デンバーで働いており、20年以上に渡ってアプリケーションやシステムのパフォーマンスチューニングやテストに関わっています。
現時点での Java の性能問題で最も大きなものは何だと思いますか？
可視性の問題です。Java アプリケーションの開発者／運用者は、何が性能問題を引き起こしているのかを特定するためにアプリケーションの内部で何が起こっているのかを「見る」ことを必要としています。 見つけさえすればそれを修正することに集中できます。 性能問題はしばしば、アプリケーションが現実の負荷にさらされた時にのみ表面化するということが有ります。 性能問題を低オーバヘッドで可視化する手段を提供することには大きなやりがいが有ります。
性能に与える影響があまりに大きいために設計を変更せざるを得ないというような事柄は何か有りますか？
はい。中間層のアプリケーションというものは当然のことながら中間に有ります。 つまり、フロントエンド層からデータのリクエストを受け取り、バックエンド層から データを読み出し、データを処理し、整形してレスポンスをフロントエンド層に送ります。 私達が目にする最大の問題は、中間層のアプリケーションが、驚くべきことに他の層への非常に多くの分散呼び出しが与える大きな影響を考慮せずに書かれることが多いということです。 こうしたアプリケーションはたいてい開発環境ではうまく動作しますが、実環境の負荷を処理する時にはスケールしません。 可能な限り分散呼び出しの回数を減らすようアプリケーションを設計するというのが、ほとんどどんなときにもあてはまる良い考えです。
これまで見て来た中で、Java アプリケーション開発中にプロジェクトが犯す性能に関する失敗で最も有りがちなものは何ですか？
人は自分が一番良く知っているところに集中しがちで (たとえば、アプリケーションサーバだけとかデータベースだけとか)、アプリケーション全体を見渡すことを忘れてしまいます。 ある層の上でしたことはアプリケーションの他のすべての層に影響を与える可能性が有るのです。 データの流れ全体 〜 ユーザから始まってアプリケーションのすべての層を通ってストレージに収まり、それから逆向きにユーザへ向かう 〜 を見ることでアプリケーションがどのように動作するかについての総合的な視点を得ることができます。 繰り返しになりますが、実環境の負荷の下でアプリケーションがどれほどの性能を出すかを理解することが、ユニットテストよりもむしろ重要なのです。
これまでの経験の中で、プロジェクトに適用したことで最も大きな性能上の改良を得られた変更とは何ですか？
J2EE アプリケーションはときに数万ものデータベース内の行をメモリに読み込んである種のフィルタリング操作を行うことが有ります。 この性能問題を解決するにはデータベーススキーマの変更が必要となるでしょうが、メモリ上でフィルタリングするよりももっと賢く SQL を使うように書き直されたアプリケーションなら1000倍速く実行できます。 信じないかも知れませんが、2004年の時点ではこういった問題は皆さんが思っているよりも多いのです。
有用だった Java の性能ベンチマークは有りますか？
多くの Java アプリケーションの性能上の問題に対しては、まず最初に他の層に対する分散呼び出しに関するアプリケーション特有のコードを変更することから取り掛かります。 こういうことに対してはベンチマークはあまり役には立ちません。 ベンチマークは、アプリケーションサーバが提供する、高可用性のためのセッションレプリケーションやEJBの大規模利用といった機能を積極的に利用するアプリケーションの開発時には役に立ちます。 この分野の発展は続いていますが、Java ベンチマークによって報告される数値を、アプリケーションの開発にとって何か意味の有るものに翻訳するのは未だ困難です。
私達の読者に紹介してもらえるパフォーマンス関係のツールは何か有りますか？
もちろん。お分かりかと思いますが、私が開発に関わっている VERITAS Indepth for J2EE についてお話させていただきます。 この製品は、アプリケーションの性能問題を GUI によって大いに可視化し、警告の有った場所から実際に問題の有るところまでドリルダウンして行くことを可能にします。 たとえば、応答時間に対して Java サーブレット、JSP、EJB、JMS、JNDI、JDBC、XML がそれぞれどれだけを占めるのかを解析します。 他の Veritas 製品と組み合わせて使うことで、ウェブ、複数の JVM、DB サーバにまたがる動作状況を関連付けられます。 また、問題をどのように解決するかのアドバイスを与えてくれる SmarTune という機能を持っています。
プロダクション監視ツールにとって最も難しいことの一つは、情報の詳しさとオーバヘッドの大きさのバランスを取ることです。 Indepth for J2EE は、私達が「適応的計測」と呼ぶ、実運用環境においてオーバヘッドを最小に抑えながらも性能問題を最大限に可視化する特許出願中の適応的なバイトコード計測技術を用います。
私達の読者に性能に関するティップスを何か教えてもらえますか？
性能を計測する前に最適化に取り掛かってはいけません。 まず現実的な負荷の下での性能を計測しましょう。 実運用中のアプリケーションを詳細に監視することに替わるものは有りません。 そしてもちろん、分散呼び出しの実行がローカルなメソッド呼び出しよりも多くの時間を費やしていないかどうかに気を付けましょう。
どうもありがとう、Chuck。教えてくれた沢山のティップスが、読者がアプリケーションの性能を改善するのに役に立つことでしょう。
The JavaPerformanceTuning.com team
（-Xmx オプションを使って）大きすぎるヒープサイズを指定すると、アプリケーションが遅くなると読んだことがあります。これは本当ですか？
その通り。いや違います。そうかもしれません。
もしかしたらアプリケーションが遅くなるかも知れません。（必ず、というわけではありません）詳しく説明しましょう。
まず、ヒープの大きさはマシン上で利用できる物理メモリの容量よりも少なく設定すべきだと言うことはもうおわかりと思います。 これはつまりメモリの総量から、同時に走っている他のプロセスが使うメモリの量を差し引いた数字です。 さもなければ、おそらく JVM のプロセスがスワップを始めます。これはよくありません。 まあ、この辺のもろもろはもうご存じだと前提でいきましょう。 これ以外にヒープサイズは何か関係があるのでしょうか？
システム内で動作するガベージコレクション（GC）には（少なくとも Sun の JVM では）２種類あります。新世代 (New Generation) の GC と、旧世代 (Old Generation) の GC です。 新世代 GC にかかる時間は生存しているオブジェクトの数に比例するため、ヒープの大きさは関係がありません。 旧世代 GC の場合はヒープの大きさに比例します。 ほとんどのオブジェクトは若い世代で回収されますが、一部の寿命の長いオブジェクトは古い世代に押し込まれます。 古い世代が満杯になったら、JVM は旧世代 GC を実行します。 仮にヒープが 3GB あったら、（現在デフォルトではないが 5.0 ではデフォルトになる予定の）並列 GC を使っていない限り、旧世代 GC はおそらくすべての処理を数秒間止めてしまうことでしょう。 このような場合、全体的な GC はベストの場合よりも遅くなる可能性があります。 ヒープがもっと小さければ、旧世代 GC も短い時間で済んだはずです。
Java アプリケーションにおける理想的な状態は、古い世代が満杯にならないこと、つまり旧世代 GC がまったく起こらないことです。 そのため、ヒープが大きすぎても問題ないのであれば、旧世代 GC が発生しないようにシステムをチューニングするのが良いでしょう。 あるいは旧世代 GC が必ず発生するのであれば、ヒープの大きさが重要な要因になります。 ヒープが大きすぎるとアプリケーションの性能が悪化する可能性があります。 GC のオーバーヘッドがシステムに与える影響を最小限に抑えるようにしましょう。
The JavaPerformanceTuning.com team
http://www-106.ibm.com/developerworks/library/j-perf06304/
ガベージコレクションのチューニング
(最終更新 2004/6, 追記 2004-08-30, 著者 Jack Shirazi Kirk Pepperdine, 出典 IBM). Tips:
http://www-106.ibm.com/developerworks/java/library/j-perf07304/
依存性の計測
(最終更新 2004/7, 追記 2004-08-30, 著者 Jack Shirazi Kirk Pepperdine, 出典 IBM). Tips:
http://www.javaworld.com/javaworld/jw-07-2004/jw-0712-threadsafe.html
スレッドセーフなサーブレット
(最終更新 2004/7, 追記 2004-08-30, 著者 Phillip Bridgham, 出典 Javaworld). Tips:
http://www.javaworld.com/javaworld/jw-06-2004/jw-0628-performance.html
サーブレットとJSPのパフォーマンスチューニング
(最終更新 2004/7, 追記 2004-08-30, 著者 Rahul Chaudhary, 出典 Javaworld). Tips:
http://www.fawcette.com/javapro/2004_06/magazine/features/caustin/
1.5/5.0の新機能
(最終更新 2004/7, 追記 2004-08-30, 著者 Calvin Austin, 出典 JavPro). Tips:
http://www.fawcette.com/javapro/2004_06/magazine/columns/innovationfactory/
5.0 の並列処理クラス
(最終更新 2004/5, 追記 2004-08-30, 著者 Brian Goetz, 出典 JavaPro). Tips:
http://www.fawcette.com/special/j2ee/modi1/
6つの J2EE ベストプラクティス
(最終更新 2004/7, 追加 2004-08-30, 著者 Tarak Modi, 出典 FTPOnline). Tips: