У меня есть связанная блокирующая очередь, в которой я выполняю операции вставки и удаления.
Мне нужно знать, какой из них лучше put или offer в случае связанной блокировки очереди.
Параметры производительности - загрузка процессора, память и общая пропускная способность.
Использование приложения - система реального времени, где может быть несколько входящих запросов и меньше потоков для обработки, где нам нужно будет вставить элемент в очередь.
Я прочитал Java-документы о поставке и предложил, что во внутреннем приложении не было большой разницы.
На самом деле, вы не можете сравнить производительность между этими двумя, метод offer - просто предложить очередь, и он не ждет или ждет указанного времени, но метод put ждет бесконечно долго, пока не будет доступно пространство, поэтому их использование другой.
Используйте put где вы не можете позволить себе потерять предмет, имея в виду, что он будет удерживать ваш стек вызовов, иначе используйте offer.
LinkedBlockingQueue полностью реентерабелен, и метод poll() не блокирует put(). Однако метод poll() будет вращаться. Вероятно, вы должны использовать queue.take(), который ожидает, что там будет элемент в очереди, вместо того, чтобы возвращать null, если очередь пуста.
Также рассмотрите этот сценарий, метод poll (long, TimeUnit) будет ожидать добавления элемента в очередь за период времени и возвращает null, если таймер истекает. Это более чистое ожидание ждать чего-то в очереди.
// wait for 2000ms for there to be an object in the queue
Object o = queue.poll(2000, TimeUnit.MILLISECONDS);
// no sleep necessary
return o;
В документации дается ответ на этот вопрос. Предложение не ждет и "сдастся", если очередь достигнет емкости. Тем не менее, put будет ждать, пока место станет доступным - другими словами, он будет блокироваться до тех пор, пока не будет доступно пространство. Поэтому предложение явно быстрее, так как оно никогда не блокируется.