📠 🔷 🥧 .NETの文字列機能 😴 🌇 👿

文字列データ型は、プログラミング言語で最も重要なものの1つです。このデータ型を使用せずに有用なプログラムを作成することはほとんど不可能です。ただし、多くの開発者は、このタイプに関連するニュアンスの一部を知りません。 .NETでこのタイプの機能をいくつか見てみましょう。

だから、メモリ内の文字列を表すことから始めましょう

B.NET文字列は、BSTR（基本文字列またはバイナリ文字列）ルールに従って配置されます。文字列データを表すこの方法は、COM（元々使用されていたVisualBasicプログラミング言語の基本語）で使用されています。 C / C ++で知られているように、PWSZは文字列を表すために使用されます。これは、 ワイド文字列へのポインタ、ゼロ終端を表します。メモリ内のこの配列では、行の終わりにヌル終了文字があり、これにより行の終わりを判別できます。 PWSZの文字列の長さは、空きメモリの量によってのみ制限されます。

BSTRは少し異なります。

メモリ内の文字列のBSTR表現の主な機能：

行の長さは、空きメモリの可用性によって制限されるPWSZとは異なり、特定の数によって制限されます。
BSTR文字列は常にバッファの最初の文字を指します。 PWSZは、バッファー内の任意の文字を指すことができます。
BSTRの末尾には常にPWSZと同様に常にヌル文字がありますが、後者とは異なり、有効な文字であり、文字列のどこにでも表示できます。
末尾にヌル文字が存在するため、BSTRはPWSZと互換性がありますが、その逆はありません。

そのため、.NETの文字列は、BSTRルールに従ってメモリ内で表されます。バッファーには、4バイト長の文字列、UTF-16形式の文字列の2バイト文字、2つのヌルバイト（\ u0000）が含まれます。

この実装の使用にはいくつかの利点があります：文字列の長さは再計算する必要がありません;それはヘッダーに格納され、文字列はどこにでもヌル文字を含むことができ、最も重要な文字列アドレス（固定）はWCHAR *が問題なく期待されるアンマネージコードに渡すことができます。

さらに進む...

文字列型オブジェクトはどのくらいのメモリを必要としますか？

文字列オブジェクトのサイズがsize = 20 +（length / 2）* 4に等しいと書かれた記事に出会いましたが、この式は完全に正しいとは限りません。

まず、文字列は参照型であるため、最初の4バイトにはSyncBlockIndexが含まれ、2番目の4バイトには型へのポインターが含まれます。

行サイズ= 4 + 4 + ...

上記のように、文字列の長さはバッファに格納されます-これはint型のフィールドであり、これはさらに4バイトを意味します。

行サイズ= 4 + 4 + 4 + ...

文字列を各行の終わりにあるアンマネージコードに（コピーせずに）すばやく転送するために、2バイトを占有するnullで終わる文字があります。

行サイズ= 4 + 4 + 4 + 2 + ...

文字列内の各文字はUTF-16エンコードであることに注意してください。つまり、2バイトも必要です。

文字列サイズ= 4 + 4 + 4 + 2 + 2 *長さ= 14 + 2 *長さ

ニュアンスをもう1つ考慮し、目標を達成します。つまり、CLRのメモリマネージャーは4バイト（4、8、12、16、20、24、...）の倍数でメモリを割り当てます。つまり、文字列の合計長が34バイトを占める場合、36バイトが割り当てられます。値を最も近い4の倍数に丸める必要があります。このために必要です。

文字列サイズ= 4 *（（14 + 2 *長さ+ 3）/ 4） （自然分割の整数）

バージョンの問題：バージョン4より前の.NETでは、Stringクラスはint型の追加のm_arrayLengthフィールドを格納しますが、これには4バイトが必要です。このフィールドは、文字列に割り当てられたバッファーの実際の長さで、ヌル終了文字、つまり長さ+ 1を含みます。.NET4.0では、このフィールドはクラスから削除され、その結果、文字列型オブジェクトは4バイト少なくなります。

m_arrayLengthフィールドがない（つまり、.NET 4.0以降では）空行のサイズは= 4 + 4 + 4 + 2 = 14バイトであり、このフィールド（つまり、.NET 4.0より下）では= 4 + 4 + 4 + 4 + 2 = 18バイト。 4バイトを丸めると、それぞれ16バイトと20バイトになります。

文字列機能

そこで、文字列がどのように表現され、実際にメモリ内でどれだけ占有されているかを調べました。次に、それらの機能について説明しましょう。

.NETの文字列の主な機能：

これらは参照型です。
それらは不変です。文字列を作成すると、それを変更することはできなくなります（正直な方法）。このクラスの各メソッド呼び出しは新しい行を返し、前の行はガベージコレクターの餌食になります。
これらはObject.Equalsメソッドをオーバーライドします。その結果、リンクの値を比較するのではなく、文字列内の文字の値を比較します。

各項目をより詳細に検討してください。

文字列-参照タイプ

文字列は実際の参照型です。つまり、常にヒープに配置されます。多くの人々はそれらを意味のあるタイプと混同します。なぜなら、彼らは同じように振る舞うからです。例えば、不変であり、参照ではなく値で比較されますが、これは参照タイプであることを忘れないでください

行は不変です

行は不変です。これには理由があります。文字列の不変性には多くの利点があります。

スレッドは文字列の内容を変更できないため、文字列型はスレッドセーフです。
不変の文字列を使用すると、1つの行の2つのインスタンスを保存する必要がないため、メモリの負荷が軽減されます。この場合、比較されるのはリンクのみで済むため、消費されるメモリが少なくなり、比較が高速になります。これが.NETで実装するメカニズムは文字列インターン（文字列プール）と呼ばれます。これについては後ほど説明します。
不変のパラメーターをメソッドに渡す場合、変更されることを心配する必要はありません（もちろん、refまたはoutとして渡された場合を除きます）。

データ構造は、一時的なものと永続的なものの2つのタイプに分類できます。エフェメラルは、最新バージョンのみを保存するデータ構造です。永続は、変更されたときに以前のバージョンをすべて保持する構造です。後者は実質的に不変です。なぜなら、それらの操作はその場で構造を変更せず、代わりに前の構造に基づいて新しい構造を返すからです。

行が変更されていない場合、永続的である可能性がありますが、そうではありません。 .NETでは、文字列は短命です。リンクでEric Lippertがまさにそうである理由について詳しく読むことができます。

比較のために、Java文字列を使用します。 .NETのように不変ですが、永続的でもあります。 JavaでのStringクラスの実装は次のようになります。

public final class String { private final char value[]; private final int offset; private final int count; private int hash; ..... }

タイプへのリンクと同期オブジェクトへのリンクを含む、オブジェクトヘッダーの同じ8バイトに加えて、文字列には次のフィールドが含まれます。

char文字配列へのリンク。
char配列の文字列の最初の文字のインデックス（開始したオフセット）。
1行あたりの文字数。
hashCode（）メソッドの最初の呼び出し後の計算されたハッシュコード。

ご覧のとおり、Javaの文字列は、.NETよりも多くのメモリを消費します。これは、文字列に追加フィールドが含まれるため、それらを永続化できるためです。永続性のため、JavaのString.substring（）メソッドはO（1）で実行されます。これは、このメソッドがO（n）で実行される.NETのように文字列をコピーする必要がないためです。

JavaでのString.substring（）メソッドの実装：

 public String substring(int beginIndex, int endIndex) { if (beginIndex < 0) throw new StringIndexOutOfBoundsException(beginIndex); if (endIndex > count) throw new StringIndexOutOfBoundsException(endIndex); if (beginIndex > endIndex) throw new StringIndexOutOfBoundsException(endIndex - beginIndex); return ((beginIndex == 0) && (endIndex == count)) ? this : new String(offset + beginIndex, endIndex - beginIndex, value); } public String(int offset, int count, char value[]) { this.value = value; this.offset = offset; this.count = count; }

しかし、LDNBの原則（昼食は無料ではありません）によれば、エリックリッパートはよく言っているのであまり良くありません。ソース文字列が十分に大きく、カットするサブ文字列が数文字の場合、サブ文字列へのリンクがある限り、元の文字列の文字配列全体がメモリにハングアップします。または、標準の方法で受信したサブ文字列をシリアル化してネットワーク経由で転送すると、元の配列全体がシリアル化されますまた、ネットワークを介して送信されるバイト数は多くなります。したがって、この場合、コードの代わりに

s = ss.substring（3）

コードを使用できます

s =新しい文字列（ss.substring（3））、

ソース文字列の文字配列への参照は保存されませんが、配列の実際に使用される部分のみがコピーされます。ところで、このコンストラクタが文字配列の長さと等しい長さの文字列で呼び出された場合、この場合コピーは発生しませんが、元の配列への参照が使用されます。

Javaの最新バージョンで判明したように、文字列型の実装が変更されました。 xonixはこれを提案しました。これで、クラスにはオフセットフィールドと長さフィールドがなくなり、新しいhash32が（異なるハッシュアルゴリズムで）登場しました。これは、行が永続的ではなくなったことを意味します。これで、String.substringメソッドは毎回新しい行を作成します。

文字列はObject.Equalsをオーバーライドします

StringクラスはObject.Equalsメソッドをオーバーライドし、参照ではなく値による比較を行います。 ==を使用して文字列を比較するコードは、メソッドを呼び出すよりもエレガントに見えるので、開発者は==演算子をオーバーライドしてStringクラスの作成者に感謝していると思います。

 if (s1 == s2)

比較して

 if (s1.Equals(s2))

ところで、Javaでは、==演算子は参照によって比較されます。文字ごとに文字列を比較するには、string.equals（）メソッドを使用する必要があります。

ストリングインターン

さて、そして最後に、ストリングインターンについて話しましょう。

文字列を反転するコードの簡単な例を考えてみましょう。

 var s = "Strings are immutuble"; int length = s.Length; for (int i = 0; i < length / 2; i++) { var c = s[i]; s[i] = s[length - i - 1]; s[length - i - 1] = c; }

明らかに、このコードは一緒にコンパイルされません。行の内容を変更しようとしているため、コンパイラはこれらの行を誓います。実際、Stringクラスのメソッドは、内容を変更する代わりに、文字列の新しいインスタンスを返します。

実際、行は変更できますが、このためには安全でないコードに頼らなければなりません。例を考えてみましょう：

 var s = "Strings are immutable"; int length = s.Length; unsafe { fixed (char* c = s) { for (int i = 0; i < length / 2; i++) { var temp = c[i]; c[i] = c[length - i - 1]; c[length - i - 1] = temp; } } }

このコードを実行すると、予想どおり、行にはelbatummi era sgnirtSが含まれます 。

文字列がまだ変更可能であるという事実は、1つの非常に興味深い事件につながります。文字列インターンに関連付けられています。

文字列インターンは、同一のリテラルがメモリ内の1つのオブジェクトを表すメカニズムです。

詳細に深く入り込まない場合、文字列インターンの意味は次のとおりです：プロセス（アプリケーションドメインではなくプロセス）内には、1つの内部ハッシュテーブルがあり、そのキーは文字列であり、値はそれらへの参照です。 JITのコンパイル中に、リテラル行がテーブルに順番に入力されます（テーブルの各行は1回だけ発生します）。実行時に、リテラル文字列への参照がこのテーブルから割り当てられます。 String.Internメソッドを使用して、実行時に内部テーブルに行を配置できます。 String.IsInternedメソッドを使用して、行が内部テーブルに含まれているかどうかを確認することもできます。

 var s1 = "habrahabr"; var s2 = "habrahabr"; var s3 = "habra" + "habr"; Console.WriteLine(object.ReferenceEquals(s1, s2));//true Console.WriteLine(object.ReferenceEquals(s1, s3));//true

デフォルトでは、文字列リテラルのみがインターンすることに注意することが重要です。内部ハッシュテーブルはインターンメントの実装に使用されるため、JITコンパイル中に検索されますが、時間がかかります。したがって、すべての行がインターンされると、すべての最適化が無効になります。 ILコードへのコンパイル中に、コンパイラーはすべてのリテラル文字列を連結します。これらを部分に含める必要がないため、2番目の等式はtrueを返します。だから、事件は何ですか。次のコードを検討してください。

 var s = "Strings are immutable"; int length = s.Length; unsafe { fixed (char* c = s) { for (int i = 0; i < length / 2; i++) { var temp = c[i]; c[i] = c[length - i - 1]; c[length - i - 1] = temp; } } } Console.WriteLine("Strings are immutable");

ここではすべてが明らかであり、そのようなコードは文字列を出力する必要があることは不変です。しかし、いいえ！コードはelbatummi era sgnirtSを出力します。それは抑留そのものであり、文字列sを変更し、その内容を変更します。これはリテラルなので、インターンし、文字列の1つのインスタンスとして表示されます。

特別なCompilationRelaxationsAttribute属性をアセンブリに適用することにより、文字列インターンを回避できます。 CompilationRelaxationsAttribute属性は、CLR JITコンパイラーによって生成されるコードの精度を制御します。この属性のコンストラクターは、現在CompilationRelaxations.NoStringInterningのみを含んでいるCompilationRelaxations列挙を受け入れます。これは、アセンブリを強制収容を必要としないものとしてマークします。

ところで、この属性は.NET Frameworkバージョン1.0では処理されません。したがって、デフォルトで抑留を無効にすることはできませんでした。 2番目のバージョンから始まるmscorlibアセンブリは、この属性でマークされています。

安全でないコードを使用して、本当に必要な場合、.NETの文字列を変更できることがわかります。

安全でないとどうなりますか？

リフレクションメカニズムを使用して、安全でないコードに頼らずに文字列の内容を変更することが可能であることがわかりました。このトリックは.NETでバージョン2.0まで含まれていた可能性があり、Stringクラスの開発者はそのような機会を奪いました。

.NET 2.0では、Stringクラスに2つの内部メソッドがあります。SetCharは範囲外に出るのをチェックし、 InternalSetCharNoBoundsCheckは範囲外に出るのをチェックせず、指定された文字を特定のインデックスに設定します。実装は次のとおりです。

 internal unsafe void SetChar(int index, char value) { if ((uint)index >= (uint)this.Length) throw new ArgumentOutOfRangeException("index", Environment.GetResourceString("ArgumentOutOfRange_Index")); fixed (char* chPtr = &this.m_firstChar) chPtr[index] = value; } internal unsafe void InternalSetCharNoBoundsCheck (int index, char value) { fixed (char* chPtr = &this.m_firstChar) chPtr[index] = value; }

したがって、次のコードを使用すると、安全でないコードを使用しなくても文字列の内容を変更できます。

 var s = "Strings are immutable"; int length = s.Length; var method = typeof(string).GetMethod("InternalSetCharNoBoundsCheck", BindingFlags.Instance | BindingFlags.NonPublic); for (int i = 0; i < length / 2; i++) { var temp = s[i]; method.Invoke(s, new object[] { i, s[length - i - 1] }); method.Invoke(s, new object[] { length - i - 1, temp }); } Console.WriteLine("Strings are immutable");

このコードは、予想どおり、 elbatummi era sgnirtSを出力します。

バージョンに関する質問： .NET Frameworkの異なるバージョンでは、string.Emptyがインターンする場合としない場合があります。

コードを考慮してください：

 string str1 = String.Empty; StringBuilder sb = new StringBuilder().Append(String.Empty); string str2 = String.Intern(sb.ToString()); if (object.ReferenceEquals(str1, str2)) Console.WriteLine("Equal"); else Console.WriteLine("Not Equal");

.NET Framework 1.0、.NET Framework 1.1、および.NET Framework 3.5 SP1では、str1とstr2は同じです。 .NET Framework 2.0 Service Pack 1（SP1）および.NET Framework 3.0では、str1とstr2は等しくありません。現在、string.Emptyはインターンです。

パフォーマンス機能

抑留にはマイナスの副作用があります。実際には、CLRによって保存されたインターンされたStringオブジェクトへの参照は、アプリケーションが終了した後、さらにはアプリケーションドメインでも保持されます。したがって、大きなリテラル文字列は使用しないでください。または、InternationRelaxations属性をアセンブリに適用して、抑留を無効にする必要がある場合もあります。

この記事がお役に立てば幸いです...

.NETの文字列機能