高パフォーマンスのシナリオで Java の StringBuilder を正しく使用する方法

高パフォーマンスのシナリオにおける StringBuilder の正しい使用方法

StringBuilder について、ほとんどの学生は、文字列の結合には StringBuilder を使用する必要があること、+ を使用しないこと、StringBuffer を使用しないこと、そしてパフォーマンスが重要であることだけを覚えています。はい、そうですか？

一部の学生は、次の 3 つのもっともらしい経験を聞いたこともあります:

1. Java はコンパイルおよび最適化されており、StringBuilder と同じ効果があります;

2. StringBuilder ではありませんthread-safe. 「安全性」のために、StringBuffer;

3 を使用することをお勧めします。ログ情報の文字列を自分で結合するのではなく、slf4j に任せてください。

1. 最初の長さは非常に重要であるため、4 回説明する価値があります。

StringBuilderの内部にはchar[]があり、定数append()は常にchar[]を埋めていく処理です。

new StringBuilder() を使用する場合の char[] のデフォルトの長さは 16 です。では、17 番目の文字を追加したい場合はどうすればよいでしょうか。

System.arraycopyを使って二重コピーして容量を拡張しましょう！ ！ ！ ！

このように、配列のコピーのコストがかかり、第二に、元の char[] も無駄になり、GC によって失われます。ご想像のとおり、129 文字の文字列が 4 回 (16、32、64、および 128) コピーされて破棄され、合計 496 文字が配列に適用されました。高パフォーマンスのシナリオでは、これはほぼ耐えられない。

したがって、初期値を合理的に設定することがいかに重要であるかということです。

しかし、実際にうまく見積もることができない場合はどうすればよいでしょうか?最終的に文字列が 16 より大きくなるのであれば、多少無駄になっても、容量を 2 倍にするよりはマシです。

2. Liferay の StringBundler クラス

Liferay の StringBundler クラスは、長さの設定に関する別のアイデアを提供します。append() のときに、急いで char[] に内容を詰め込む必要はありません。代わりに、最初に String[ ] を作成してすべてを保存し、最後にすべての String の長さを合計して、適切な長さの StringBuilder を構築します。

3. ただし、char[] の 2 倍はまだ無駄です

無駄は最後のステップ StringBuilder.toString()

// を作成しますcopy 、配列を共有しないでください
return new String(value, 0, count);

String のコンストラクターは System.arraycopy() を使用して受信 char[] をコピーします セキュリティを確保するためそして不変性ですが、このようにストーリーが終わっても、StringBuilder の char[] は無駄に犠牲になることになります。

この char[] を無駄にしないためには、Unsafe などの様々なブラックテクノロジーを使ってコンストラクタをバイパスし、String の char[] 属性に直接値を代入する方法がありますが、これを行う人はほとんどいません。 。

もう 1 つのより信頼性の高い方法は、StringBuilder を再利用することです。再利用により、最初の長さ設定の問題も解決されます。最初は推定が正確でなくても、さらに数回拡張すれば十分になるからです。

4. StringBuilder を再利用する

このメソッドは、JDK の BigDecimal クラスからのものです (JDK コードがどれほど重要であるかを理解するのは問題ありません)。SpringSide はコードを StringBuilderHolder に抽出します。 function

public StringBuilder getStringBuilder() {
sb.setLength(0);
return sb;
}

StringBuilder.setLength()この関数はカウント ポインタをリセットするだけで、char[] は引き続き再利用されます。また、toString() は現在のカウント ポインタをパラメータとして String コンストラクタに渡します。そのため、制限を超える古いコンテンツを渡すことを心配する必要はありません。新しいコンテンツのサイズです。 StringBuilder が完全に再利用可能であることがわかります。

同時実行性の競合を避けるため、この Holder は通常 ThreadLocal に設定されます。標準的な記述方法については、BigDecimal または StringBuilderHolder のコメントを参照してください。

5. + と StringBuilder

String s = “hello ” user.getName();

javac コンパイル後のこの文の効果は、これは確かに StringBuilder を使用するのと同じですが、長さを設定しません。

String s = new StringBuilder().append(“hello”).append(user.getName());

ただし、次のような場合:

String s = “hello ”;
// 他のステートメントで区切られる
s = s + user.getName();

それぞれここには 2 つの StringBuilder があり、パフォーマンスはまったく異なります。 s =i; がループ本体にある場合、さらにおかしなことになります。

R University によると、熱心な JVM エンジニアは実行の最適化段階にあり、XX: OptimizeStringConcat (JDK7u40 以降はデフォルトで開かれる) によると、(制御ステートメントなしで) 隣接する StringBuilder を結合できるようになるそうです。長さを推測してみてください。

したがって、安全を期すために、引き続き StringBuilder を使用し、長さを自分で設定してください。

6. StringBuffer と StringBuilder

StringBuffer と StringBuilder はどちらも AbstractStringBuilder から継承していますが、唯一の違いは、StringBuffer 関数に synchronized キーワードがあることです。

StringBuffer は「安全」だと言う学生の皆さん、複数のスレッドが順番に StringBuffer を追加しているのを実際に見たのはいつですか? ? ?

7. ログ文字列の連結を常に slf4j に引き渡します??

logger.info("Hello {}", user.getName());

出力するかどうかわからないログについては、本当に出力する必要がある場合のみ slf4j に任せて結合することで、確かにコストを節約できます。

ただし、出力する必要があるログの場合は、StringBuilder を使用して自分で結合した方が早いです。 slf4j の実装を見ると、実際には定数の Indexof("{}") と定数の subString() があり、それをまとめるために常に StringBuilder を使用しているだけであるため、特効薬はありません。

PS. slf4j の StringBuilder は、元のメッセージの外側に 50 文字を予約します。変数パラメータの合計が 50 文字を超える場合でも、それらをコピーして展開する必要があり、StringBuilder は再利用されません。

以上が高パフォーマンスのシナリオで Java の StringBuilder を正しく使用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。