Когда пойти на объединение объектов?

Question

Когда идти за пул объектов с помощью C #? Любой хороший экс ...

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

Answer 1

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

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

Вот хорошая статья , в которой рассказывается о процессе сборки мусора, сжатии памяти и почему помогает пул объектов.

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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