Статическая память для входящих пакетов UDP - PullRequest
Новая
       10

Статическая память для входящих пакетов UDP

0 голосов
/ 14 октября 2010

Цель:

Для передачи данных из входящих дейтаграмм UDP 4 потокам, ожидающим в соответствующих очередях. Предполагается, что приложение работает непрерывно для прокачки трафика к DUT и обработки входящих сообщений. Вот что я делаю: 

1. Public byte[] receiveData = new byte[512]
2. receivePacket = new DatagramPacket(receiveData, 0 , receiveData.length)
[The above 2 steps are in constructor of the listener class]
3. while (1)
a. ApplicationStart.serversocket.receive(receivePacket)
b. recvData = new String(receivePacket.getData()
. 
. {Processing of data}
.

c. recvData = null

Проблема:

Память постоянно увеличивается. Я подозреваю, что это потому, что он ожидает GC, чтобы потребовать неиспользованную память. Я хотел бы выделить статическую память вне бесконечного цикла while. Проблема, с которой я сталкиваюсь, если я делаю это, заключается в том, что «receivePacket.getData ()» возвращает байтовый массив, и для работы с данными мне нужно преобразовать его в строку. Все данные представлены в текстовом формате (точнее, это пакеты MGCP). Пожалуйста, предложите любой способ убедиться, что память не исчерпана. Я не хочу вручную вызывать сборщик мусора. Я не уверен в накладных расходах для GC.

Спасибо

Ответы [ 2 ]

0 голосов
/ 14 октября 2010

Хорошо.Я очень надеюсь, что это домашнее задание, а не оффшорный проект ...

Ответ на ваш актуальный вопрос:

Вы можете создать несколько предварительно выделенных пакетов и добавить их в очередь.Возьмите использованный пакет с начала очереди и получите в него.Когда поток-обработчик обработал пакет, он помещает его в конец очереди.

Следует избегать шага 3.b, поскольку он создает новый байтовый массив и копирует содержимое из пакета в него,поэтому перепишите потоки для обработки пакетов (или байтовых массивов) в качестве входных данных.

Возможно, вы получаете пакеты быстрее, чем вы можете их обработать;и тогда ваш код будет использовать всю память.(Когда вы распределяете пакеты и строки и помещаете их в очереди потоков обработчика.)

Если вы используете очередь блокировки и ожидаете чтения «свободных» пакетов, этого не произойдет;по крайней мере, не так.Пакеты UDP будут отброшены или помещены в буфер (или, вероятно, оба) где-нибудь в сетевом стеке ОС или javas, поэтому вам нужно позаботиться об этом.Вот почему большинство «ориентированных на сообщения» протоколов заканчиваются использованием TCP / IP, хотя на самом деле они переносят «дейтаграммы»

0 голосов
/ 14 октября 2010

Во-первых, вам не нужно вызывать GC вручную, и обычно это плохая идея.

Сказав это, неясно, что вы подразумеваете под "память постоянно увеличивается".

Если вы имеете в виду, что выделение памяти вашим приложением, наблюдаемое извне, увеличивается, то это нормально. Java будет распределять новые объекты настолько долго, насколько это возможно, и запускать GC только тогда, когда свободного места нет. Со стороны кажется, что JVM использует все больше и больше памяти.

Если вы имеете в виду, что JVM сообщает, что ей не хватает места в куче (т. Е. Выбрасывает OutOfMemoryError), то у вас есть проблема. Однако эта проблема не будет устранена при запуске GC. Вместо этого вам нужно запустить профилировщик памяти Java, чтобы найти источник утечки и устранить его.

(Справочная информация: утечки памяти Java немного отличаются от (например) утечек памяти C / C ++. В C / C ++ утечка происходит, когда ваше приложение игнорирует free / delete объект, когда он больше не является В Java утечка памяти происходит, когда ваше приложение случайно сохраняет ссылку на объект, который больше не будет использоваться. Если GC считает, что приложение может снова использовать объект, оно не может восстановить это ... и, следовательно, объект остается вокруг.)

...