メモリーの問題

一般のソフトウェア・プログラムと同様に、Javaアプレットもメモリーを使用します。Javaの場合、言語仕様 ではJava仮想マシン（JVM）の内部メモリー・マネージャである「ガベージ・コレクタ」が必要とされます。

Javaプログラムではメモリーが必要になると、JVMを通じてメモリーを要求します。空きメモリーがないと、

JVMはガベージ・コレクタを使用してメモリーを解放しようとします。ガベージ・コレクタは、プログラムを 実行するのに不要になったメモリーを解放して JVMに返します。それでもタスクの実行に必要なメモリーが

D:¥>appletviewer -J-mx24M "http://testpc.us/webforms/mem.html"

Default cache directory d:¥forms6i¥jdk¥bin¥..¥jcache not found. JAR caching disabled.

Forms Applet version is : 4 java.lang.OutOfMemoryError

at sun.awt.image.GifImageDecoder.<init>(Compiled Code)

at sun.awt.image.InputStreamImageSource.getDecoder(Compiled Code) at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:119) at sun.awt.image.InputStreamImageSource.doFetch(Compiled Code) at sun.awt.image.ImageFetcher.fetchloop(Compiled Code)

at sun.awt.image.ImageFetcher.run(Compiled Code)

7.4.1 JVMランタイムランタイム・オプションの設定ランタイムランタイム・オプションの設定・オプションの設定・オプションの設定

JVMについては、割当て最大メモリーと共に初期割当てメモリーも設定できます。全パラメータのリストは、

http://java.sun.com/products/jdk/1.1/docs/tooldocs/solaris/java.htmlを参照してください。

以下に、一部のパラメータを紹介します。

D:¥testjava>appletviewer -J-help x usage: java [-options] class

オプションには次のものが含まれます。

-help このメッセージを表示します。

-version ビルドのバージョンを表示します。

-v -verbose verboseモードをオンにします。

-debug リモートJAVAデバッグ機能を使用可能にします。

-noasyncgc 非同期ガベージ・コレクションを禁止します。

-verbosegc ガベージ・コレクションが実行されると、メッセージを表示します。

-noclassgc クラス・ガベージ・コレクションを使用不可にします。

-ss<数字> 任意のスレッドの最大ネイティブ・スタック・サイズを設定します。

-oss<数字> 任意のスレッドの最大Javaスタック・サイズを設定します。

-ms<数字> 初期Javaヒープ・サイズを設定します。

-mx<数字> 最大Javaヒープ・サイズを設定します。

-classpath <ディレクトリ名をセミコロンで区切る>クラスを検索するディレクトリを一覧します。

-prof[:<ファイル>] .¥java.profまたは.¥<ファイル>にプロファイル・データを出力します。

-verify 読込み時にすべてのクラスを検証します。

-verifyremote ネットワークを通じて読み込まれたクラスを検証します。[デフォルト]

-noverify クラスを検証しません。

-nojit JITコンパイラを使用不可にします。

Appletviewerを使用する場合は、次のような構文を使用する必要があります。

appletviewer -J<オプション> <ファイル名>

たとえば、次のようなコマンドは初期「Javaヒープ」（JVMによって使用されるメモリー）を20MBに設定し、

JVMによって使用される最大メモリーを32MBに設定します。

Appletviewer -J-ms20m -J-mx32Mb "http://test-pc.us/webforms/maxmem.html"

Appletviewerのデフォルトの初期サイズおよび最大サイズはそれぞれ、16MBと20MBです。

JInitiatorを使用する場合、JInitiatorコントロール・パネルでランタイム・オプションを設定する必要がありま

す。

注：JVMは使用が許されているメモリーのみを使用します。オペレーティング・システム用のメモリーに余裕 があっても、JVMは使用しません。

7.5 メモリーメモリーメモリーメモリー・リーク・リーク・リーク・リーク

7.5.1 メモリーメモリー・リークとは何かメモリーメモリー・リークとは何か・リークとは何か・リークとは何か

メモリー・リークとは、プログラムのダイナミック・ストア割当てロジックのエラーで、廃棄されたメモリー を再現できなくなり、最終的にはメモリー不足に陥り、プログラムが実行不可能になります。

これは何を意味するのでしょうか？プログラムを実行すると、特定のタスクの実行に必要なメモリーを割り当 てる必要があります。プログラムがそのメモリーの使用を終えてメモリーが不要になっても、マシン上で実行 中の他のプログラムが使用できるようにメモリーを返せない場合は、メモリー・リークが発生したと言われま す。

ただし、問題はそれほど単純ではありません。複雑なソフトウェアの中には、割当て済みのメモリーを後で再 利用できるようにしばらく保持するものもあります。メモリー割当てはコストのかかる操作ですから、プログ ラムが後でより多くのメモリーが必要になると予測している場合は、未使用メモリーを再利用できるように 取っておく方が効率的です。

7.5.2 Javaでのメモリーでのメモリーでのメモリーでのメモリー・リーク・リーク・リーク・リーク

Java言語の仕様では、JVMにガベージ・コレクタ（GC）が必要とされています。Javaを使用する場合、プロ グラマーは新しいオブジェクトを作成してメモリーを割り当てます。このメモリーを割当て解除することはで きません。ガベージ・コレクタは定期的にプログラムに割り当てられたメモリーを整理し、廃棄しても問題の ないオブジェクトを判断し、メモリーを解放します。

ガベージ・コレクタは、廃棄しても問題のないオブジェクトを判断するアクティブな参照が残っているメモ リーをマークしながら、オブジェクトへの考えられるパスをすべて調べ、マークの付いていないオブジェクト を不要と判断します。これらのオブジェクトがガベージ・コレクションの対象としてみなされます。

Javaプログラミングにおいて誤解されがちなのは、ガベージ・コレクタが存在するからメモリー・リークは発 生しないと思われることです。これは間違いです。ガベージ・コレクタはアクティブ参照のあるオブジェクト をマークして、マークされていないオブジェクトを破壊するだけです。オブジェクトに不要なアクティブ参照 がまだ残っていることも考えられます。これがJavaでのメモリー・リークです。リークを解決するには、不要 になったオブジェクトの参照を破壊して、破壊しても問題がないとガベージ・コレクタに認識させる必要があ ります。Javaプログラムにメモリー・リークがある場合は、ガベージ・コレクタを呼び出す回数を増やしても 効果はありません。

さらに事態を複雑にするのは、JVMが使用されないメモリーをオペレーティング・システムに返さない場合が あることです。たいていのプログラムは将来のある時点で追加のメモリーが必要になり、JVMの空きメモリー を再利用できるので、現実にはオペレーティング・システムにメモリーが返されないと言ったことはほとんど 起こりません。ただし、JVM に割り当てられたメモリーがすべて、JVM で実行中のプログラムによって使用 されるわけではないということは覚えておく必要があります。

7.5.3 メモリーメモリー・リークを識別する方法メモリーメモリー・リークを識別する方法・リークを識別する方法・リークを識別する方法

一般に、特定の一連の操作を実行するたびにメモリーの使用量が増えるようなら、メモリー・リークがあると 考えられます。できれば、次のような方法で判断するのが理想です。

1. フォームを初期の基本状態にして、メモリーの使用量を記録する。

2. 一連の手順を実行して問題を例証する。

3. 初期の基本状態に戻って、メモリーの使用量を記録する。

手順2と3を繰り返せば、一定のメモリー・リークがあるかどうかを判断できます。何度も操作を実行しても、

メモリー使用量の増加がわずかであれば、リークではなく、JVMが未使用メモリーを保持しているか、ガベー ジ・コレクタが思ったほど頻繁に実行していないことが考えられます。