1

JFileChooser を使用して多数のファイルを開いていBufferedImageますimage = ImageIO.read(path);。image が静的フィールドとして宣言されている場所。

これで、それぞれ 1Mb のファイルが 30 個になり、read() を 60 回実行した後、メモリ使用量 (OS プログラム マネージャーで確認) が約 70Mb 増加しました。

私の画像変数は静的であるため、画像コンテンツがどこかに保存されているという問題ではありません。私の質問は、なぜそんなに多くのメモリを失っているのですか?

大量の写真をメモリにロードする必要があるアプリを書いていますが、ネギはありますか? 使用されていないデータをクリーンアップするのはガベージ コレクターのタスクですか?

このデータを読み取るコードは次のとおりです。

public class FileListElement {

private static final long serialVersionUID = -274112974687308718L;

private static final int IMAGE_WIDTH = 1280;

// private BufferedImage thumb;
private static BufferedImage image;
private String name;

public FileListElement(File f) throws IllegalImageException {
    // BufferedImage image = null;
    try {
        image = ImageIO.read(f);
        // if (image.getWidth() != 1280 || image.getHeight() != 720) {
        // throw new IllegalImageException();
        // }
    } catch (IOException e) {
        e.printStackTrace();
    }
    image.flush();
    //
    // thumb = scale(image, 128, 72);
    // image = null;

    name = "aa";
}
}

どうしたの？

多分私は間違っているのですか？RAMにロードされた大量の画像または圧縮画像から生のピクセルが必要です。そのため、画像の任意のピクセルにすばやくアクセスできました。

1Mb の pic をロードするのに 1Mb 以上かかるのは奇妙です。

4

1 に答える 1

3

現在のメモリ使用量が必要なメモリ量であることに期待することはできません。特に、最大メモリ使用量から離れている場合は、ガベージ コレクションが常に実行されるわけではありません。さらに画像を読み込んでみてください。問題がないことがわかる場合があります。

1Mb の pic をロードするのに 1Mb 以上かかるのは奇妙です。

まあ、ディスクに保存されている形式は圧縮されている可能性があり、メモリ内の BufferedImage よりも小さいと思います。だから、これはおかしいとは思いません。

于 2011-05-13T19:39:19.077 に答える