Когда нужно собирать объекты?

Question

Когда нужно собирать объекты с помощью C#? Любой хороший ex ...

Что такое pro и con для поддержания пула часто используемых объектов и захвата одного из пула вместо создания нового?

Answer 1

Есть только два типа ресурсов, о которых я могу думать, которые обычно объединяются: потоки и соединения (т. Е. В базу данных).

У обоих из них есть одна общая проблема: Недостаток.

• Если вы создаете слишком много потоков, контекст-коммутация будет отвлекать все ваше процессорное время.
• Если вы создаете слишком много сетевых подключений, накладные расходы на обслуживание этих соединений становятся более полезными, чем все, что должны делать соединения.
• Кроме того, для базы данных количество подключений может быть ограничено по причинам лицензирования.

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

Answer 2

1. При создании объекта является дорогостоящим
2. Когда вы потенциально могут испытывать давление памяти - слишком много объектов (например - приспособленец)

Answer 3

Я хотел бы добавить фрагментации памяти к списку. Это может произойти при использовании объектов, которые инкапсулируют собственные ресурсы, которые после их выделения не могут быть перемещены сборщиком мусора и могут потенциально фрагментировать кучу.

Один реальный пример - это когда вы создаете и уничтожаете множество сокетов. Буферы, которые они используют для чтения/записи данных, должны быть закреплены для переноса в собственный API WinSock, что означает, что при сборе мусора, даже если часть памяти исправлена ​​для сокетов, где они были уничтожены, - это может оставить память в фрагментированном состоянии, так как GC не может сжать кучу после сбора. Таким образом, буферы чтения/записи являются основными кандидатами для объединения. Кроме того, если вы используете объекты SocketEventArgs, они также будут хорошими кандидатами.

Вот good article, который рассказывает о процессе сбора мусора, уплотнении памяти и о том, почему помогает пул объектов.

Answer 4

Существует замечательная статья журнала MSDN, озаглавленная «Восстановить утраченное искусство оптимизации памяти» в управляемом коде Эрика Брауна. http://msdn.microsoft.com/en-us/magazine/cc163856.aspx. Он включает пул объектов общего назначения с тестовой программой. Этот пул объектов поддерживает минимальные и максимальные размеры. Я не могу найти ссылки на людей, использующих это в производстве. Кто-нибудь сделал это? Кроме того, имея дело с фрагментацией памяти в приложении ASP.NET, я могу засвидетельствовать значение в ответе Мики Динеску. Кроме того, немного уточнив ответ Виталия, рассмотрим случай больших объектов (т. Е.> 85K), которые очень дороги для создания. Большие объекты участвуют только в сборке мусора Gen 2. Это означает, что они не будут собраны так быстро, как объекты, которые полностью участвуют в сборке мусора в Gen 0 и Gen 1. Эта статья Куча больших объектов, не открытая Maoni Stephens в http://msdn.microsoft.com/en-us/magazine/cc534993.aspx, объясняет подробно кучу объектов.

Answer 5

Для игр GC может ввести нежелательную задержку в некоторых ситуациях.Если это так, повторное использование объектов может быть хорошей идеей. В разделе this thread есть несколько полезных соображений.