5

私はバーストにログインするためにたくさんのものを書いていて、データパスを最適化しています。でログテキストを作成しますStringBuilder。最も効率的な初期容量、メモリ管理に関しては、JVMに関係なくうまく機能するのでしょうか。目標は、ほとんどの場合、再割り当てを回避することです。これは、約80〜100の初期容量でカバーする必要があります。ただし、StringBuilderインスタンスがバッファ内でハングし、無駄なバイトが発生する可能性があるため、できるだけ少ないバイトを無駄にしたいです。

これはJVMに依存することは理解していますが、JVMに関係なく、「最小公分母」のような、最小のバイトを浪費する値があるはずです。私は現在128-16、を使用しています。ここで、128は適切なラウンド数であり、減算は割り当てのオーバーヘッド用です。また、これは「時期尚早の最適化」の場合と考えられるかもしれませんが、私が求めている答えは「経験則」の数値であるため、将来的にも役立つことを知っています。

私は「私の最善の推測」の答えを期待していません（上記の私自身の答えはすでにそれです）、誰かがこれをすでに研究していて、知識ベースの答えを共有できることを願っています。

4

2 に答える 2

4

この場合、賢くなろうとしないでください。

私は現在128-16を使用しています。ここで、128は適切なラウンド数であり、減算は割り当てのオーバーヘッド用です。

Javaでは、これはJVMの内部動作に関する完全に任意の仮定に基づいています。JavaはCではありません。バイトアラインメントなどは、プログラマーが悪用できる、または悪用すべき問題ではありません。

文字列の（推定される）最大長がわかっている場合は、それを初期サイズに使用できます。それを除けば、最適化の試みは無駄です。

大量のが非常に長期間存在することを本当に知っていて（これはロギングの概念に完全には適合しません）、ヒープスペースのバイトを節約するようにJVMを説得する必要があると本当に感じている場合文字列が完全に構築された後に使用してみてください。しかし、繰り返しになりますが、文字列がそれぞれメガバイトを浪費しない限り、実際に行って、アプリケーションの他の問題に焦点を当てる必要があります。StringBuildertrimToSize()

于 2012-11-13T12:48:36.530 に答える
3

さて、私はこれを自分で簡単にテストし、コメントの後にさらにテストして、この編集された答えを得ることになりました。

JDK 1.7.0_07とテストアプリレポートVM名「JavaHotSpot（TM）64ビットサーバーVM」を使用すると、StringBuilderメモリ使用量の粒度は4文字で、4文字でも増加します。

回答：少なくともこの64ビットJVMでは、メモリ割り当ての観点から、StringBuilderにとって4の倍数は同等に優れた容量です。

異なる初期容量で、異なるテストプログラムの実行（同じ初期ヒープ状態を持つため）で1000000のStringBuilderオブジェクトを作成し、ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getUsed()前後に出力することによってテストされます。

ヒープサイズを出力することも確認されました。JavacharStringBuilderの長さは2バイトであるため、予想どおり、各バッファのヒープから実際に割り当てられる量は8バイトの偶数倍です。つまり、初期容量1..4で1000000インスタンスを割り当てると、初期容量5 ... 8で同じ数のインスタンスを割り当てるよりも約8メガバイト少ないメモリ（インスタンスあたり8バイト）が必要になります。

于 2012-11-13T13:52:22.340 に答える