String

字符串作為一種特殊的引用類型，是迄今為止.NET程序中使用最多的類型。可以說是萬物皆可string

因此在分析dump的時候，大量字符串對象是很常見的現象

string的不可變性

string作為引用類型,那就意味是可以變化的.但在.NET中，它們默認不可變。
也就是說行為類似值類型，實際上是引用類型的特殊情況。

但是，"字符串具有不可變性"僅在.NET平臺下成立，只是因為在BCL(Basic Class Library)中并未提供改變string內容的方法而已。
在C/C++/F# 中，是可以改變的。因此，我們完全可以在底層實現修改字符串內容

眼見為實

示例1

可以看到，string的值為aaa

通過算法：address + 0x10 + 2 * sizeof(char) ,我們直接修改內存的內容

可以看到，同一個內存地址，里面的值已經從"aaa"變成了"aab".

示例2

字符串的可變行為

那么在日常使用中，我們需要大量字符串拼接的時候。如何改進呢？
最常見的辦法就是使用Stringbuilder.

Stringbuilder源碼解析

 public sealed partial class StringBuilder : ISerializable
 {
 		//存儲字符串的char[]
        internal char[] m_ChunkChars;
		//StringBuilder之間使用鏈表來關聯
        internal StringBuilder? m_ChunkPrevious;
		
        public StringBuilder(string? value, int startIndex, int length, int capacity)
        {
            ArgumentOutOfRangeException.ThrowIfNegative(capacity);
            ArgumentOutOfRangeException.ThrowIfNegative(length);
            ArgumentOutOfRangeException.ThrowIfNegative(startIndex);
            value ??= string.Empty;
            if (startIndex > value.Length - length)
            {
                throw new ArgumentOutOfRangeException(nameof(length), SR.ArgumentOutOfRange_IndexLength);
            }
            m_MaxCapacity = int.MaxValue;
            if (capacity == 0)
            {
                capacity = DefaultCapacity;
            }
            capacity = Math.Max(capacity, length);
            m_ChunkChars = GC.AllocateUninitializedArray<char>(capacity);
            m_ChunkLength = length;
            value.AsSpan(startIndex, length).CopyTo(m_ChunkChars);
        }
		public StringBuilder Append(char value, int repeatCount)
        {
            if (repeatCount == 0)
            {
                return this;
            }
            char[] chunkChars = m_ChunkChars;
            int chunkLength = m_ChunkLength;
    		// 嘗試在當前塊中放入所有重復字符
    		// 使用與 Span<T>.Slice 相同的檢查，以便在 64 位系統中進行折疊
    		// 因為 repeatCount 不能為負數，所以在 32 位系統中不會溢出
            if (((nuint)(uint)chunkLength + (nuint)(uint)repeatCount) <= (nuint)(uint)chunkChars.Length)
            {
				//使用Span高性能填充char[]
                chunkChars.AsSpan(chunkLength, repeatCount).Fill(value);
                m_ChunkLength += repeatCount;
            }
            else
            {
				//如果空間不足，則進行擴容
                AppendWithExpansion(value, repeatCount);
            }
            return this;
        }
		public override string ToString()
        {
			// 分配一個新的字符串用于存儲結果
            string result = string.FastAllocateString(Length);
            StringBuilder? chunk = this;
            do
            {
                if (chunk.m_ChunkLength > 0)
                {
                   // 將這些值復制到局部變量中，以確保在多線程環境下的穩定性
                    char[] sourceArray = chunk.m_ChunkChars;
                    int chunkOffset = chunk.m_ChunkOffset;
                    int chunkLength = chunk.m_ChunkLength;
					// 使用內存移動復制數據到result中
                    Buffer.Memmove(
                        ref Unsafe.Add(ref result.GetRawStringData(), chunkOffset),
                        ref MemoryMarshal.GetArrayDataReference(sourceArray),
                        (nuint)chunkLength);
                }
				//移動到上一個StringBuilder中，鏈表式讀取
                chunk = chunk.m_ChunkPrevious;
            }
            while (chunk != null);
            return result;
        }
 }

在Stringbuilder的內部，內部使用char[] m_ChunkChars將文本保存。并且使用Span方式直接高性能操作內存。

避免對象分配是改進代碼性能的最常見方法
string.format/string.join/$"name={name}" 等常見函數均已在內部實現Stringbuilder

字符串為什么不可變？

那么既然string的反直覺，那么為什么要這么設計呢？原因有如下幾點

1. 安全性
   string的使用范圍太廣了，比如new Dictionary<string, string>()，用戶token,文件路徑。它們的用途都代表一個key，如果這個key能被程序隨意修改。那么將毫無安全性可言。
2. 并發性
   正因為string使用范圍大，所以很多場景都可能存在并發訪問，如果可變，那么需要承擔額外的同步開銷。

為什么string不是一個結構？

上面說了這么多，結構完美滿足了不可變/并發安全 這兩個條件，那為什么不把string定義為結構？
其核心原因在于，結構的傳值語義會導致頻繁復制字符串
而復制大字符串的開銷太大了，因此使用傳引用語義要高效得多

JSON 的序列化/反序列化就是一個典型的例子

字符串暫存

.NET Rumtime內部有一個string interning 機制
當兩個字符串一模一樣的時候，不需要在內存中存兩份。只保留一份即可

但字符串暫存有個限制，默認情況下是只暫存靜態創建的字符串的。也就是靜態值才會被暫存起來.由JIT來判斷是否暫存

究其原因是因為這樣做開銷巨大，創建一個新字符串時，runtime需要動態的檢測它是否已被暫存。如果被檢測的字符串相當龐大或數量特別多，那么花銷同樣也很大。

FCL提供了顯式API string.IsInterned/string.Intern 來讓我們可以主動暫存字符串。

字符串被暫存在哪里?

https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/stringliteralmap.cpp

這時大家可以思考一下，暫存的字符串跟靜態變量有什么區別？ 都是永遠不會被釋放的對象
因此可以猜到。字符串應該是被暫存在AppDomain中。與高頻堆應該相鄰在一起.

在.NET內部Appdomain中，有一個私有堆叫String Literal Map的對象，內部存儲著字符串的hash與一個內存地址。
內存地址指向另外一個數據結構LargeHeapHandleTable .位于LOH堆中,LargeHeapHandleTable內部包含了對字符串實例的引用

在正常情況下，只有>85000字節的才會被分配到LOH堆中，LargeHeapHandleTable就是一個典型的例外。一些不會被回收/很難被回收的對象即使沒有超過85000也會分配在LOH堆中。因為這樣可以減少GC的工作量（不會升代,不會壓縮）

眼見為實

挖坑待埋，sos并未提供String Literal Map的堆地址，待我摸索幾天

安全字符串

在使用string的過程中，可能包含敏感對象。比如Password.
String對象內部使用char[]來承載。因此攜帶敏感信息的string。被執行了unsafe或者非托管代碼的時候。就有可能被掃描內存。
只有對象被GC回收后，才是安全的。但是中間的時間差足夠被掃描N次了。

為了解決此問題，在FCL中添加了SecureString類。作為上位替代

1. 內部使用UnmanagedBuffer來代替char[]

public sealed partial class SecureString : IDisposable
{
		private readonly object _methodLock = new object();//同步鎖
        private UnmanagedBuffer? _buffer; //使用UnmanagedBuffer代替char[]
		public SecureString()
        {
			_buffer = UnmanagedBuffer.Allocate(GetAlignedByteSize(value.Length));
            _decryptedLength = value.Length;
            SafeBuffer? bufferToRelease = null;
            try
            {
                Span<char> span = AcquireSpan(ref bufferToRelease);
                value.CopyTo(span);
            }
            finally
            {
                ProtectMemory();
                bufferToRelease?.DangerousRelease();
            }
        }
		
		public void AppendChar(char c)
        {
            lock (_methodLock)
            {
                EnsureNotDisposed();
                EnsureNotReadOnly();
                Debug.Assert(_buffer != null);
                SafeBuffer? bufferToRelease = null;
                try
                {
				    //解密內存以便進行修改
                    UnprotectMemory();
                    EnsureCapacity(_decryptedLength + 1);
                    Span<char> span = AcquireSpan(ref bufferToRelease);
                    span[_decryptedLength] = c;
                    _decryptedLength++;
                }
                finally
                {
					//重新加密
                    ProtectMemory();
                    bufferToRelease?.DangerousRelease();
                }
            }
        }
}

2. 實現了IDisposable接口，開發可以手動執行Dispose().對內存緩沖區直接清零，確保惡意代碼無法獲得敏感信息

        public void Dispose()
        {
            lock (_methodLock)
            {
                if (_buffer != null)
                {
                    _buffer.Dispose();
                    _buffer = null;
                }
            }
        }

安全字符串真的安全嗎？

SecureString的目的是避免在進程中使用純文本存儲機密信息
SecureString的底層本質上也是一段未加密的char[],由FCL進行數據加密/解密。
因此只有.NET Framework 中，內部的char[]由windows提供支持，是加密的
但在.NET Core中，其他平臺并未提供系統層面的支持

https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

因此，個人認為真正的"銀彈". 是數據本身就是加密的。比如從數據庫中存儲就是加密內容，或者配置文件中本身就是加密的。因為操作系統沒有安全字符串的概念。

惡意代碼只要能讀內存，且內存本身未加密。那么在CLR層上就是裸奔

轉自https://www.cnblogs.com/lmy5215006/p/18494483