サイズが 600MB のアーカイブをアップロードしようとしています。
次のエラーが表示されます。
Execution failed for task ':uploadArchives'.
> Java heap space
...
...
Caused by: java.lang.OutOfMemoryError: Java heap space
最大値を設定するために、GRADLE_OPTS、JVM_OPTS、および MAVEN_OPTS 変数を設定しようとしました。たとえば、次のようなヒープ サイズです。
export GRADLE_OPTS=-Xmx1024m
gradle uploadArchives
しかし、私はまだ同じエラーが発生しています。
ここで何が欠けていますか？
問題は、gradle がシンボリック リンクを処理できないために、パッケージの実際のサイズがはるかに大きかったためです。
シンボリックリンクを手動で処理したところ、問題は解決しました。
最終的には、実行しているプラットフォームに関係なく、使用できる最大ヒープは常に有限です。Windows 32 ビットでは、これは約 2 GB です (特にヒープではなく、プロセスごとのメモリの合計量)。たまたま Java がデフォルト値を小さくすることがあります (おそらく、プログラマーが、この問題に遭遇し、その実行内容を正確に調べる必要なしに、メモリ割り当てが暴走するプログラムを作成できないようにするためです)。
したがって、必要なメモリの量を決定するか、使用しているメモリの量を減らすために取ることができるいくつかのアプローチがあります。Java や C# などのガベージ コレクション言語でよくある間違いの 1 つは、使用しなくなったオブジェクトへの参照を保持したり、代わりに再利用できる場合に多くのオブジェクトを割り当てたりすることです。オブジェクトがそれらへの参照を持っている限り、ガベージ コレクターはオブジェクトを削除しないため、ヒープ スペースを使用し続けます。
この場合、Java メモリ プロファイラーを使用して、プログラム内のどのメソッドが多数のオブジェクトを割り当てているかを判断し、それらが参照されなくなったことを確認する方法があるかどうか、または最初からそれらを割り当てないようにする方法があるかどうかを判断できます。私が過去に使用したオプションの 1 つは、"JMP" http://www.khelekore.org/jmp/です。
何らかの理由でこれらのオブジェクトを割り当てていると判断し、参照を保持する必要がある場合 (何を行っているかによって異なります)、プログラムの起動時に最大ヒープ サイズを増やすだけで済みます。ただし、メモリ プロファイリングを実行し、オブジェクトがどのように割り当てられるかを理解すると、必要なメモリ量をよりよく理解できるはずです。
一般に、プログラムが有限量のメモリ (おそらく入力サイズに依存) で実行されることを保証できない場合、常にこの問題に遭遇します。これらすべてを使い果たした後でのみ、オブジェクトをディスクなどにキャッシュすることを検討する必要があります。この時点で、何かのために「Xgb のメモリが必要です」と言う非常に正当な理由が必要であり、改善してもそれを回避することはできません。アルゴリズムまたはメモリ割り当てパターン。通常、これは大規模なデータセット (データベースや科学分析プログラムなど) で動作するアルゴリズムの場合にのみ当てはまり、キャッシュやメモリ マップド IO などの手法が役立ちます。
-Xmxヒープの最大サイズを設定するコマンドライン オプションを使用して Java を実行します。
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html#nonstandard
JVM ヒープ サイズはgradle.properties、gradle プロジェクトのルート ディレクトリにあるファイルで設定できます。このような：
org.gradle.jvmargs=-Xms256m -Xmx1024m