Снижаем нагрузку на Garbage Collector, оптимизируя работу с памятью с помощью различных memory pool'ов

Как-то я работал над приложением, которое испытывало пиковые нагрузки при получении новых данных и не успевало поставить их в централизованную обработку. Профилирование показало, что дело было не в какой-то медленной time-critical функции, а в том, что в кульминационный момент из-за нехватки памяти запускался Garbage Collector, и на время сервисных работ по очистке памяти приложение замирало. Но если побороть прерывания программы Garbage Collector’ом по расписанию по разным причинам нерационально, а иногда и чревато ошибками Out Of Memory, то противостоять или отодвинуть момент превышения порога занятой памяти вполне возможно, переиспользуя уже выделенную память.

В докладе рассматриваются вопросы: 

• как организовать пул предопределенного размера с помощью буферизованного канала и когда это решение не работает; 
• особенности использования sync.Pool и когда не следует возвращать данные в пул;
• как запретить GC очищать выделенную память.