Недавно мы обновили Netty 3.x до последней версии 4.x.После обновления мы обнаружили в нашей производственной системе страшную OOM, характерную для Netty ByteBuf. * 1001 *
Мы включили обнаружение утечек с помощью системного свойства, но по какой-то причине это, похоже, ничего не выводит в наших журналах, и мывсе еще в конечном итоге получается ошибка Netty OOM.
Чтобы избежать OOM, мы используем следующее, где мы можем позволить Netty управлять выпуском сообщения / ByteBuf:
SimpleChannelInboundHandler - освобождает сообщение чтенияByteToMessageDecoder - освобождает ByteBuf
. Остальные места, которые у меня есть, могут вызвать проблемы, если возникают исключения.
Сценарий 1. Считывание входного потока и создание ByteBuf для каждого чтения, а затем записьByteBuf на канал.Я мог видеть, когда при записи в канал он закрыт или имеет исключение, этот ByteBuf никогда не читается и никогда не освобождается.Если это произойдет, я должен выпустить этот ByteBuf?Я попытался выпустить его во время тестирования, но потом получил исключение, потому что в нем нет ссылок.Если на него нет ссылок, то действительно ли это вызывает утечку памяти?Я прочитал еще один вопрос, что вам нужно прочитать все байты, а затем выпустить ByteBuf.Это правда?
Сценарий 2: У меня есть 2 установленных канала.Когда я получаю сообщение на 1 канале, мы просто пишем его на другой канал.Когда не возникает никаких исключений, тогда другой канал, на который мы отправляем ByteBuf, освободит ByteBuf после использования и отправки байтов.Однако допустим, что запись его на другой канал не выполняется, за исключением того, что этот канал сейчас закрыт или что-то в этом роде.Опять же, этот ByteBuf никогда не читается, потому что его не удалось записать на другой канал.Если это произойдет, я должен выпустить ByteBuf?Еще раз, мне нужно потреблять это и затем выпустить это?