2

Sun Java 1.4.2 VM で実行されていた古い Java ソースを Sun Java (JRE) 6 VM にアップグレードしました。多かれ少なかれ変更しなければならなかった唯一のことは、いくつかの抽象オブジェクト (ハッシュマップ、ベクターなど) の明示的なデータ型を追加することでした。コード自体は非常にメモリ集約的で、最大 1G のヒープ メモリを使用します (VM を起動するパラメータとして -Xmx1024m を使用)。

新しい Java VM でパフォーマンスが向上したという記事をよく読んだので、これがこのアップグレードを行った理由の 1 つです。

  1. 私の場合、パフォーマンスが低下した理由を誰か思いつくことができますか?
  2. 既存のコードを (スピードに関して) 最適化したい場合、Java 以外の第一人者に何を探すべきかアドバイスはありますか? ヒント、推奨ドキュメント、ツールはありますか?

ありがとう。

4

4 に答える 4

7

ここにはあまり情報がありません。ただし、次の 2 点を検討してください。

  • Xmx と Xms を同じ値 (この場合は 1024M) にして VM を起動します。

  • 仮想マシンの起動にサーバー jvm dll が使用されていることを確認します。

  • プロファイラーを実行して、どのオブジェクトがメモリを占有しているか、またはどのオブジェクトがガベージ コレクションされていないかを確認します。

  • VM を jconsole に接続し、オブジェクトをトレースします

于 2008-12-12T11:35:30.093 に答える
3

アプリケーションの空き領域がほとんどなくなると、ガベージ コレクション時間が計算時間の大半を占める可能性があります。

これを探すには gc デバッグを有効にします。または、単に jconsole を起動してプログラムにアタッチするだけでもよいでしょう。

于 2008-12-12T11:28:40.357 に答える
3

理論的には、文字列が内部の char[] を共有する方法が変更されたため、アプリケーションがより多くのメモリを消費する可能性があります。1.4 以降は共有が少なくなります。http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/5100で私の古いブログを確認してください(新しいブログはこちら)

ガベージ コレクターのログを比較して、メモリ使用量が本当に問題であるかどうかを確認します。

それでも問題が解決しない場合は、Yourkit などのプロファイラーを使用して違いを見つけてください。

于 2008-12-12T15:07:46.037 に答える
0

間違いなくアプリでプロファイラーを使用してください (YourKit は素晴らしいです)...ほとんどの場合、プロファイラーで非常に迅速に問題を絞り込むことができるため、問題を推測するのに多くの時間を浪費するのは簡単です。

于 2010-01-31T02:25:59.567 に答える