Пока я читал Tomcat source code, я обнаружил, что стек используется для кэширования объектов процессора. Почему следует использовать SynchronizedStack, например, ConcurentLinkedQueue?Tomcat использует стек intsead очереди. Почему лучше использовать стек вместо очереди или другого пула?
Нет никакой разницы в том, что структура данных используется для бесплатных процессоров, в то время как она позволяет добавлять элемент и доступный элемент, который будет выбран в постоянное время. Но связанный код является параллельным, и есть способ, который проще и эффективнее реализовать параллельный стек, чем параллельная очередь.
документация Javadoc для SynchronizedStack прямо говорит:
Это предназначено как (в основном) GC-свободная альтернатива
ConcurrentLinkedQueueкогда требование является создать пул многоразовых объектов без каких-либо требований к сжимать бассейн. Цель состоит в том, чтобы обеспечить минимальную требуемую функциональность как можно быстрее с минимальным мусором.
Мда, но все-таки, почему, так как они уже реализовали [SynchronizedQueue] (http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/collections/SynchronizedQueue. java), также ConcurrentLinkedQueue - это алгоритм без ожидания. тогда как SynchronizedStack & SynchronizedQueue блокирует – Shashank
Давайте сравним 'SynchronizedStack.push' и' SynchronizedStack.offer' в стабильном случае, то есть ни стек, ни очередь не будут расширены. В этом случае 'push' выполняет приращение, сравнение (правильно предсказанное как' false'), сохранение и возврат массива. 'offer' выполняет приращение, хранение массива, сравнение (иногда неправильно предсказано как« false »), другое сравнение (правильно предсказанное как« false »), return. Таким образом, «предложение» стоит одно (иногда неправильно предсказанное) сравнение больше. Тот же анализ выполняется для методов 'pop' и' poll'. – kgeorgiy