когда .net сборщик мусора не компактен gc heap?

Question

Я бег следующего кода

 StringBuilder sb = new StringBuilder(); 
     Stack stack = new Stack(); 
     SynchronizationContext sc = new SynchronizationContext(); 

     GC.Collect(); 
     Console.WriteLine("GC. First Execution."); 

     stack = null; 

     GC.Collect(); 
     Console.WriteLine("GC. Second Execution."); 

     GC.Collect(); 
     Console.WriteLine("GC. Third Execution."); 

При отладке этого кода с SOS я вижу, что после первого исполнения GC адресов следующие:

!dso 
... 
0239b5f8 System.Threading.SynchronizationContext 
0239b5a8 System.Collections.Stack 
0239b560 System.Text.StringBuilder 
... 

После второго исполнения нет «стек» объекта куча, но другие адреса:

!dso 
... 
0239b5f8 System.Threading.SynchronizationContext 
0239b560 System.Text.StringBuilder 
... 

Таким образом, объект «стек» был собран, но подкожно (SynchronizationContext) объект не был reloca в памяти для уплотнения. У нас есть зазор в памяти

!do 0239b5a8 
Free Object 
Size:  80(0x50) bytes 

После третьего выполнения ситуация такая же.

Почему это происходит? Почему «компактная» операция не выполняется в этом случае?

спасибо.

Answer 1

GC является ленивым, чтобы быть эффективным. Это фактически не будет бесплатным или, как вы говорите, «компактным», пока это не понадобится. Объект был перемещен в очередь размещения.

Вы можете подождать несколько дней и не увидеть его в чистоте. Он будет очищаться, когда ресурсы будут низкими, и это необходимо.