Когда пойти для пулинга объектов?
Когда пойти для пулинга объектов с помощью C#? Любая польза исключая...
Что за и против поддержания пул часто используемых объектов и захватывает один от пула вместо того, чтобы создать новый?
3 ответа
Я могу представить себе только два типа ресурсов, которые обычно объединяются в пулы: потоки и соединения (т. Е. С базой данных).
У обоих есть одна общая проблема: Дефицит.
- Если вы создадите слишком много потоков, переключение контекста потратит впустую все ваше процессорное время.
- Если вы создаете слишком много сетевых подключений, накладные расходы на поддержку этих подключений становятся больше работы, чем все, что они должны делать.
- Кроме того, для базы данных количество подключений может быть ограничено по причинам лицензирования.
Итак, основная причина, по которой вы захотите создать пул ресурсов, заключается в том, что вы можете позволить себе иметь только ограниченное их количество одновременно.
Я бы добавил в список фрагментацию памяти . Это может произойти при использовании объектов, которые инкапсулируют собственные ресурсы, которые после выделения не могут быть перемещены сборщиком мусора и потенциально могут фрагментировать кучу.
Один из реальных примеров - создание и уничтожение множества сокетов. Буферы, которые они используют для чтения / записи данных, должны быть закреплены для передачи в собственный WinSock API, что означает, что когда происходит сборка мусора, даже если некоторая часть памяти восстанавливается для сокетов, которые были уничтожены, она может оставить память во фрагментированном состоянии, поскольку сборщик мусора не может сжать кучу после сбора. Таким образом, буферы чтения / записи - главные кандидаты для объединения. Кроме того, если вы используете объекты SocketEventArgs, они также будут хорошими кандидатами.
Вот хорошая статья , в которой рассказывается о процессе сборки мусора, сжатии памяти и о том, почему помогает объединение объектов.
- Когда создание объекта обходится дорого
- Когда вы потенциально можете столкнуться с нехваткой памяти - слишком много объектов (например, шаблон легкого веса)