Производительность: ConcurrentLinkedQueue‹Integer› как последовательный входящий буфер

Допустим, у нас есть общий Serial и мы слушаем входящие байты. Допустим, что скорость записи больше, чем чтение и чтобы не терять байты из Serial вводим буфер и делаем следующее. Последовательный слушатель просто помещает байты в буфер (поток записи буфера) и считыватель буфера для извлечения байтов из буфера (поток чтения буфера) и анализа данных.

Насколько эффективно использование java 1.5 ConcurrentLinkedQueue<Integer> с учетом упаковки и распаковки при переключении между примитивным int incomingByte из последовательного и Queue<Integer>?

Ограничения:

  1. нет ограничений на размер буфера

Я знаю, что часто используется буфер фиксированного размера, такой как int[] buffer[BUFFER_SIZE], но я бы не хотел иметь ограничения на ограничение буфера.

  1. потокобезопасный

Лучше иметь потокобезопасность из коробки и не синхронизировать потоки вручную, используя блокирующий буфер или что-то в этом роде.


java concurrency buffer serial-communication
person Anton    schedule 13.12.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Какова скорость передачи в байтах/секунду вашего устройства? Если это менее 1 МБ в секунду, вероятно, не имеет значения, какой подход вы выберете.

Если вы записываете байты, почему бы не использовать ConcurrentLinkedQueue<Byte> Значение всех возможных байтов кэшируется, поэтому существует только условная стоимость автоматической упаковки и распаковки.

Основным узким местом производительности являются связанные записи в очереди. Каждый байт по-прежнему создает объект (который является узлом в списке), и каждый объект использует около 16 байтов. Другими словами, вы можете увеличить byte[] в 16 раз, и он будет использовать тот же объем памяти и создавать меньше мусора.

Чтобы удовлетворить ваши требования, вы можете использовать ConcurrentLinkedQueue<Byte>, однако создание кольцевого буфера для byte[] будет быстрее (и его легко изменить по размеру)

Если вы отправляете более 10 МБ / с, я бы предложил написать ByteBuffer и обменяться с другим потоком (т. Е. Таким образом, вы передаете большие блоки за раз)

person Peter Lawrey    schedule 13.12.2011
comment
Ожидается, что код будет работать на устройствах Android. Таким образом, отправителем может быть ПК (пишет в порт), а получателем может быть очень медленное устройство (читает из порта). Байтовая очередь лучше, чем целочисленная, но я думаю, что кольцевой буфер - лучший выбор. Спасибо - person Anton; 13.12.2011