ByteBuffer класс утилизации - PullRequest
2 голосов
/ 26 февраля 2010

Мне интересно, как бы я кодировал класс переработки ByteBuffer, который может дать мне ByteBuffer, который по крайней мере такой же большой, как указанная длина, и который может заблокировать ByteBuffer используемые объекты для запретить их использование, пока они используются моим кодом. Это предотвратит повторное построение DirectByteBuffers и тому подобное снова и снова, вместо использования существующих. Существует ли существующая библиотека Java, которая может сделать это очень эффективно? Я знаю, что Javolution может работать с утилизацией объектов, но распространяется ли это на класс ByteBuffer в этом контексте с установленными требованиями?

Ответы [ 3 ]

4 голосов
/ 26 февраля 2010

Было бы более уместно быть более консервативным в ваших шаблонах использования. Например, есть много кода, который показывает распределение нового ByteBuffer на каждом OP_READ. Это безумие. Вам нужно всего два байтовых буфера максимум для каждого соединения, один для ввода и один для вывода, и в зависимости от того, что вы делаете, вы можете использовать только один. В очень простых случаях, таких как эхо-сервер, вы можете использовать один BB для всего приложения.

Я бы посмотрел на это, а не рисовал над трещинами еще один слой программного обеспечения.

3 голосов
/ 26 февраля 2010

Это всего лишь совет, а не ответ. Если вы реализуете некоторое кэширование для DirectByteBuffer, то обязательно прочитайте о последствиях GC, поскольку память, используемая DirectByteBuffer, не отслеживается сборщиком мусора.

Некоторые ссылки:

Нить - с указанием линии стека переполнения стека

Сообщение в блоге на ту же тему

И продолжение

1 голос
/ 23 мая 2010

Как правило, вы используете комбинацию ThreadLocal и SoftReference. Бывший, чтобы упростить синхронизацию (устранить необходимость в ней, по существу); и последнее, чтобы сделать буфер перезагружаемым, если не хватает памяти (учитывая другие комментарии относительно проблем GC с прямыми буферами). На самом деле все довольно просто: проверьте, есть ли у SoftReference буфер с достаточно большим размером; если нет, выделите; если да, четкая ссылка. Как только вы закончите с этим, переустановите ссылку, чтобы указать на буфер.

Другой вопрос - нужен ли ByteBuffer по сравнению с обычным байтом []. Многие разработчики предполагают, что ByteBuffers лучше с точки зрения производительности, но это предположение обычно не подтверждается фактическими данными (т. Е. Тестированием, чтобы увидеть, есть ли разница в производительности и в каком направлении). Причина, по которой byte [] часто может быть быстрее, заключается в том, что доступ к нему может быть проще, а HotSpot - эффективнее JIT.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...