Производительность: ConcurrentLinkedQueue <Integer>как последовательный входящий буфер - PullRequest
1 голос
/ 13 декабря 2011

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 13 декабря 2011

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


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

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

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

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

...